Работа с базой данных

• Настройка автоматического резервного копирования
• Очистка базы данных
• Очистка базы от издержек тестирования с сохранением настроек
• Удаление логов из БД
• Полезные скрипты для работы с БД.
• IBExpert. Регистрация базы, выполнение скриптов и запросов
• Регистрация базы данных
• Выполнение скриптов и запросов к БД
• Мониторинг базы данных. Database Monitoring.
• Статистика базы данных (Database statistics)
• Причины и устранение задержек в работе с БД
• Долгий перевод смены - решение для версии ДО 146
• Иероглифы вместо кириллицы в программах Абонемент и Отчеты

Настройка автоматического резервного копирования

Резервное копирование через планировщик задач   

     Основной задачей резервного копирования является обеспечение непрерывности работы современного предприятия. Важность регулярного проведения резервного копирования в значительной мере объясняется зависимостью предприятий, организаций и отдельных людей от информации, хранимой и обрабатываемой компьютерами. 

     Для автоматического резервного копирования нам понадобится файл backup, который находится в папке IBDATA:

В файле используются относительные пути: 

WorkDBFileName - имя рабочей базы Shelter;

TeampDBBackup - временный файл для резервного копирования; 

RARBackup - файл резервного копирования;   

Обратите внимание от какого пользователя выполняется резервное копирование: 

Возможные варианты: -user ucs -password ucs / -user sysdba -password masterkey

Но выполнение резервного копирования рекомендуется от имени пользователя ucs!

Перейдем в Планировщик заданий: Пуск-Панель управления-Администрирование:

Создадим простую задачу:

Введем "Имя" и "Описание":

Триггер - Ежедневно

Резервное копирование лучше запускать в ночное время, когда с базой данных никто не работает.

Выбираем действие для задачи "Запустить программу":

Выбираем файл backup в каталоге IBDATA:

В следующем окне ставим чек-бокс Открыть окно "Свойства":

После открытия окна "Свойства":

1. Выберем УЧЕТНУЮ ЗАПИСЬ от имени которой будет выполняться задача
2. Выставим чек-боксы "Выполнять с наивысшими правами" и "Скрытая задача"
3. Проверяем остальные вкладки

В планировщике создается задача, щелкаем ПКМ по задаче и проверяем выполнение:

После успешного выполнения в строке "Результат последнего запуска" увидим "Операция успешно завершена"

 

Очистка базы данных

Очистка базы от издержек тестирования с сохранением настроек

Часто, в следствие использования базы без бэкапирования, для целей обучения и/или обкатки объекта, появляется необходимость очистки базы, с сохранением всех настроек.

Удалить всех клиентов, оплаты и кассовые смены, сохранив при этом все настройки абонементов, тарфов и пр., возможно.

Для этого нужно:

1. Запустить IBExpert, подключится к базе.

2. Запустить sqlEditor и выполнить следующий запрос:

select text from SPADM_CLEARUP_PREPARE('&CHECK_FIELDS_IN_WORKTABLES=1' ||'&CHECK_WORKTABLES=1' ||'&DELETE_STAFF=0' ||'&DELETE_USER=0');

3. Результатом выполнения запроса будет скрипт, который требуется выполнить в Script Executive. По окончании выполнения скрипта, база будет очищена в соответствии с указанными параметрами.

 

Примечание:

Если два первых параметра установлены в 1, то скрипт на выходе, очистит все действия из базы (оплаты, трансферы, посещения, клиенты), третий параметр отвечает за очистку списка специалистов, и четвёртый отвечает за удаление всех зарегистрированных пользователей Абонемент.

 

ВАЖНО

После выполнения полученного скрипта, на существующих киосках становиться невозможно открыть смену. 

Для устранения данной проблемы требуется применить скрипт:

update pos p set p.shift = 1 where p.id = 1 and p.shift = 0

Или же, можно средствами Абонемента создать новый киоск и продолжать работу на нём, деактивировав имеющийся.

Скрипт очистки будет поправлен в ближайших версиях и данная процедура больше не понадобится.

Обновление скрипта (146 версия, задача по трекеру http://tracker.shelter.ru/issues/201632) spadm_clearup_tableprepare_146 (4).sql

Удаление логов из БД

  При продолжительном использовании ПО "Абонемент" работающего в связке с утилитами gkHost и GkHostConnect (модуль управления турникетами), вся информация о каждой попытке прохода сохраняется в таблице Access_Control_Log, которая может достигать больших размеров (порядка нескольких гигабайт).

  Для данного случая был подготовлен скрипт "AutoDelete_Access_Control_Log", оставляющий в упомянутом выше файле информацию за последние 90 дней.

  На Рисунках 1,2,3 отражена последовательность действий в программе IBExpert для уточнения размера служебного файла (имеется ли смысл в применении данного скрипта).

Рис.1 "Заходим в программу IBExpert, щелкаем левой кнопкой мыши (один раз) по алиасу нашей рабочей базы в списке "Database Explorer", далее  нажимаем "Services" -> "Database Statistics";

 Откроется окно в котором нужно будет нажать на кнопку "Retrieve Statistics";\

Далее будет выведена статистика базы, переходим на вкладку "Tables" и обращаем внимание на колонку "Size, bytes".

Исходя из размера ACCESS_CONTROL_LOG принимаем решение о необходимости применения скрипта очистки.

Удаление логов взаимодействия оборудования с БД "Абонемент"

Скрипт состоит из 2 частей ("*.bat" и "*.sql"):

Содержание файла "AutoDelete_Access_Control_Log.bat":

set isql="C:\Program Files (x86)\Firebird\FireBird_2_5\bin\isql.exe"  
set sqlPath=%~dp0
set sqlFile=%sqlPath%AutoDelete_access_control_log.sql
%isql% -input %sqlFile% 

Содержание файла "AutoDelete_Access_Control_Log.sql":

/*Удаляет логи взаимодействия с оборудованием.
Оставляет только последние 90 дней*/
CONNECT '127.0.0.1/3080:D:\_FITNESS\IBData\FITNESS.FDB' USER 'ucs' PASSWORD 'ucs';
delete from access_control_log acl where acl.regdate < d2dbl('now') - 90;
commit work;

Удаление логов действий пользователей из БД "Абонемент" до заданной даты

Совместно со скриптом указанным выше, возможно (на усмотрение Заказчика) удаление логов действий пользователей в БД "Абонемент".

Содержание файла "AutoDelete_IBHistory_Log.bat":

set isql="C:\Program Files (x86)\Firebird\FireBird_2_5\bin\isql.exe"  
set sqlPath=%~dp0
set sqlFile=%sqlPath%AutoDelete_IBHistory_Log.sql
%isql% -input %sqlFile% 

Содержание файла "AutoDelete_IBHistory_Log.sql":

/*Удаляет логи до заданной даты. */ 
CONNECT '127.0.0.1/3080:D:\_FITNESS\IBData\FITNESS.FDB' USER 'ucs' PASSWORD 'ucs';
delete from sys_history;
delete from sys$log sl where sl.regdate<d2dbl('ДД.ММ.ГГГГ');
commit work;

Вся история изменений до ДД.ММ.ГГГГ будет удалена.

Скрипт AutoDelete_IBHistory_Log.sql, как и в случае AutoDelete_Access_Control_Log.sql, можно настроить на периодическое выполнение через "Планировщик задач" MS Windows.

При выполнении скрипта отдавайте себе отчет, что вносимые изменения необратимы! Рекомендовано все скрипты выполнять изначально на тестовой БД!

После выполнения любых скриптов по очистке логов необходимо сделать backup/restore 

Пример использования скрипта, в результате которого будет поддерживаться актуальная информация о проходах за последние 90 дней в таблице Access_Control_Log БД Абонемент(Создание задачи в "Планировщике задач" MS Windows):

Полезные скрипты для работы с БД.

Применительно к базам данных Abonement/Shelter.

1. Удаление логов из базы данных.

1.1.  Удаление логирования из таблицы LOG$FIELDS

     delete from log$fields;
     commit;                   

1.2. Удаление логирования из таблицы LOG$TABLES

	delete from log$tables;
	commit;

1.3. Для удаления логов за определенный период необходимо выполнить следующий скрипт:

           delete from LOG$TABLES LT where LT.DATE_TIME < d2dbl('now') - 30;

           delete from LOG$FIELDS LF where not LF.LOG_TABLES_ID in (select LT.ID from LOG$TABLES LT where LT.ID = LF.LOG_TABLES_ID);

           commit;

После выполнения данного скрипта, в БД останутся логи за 30 дней, остальные будут удалены.

      Для уменьшения размера БД необходимо сделать backup / restore.

1.4. Для автоматического удаления логов необходимо в «Планировщик заданий» Windows добавить простую задачу с выполнением .bat файла, рядом с котором должен быть файл script.sql.

      Содержание .bat файла:

                   @rem Указать путь до isql.exe

                   @echo off

                   set isql="C:\Program Files (x86)\Shelter\Firebird\bin\isql.exe" 

                   set sqlPath=%~dp0

                   set sqlFile=%sqlPath%script.sql

                   %isql% -input %sqlFile%

Содержание script.sql:

                                    CONNECT 'localhost/3080:C:\_BASE\SHELTER.FDB' user 'ucs' PASSWORD 'ucs';

                   delete from LOG$TABLES LT where LT.DATE_TIME < d2dbl('now') - 30;

                   delete from LOG$FIELDS LF where not LF.LOG_TABLES_ID in (select LT.ID from LOG$TABLES LT where LT.ID = LF.LOG_TABLES_ID);

                   commit;

 

2. Запрос и скрипт на перестыковку платежей. 

2.1. Сначала выполняем запрос в разделе Tools - SQL Editor.

Запрос:

select distinct cc.CHK
from CHECK_CONTENTS cc
where not exists(select i.id from INVOICES i where i.id = cc.CHK)
order by 1

2.2. Если после выполнения запроса в таблице появляются данные (таблица не пуста), то применяем скрипт.

Скрипт:

delete from CHECK_CONTENTS_JOINS ccd where ccd.CHK in (

select distinct cc.CHK from CHECK_CONTENTS cc
where not exists(

                              select i.id from INVOICES i where i.id = cc.CHK)
);

---------------------
delete from CHECK_CONTENTS ccd where ccd.CHK in (
select
distinct cc.CHK from CHECK_CONTENTS cc
where
not exists(select i.id from INVOICES i where i.id = cc.CHK)
);

 

3. Скрипт для смены адреса глобального сервера обновлений. 

3.1. Скрипт:

update DEFAULT_VALUES dv set dv.STRVALUE = 'udpate.shelter.ru' where dv.STRVALUE = 'shelter2.ucs.ru'

// shelter only !!? убрать

4. Получение сведений о клиентских приложениях.

4.1. Через SQL-Editor:

SELECT MON$USER, MON$REMOTE_ADDRESS, MON$REMOTE_PID, MON$TIMESTAMP
FROM MON$ATTACHMENTS
WHERE MON$ATTACHMENT_ID <> CURRENT_CONNECTION

4.2. Отключение всех соединений с базой, за исключением своего:

DELETE FROM MON$ATTACHMENTS
WHERE MON$ATTACHMENT_ID <> CURRENT_CONNECTION

Обязательный бэкап/рестор после выполнения скриптов!!!

IBExpert. Регистрация базы, выполнение скриптов и запросов

Регистрация базы данных

1. Для подключения к базе данных необходимо воспользоваться IBExpert. Дистрибутив ПО доступен:

- На официальном сайте: https://www.ibexpert.net/ibe

- В сборке (дистрибутиве) Shelter2.

2. Вход в  программу осуществляется путем запуска файла \Shelter...\IBExpert\IBExpert.exe

(Рис. 1 - Запуск приложения)

3. Зарегистрировать базу (если она ещё не зарегистрирована). Для этого необходимо: нажать кнопку -  Register Database (в разделе Database).

(Рис. 2 - Регистрация базы данных)

После этого ввести необходимые параметры подключения (см. рис. 3 - пункт 3) 

Remote - для удаленного подключения к FireBird, с возможностью ввода IP-адреса машины или имени сервера, а также номера порта.

Local - для локального подключения к FireBird, 127.0.0.1 - IP-адрес машины, используемый порт - 3080

Далее выбрать  кодировку WIN1251, установить логин UCS и пароль ucs для базы, выбрать версию Firebird (для всех актуальных установок используется версия 2.5). Указать путь до файла gds32.dll, который по умолчанию находится в папке с установленной версией Firebird в каталоге bin. Рекомендуется для Alias'а (отображаемого названия) использовать WORK - для рабочей базы и TEST - для тестовой.

(Рис.3 - Заполненные регистрационные данные базы)

4. Создать подключение к ещё одной базе можно простым методом - Клонировать Регистрационные Данные (Clone Registration Info) - нажав правой кнопкой на БД в списке Database Explorer (см. рис. 4 - пункт 2).

Подключиться к базе данных, дважды кликнув по ней в списке, либо выбрав соответствующий пункт из выпадающего меню - Connect to Database (см. рис. 4 - пункт 1).

А также посмотреть или изменить регистрационные данные базы, нажав правой кнопкой на существующей БД и выбрав из выпадающего списка пункт меню - Database Registration Info (см. рис. 4 - пункт 3)

(Рис 4 - Меню действий с базой данных)

Выполнение скриптов и запросов к БД

Выполнение скрипта (Script Executive).

1. После регистрации и подключения к БД, необходимо зайти в меню  Tools\Script Executive или использовать сочетание клавиш (Ctrl+F12)(см. рис. 1).

(Рис. 1 - Tools\Script Executive)

2. открыть SQL файл (см. рис. 2, пункт 1) (либо вставить содержимое скрипта в поле Edit), содержащий нужный скрипт, установить галочку (checkbox) "Use current connect" (данная функция будет активна, если выполнено хотя бы одно подключение к БД) (см. рис. 2, пункт 2).

(Рис. 2 - Меню выполнения скрипта)

При выполнении скриптов, базу регистрировать не обязательно - если подключение не выполнено, можно указать путь до базы в самом скрипте, например так:

CONNECT '127.0.0.1/3080:D:\Base\_Garbage_Shelter\_Tracker\SHELTER.FDB' USER 'UCS' PASSWORD 'ucs';

2. Нажать кнопку  Run Script (F9). Скрипт должен выполнится без ошибок.
3. Результат выполнения скрипта:

 (Рис. 3 - Результат выполнения скрипта)

Выполнение запросов к БД (SQL Editor).

1. Зайти в меню  Tools\SQL Editor или нажать клавишу (F12)

2. В открывшемся окне вписать необходимый SQL-запрос, нажать F9 (Execute)

Пример запроса : 

select * from folio f where f.id = 3201

3. Результат выполнения запроса :

(Рис. 4 - Результат выполнения запроса)

 

Мониторинг базы данных. Database Monitoring.

1. Инструмент Database Monitoring предназначен для мониторинга активности клиентов при работе с выбранной базой данных. После подключения к нужной нам БД, необходимо выбрать раздел Services\Database Monitoring (см. рис 1)

(Рис. 1 - Database Monitoring)

2. По умолчанию в левой части окна,  отображается в виде иерархии,  структура элементов,  выбрав одну из которых можно получить информацию о БД (Database):

- информацию о подключенных пользователях (Attachments)

- информацию о транзакциях которые выполняются к БД (Transactions)

- информацию о запросах к БД (Statements). 

(см. рис 2)

(Рис. 2 - Структура Database Monitor)

 

3. В ветке Database отображена информация о базе данных, например дата создания, размер страниц и т.д. (см. рис. 3):

(Рис. 3 - Ветка Database)

 

4. В ветке Attachments отображена информация о подключенных пользователях, например какой процесс подключен к базе, с какого ip-адреса осуществляется подключение, по какому протоколу выполняется соединение с базой и т.д. Можно отключить необходимое соединение выделив его и нажав кнопку "Shutdown attachment". Если необходимо отключить всех пользователей кроме текущего соединения (current connection), можно воспользоваться скриптом:

DELETE FROM MON$ATTACHMENTS
WHERE MON$ATTACHMENT_ID <> CURRENT_CONNECTION

(Рис. 4 - Ветка Attachments)

 

5. В ветке Transactions отображена информация о всех транзакциях в базе данных. Транзакция- это последовательность операций, выполняемых в логическом порядке пользователем, либо программой, которая работает с БД. Основные концепции транзакции описываются аббревиатурой ACID - Atomicity, Consistency, Isolation, Durability (Атомарность, Согласованность, Изолированность, Долговечность).

- Атомарность (Atomicity) гарантирует, что любая транзакция будет зафиксирована только целиком (полностью). Если одна из операций в последовательности не будет выполнена, то вся транзакция будет отменена. Тут вводится понятие “отката” (rollback). Т.е. внутри последовательности будут происходить определённые изменения, но по итогу все они будут отменены (“откачены”).

- Согласованность (Consistency) означает, что любая завершённая транзакция (транзакция, которая достигла завершения транзакции – end of transaction) фиксирует только допустимые результаты.

- Изолированность (Isolation) подразумевает, что каждая транзакция должна быть изолирована от других, т.е. её результат не должен зависеть от выполнения других параллельных транзакций. На практике, изолированность крайне труднодостижимая вещь, поэтому здесь вводится понятие “уровни изолированности” (транзакция изолируется не полностью).

- Долговечность (Durability) - Эта концепция гарантирует, что если мы получили подтверждение о выполнении транзакции, то изменения, вызванные этой транзакцией не должны быть отменены из-за сбоя системы (например, отключение электропитания).

5.1. Управление транзакциями.

Для управления транзакциями используются следующие команды:

- COMMIT
Сохраняет изменения

- ROLLBACK
Откатывает (отменяет) изменения

- SAVEPOINT
Создаёт точку к которой группа транзакций может откатиться

- SET TRANSACTION
Размещает имя транзакции.

Как мы видим на рис. 5, в ветке Transactions доступны операции Commit, Rollback и Shutdown attachment (разрывает соединение с БД у инициатора транзакции).

(Рис. 5 - Ветка Transactions)

 

6. Ветка Statements отображает информацию о запросах к БД. Запрос (query) – это средство выбора необходимой информации из базы данных. 

В таблице стоит обратить внимание на такие поля как:

- ATTACHMENT_ID (инициатор запроса к БД)

- STATEMENT_TEXT (Текст запроса)

С запросами можно выполнять следующие операции:

- COMMIT
Сохраняет изменения

- ROLLBACK
Откатывает (отменяет) изменения

- CANCEL STATEMENT
Отменяет запрос без отката изменений.

- SHUTDOWN ATTACHMENTS
Разрывает соединение с БД у инициатора запроса.

7. Руководство по языку SQL СУБД Firebird 2.5 можно найти здесь:

- https://www.firebirdsql.org/file/documentation/reference_manuals/Firebird_Language_Reference_RUS.pdf

- http://www.ibase.ru/files/firebird/langref25rus/index.html

 

Статистика базы данных (Database statistics)

1. Снижение производительности базы данных практически всегда связано с некорректным администрированием и/или плохой обработкой транзакций. Статистика базы данных IBExpert извлекает и отображает важную статистическую информацию базы данных, которую можно экспортировать в файлы различных форматов или распечатать. Данный пункт находится в меню Services\Database Statistics.

(Рис. 1 - Database Statistics)

Статистика базы данных полезна для обнаружения и решения различных проблем с производительностью, например, для определения того, открыта ли где-то старая транзакция, что может замедлить работу базы данных из-за администрирования постоянно растущего числа версий записей. Насколько эффективно заполняется страница данных? Можно ли его улучшить, разделив определенные большие таблицы на несколько меньших? Или для анализа других показателей.

Чтобы сгенерировать текущую статистику базы данных для всей базы данных, сначала нажмите верхнюю левую кнопку, чтобы просмотреть список всех зарегистрированных баз данных:

(Рис. 2 - Employee)

или просто перетащите узел базы данных или один или несколько выбранных узлов таблицы из обозревателя баз данных на страницу текста статистики базы данных для автоматического создания статистики по вашему выбору:

(Рис. 3 - Table Select)

Или откройте существующий файл статистики, чтобы просмотреть и проанализировать статистические записи:

(Рис. 4 - Analyze from file)

При необходимости можно изменить критерий построения статистики, выбрав один из следующих вариантов (Рис. 5):

- Прекратить получение статистики после заголовка страницы

- Прекратить получать статистику по страницам журнала

- Прекратить получение после того, как пользователь проиндексирует статистику

- Прекратить получение статистики после таблиц данных

- Прекратить получение статистики после системных таблиц и индексов

(Рис. 5 - Опции построения статистики)

 

2. Статистическая сводка базы данных отображается как текст:

(Рис. 6 - Статистическая сводка)

Текстовая сводка предоставляет определенную информацию из базы данных (Рис. 6), а также статистическую сводку с разбивкой по таблицам (Рис. 8), содержащую информацию, также отображаемую в сводной таблице.

В сводке отображается определенная информация журнала, такая как отметка времени , размер страницы и версия ODS (On-Disk Structure). Затем он перечисляет старейшую транзакцию, старейшая активная транзакция (самая старая транзакция, которая была начата , но еще не совершила или откат), старые снимки (это показывает, где сборщик мусора (Garbage collector) начнет свою работу) и следующую транзакцию . Это статистика, за которой всегда следует следить, поскольку она может указывать на потенциальный источник снижения производительности. Большая разница между самой старой активной транзакцией (OAT), а следующая транзакция указывает, что где-то в базе данных есть открытая транзакция (т. е. транзакция, которая была запущена, но не зафиксирована). Такая проблема может привести к постепенному замедлению работы базы данных по мере того, как сервер администрирует все больше и больше открытых версий, и сборщик мусора не может удалить более старые версии.

Статистика базы данных отображает следующую информацию для всех таблиц в базе данных, как в виде сценария журнала, так и в табличной форме: имя таблицы, расположение, страницы, размер (байты), слоты, заполнение (%) , использование DP (%) и заполнение распространение (оптимальное заполнение страницы - около 80%). Для каждой таблицы статистика индексов включает: глубину , сегменты листа, узлы, среднюю длину данных и распределение заполнения.

(Рис. 7 - Текстовая статистика)

Страница первичного указателя (Primary Pointer page): На рисунке выше страница первичного указателя (PTR) для таблицы EMPLOYEE имеет номер 172. Она начинается с байта, который равен номеру страницы 172, умноженному на размер страницы . Это своего рода оглавление таблицы EMPLOYEE; он указывает на страницы данных, которые содержат данные таблицы .

Корневая страница индекса (Index root page): та же информация отображается для корневых страниц индекса (IRT) для индексов в этой таблице.

Средняя длина записи (Average record length): показывает, какова средняя длина версий записи данных (в байтах). Когда таблица dBase создается, например, с двумя полями, каждое CHAR (100), средняя длина набора данных всегда будет 200. Firebird / InterBase ^®, однако, не сохраняет смежные пустые пространства. Например, поле CHAR (100), содержащее строку длиной 65, за которой следуют 35 пустых пространств, сохраняется Firebird / InterBase ^® как строка из 65 плюс 1 пустое пространство, умноженное на 35. Вот почему при импорте данных в Firebird / InterBase ^® из другой базы данных, данные иногда после импорта становятся меньше, чем были раньше. (См. Статью о технологии баз данных, Сервер Firebird и VARCHAR., для дополнительной информации.)

Всего записей (Total records): сколько наборов данных содержится в отдельных таблицах.

Средняя длина версии (Average version length): Средняя длина версий записи. После выполнения обновлений вы можете увидеть здесь, сколько байтов в среднем изменилось по сравнению с исходным набором данных.

Всего версий (Total versions): сколько версий записей существует для этой таблицы. Это число всегда должно быть как можно меньше, поскольку оно указывает, сколько версий таблицы хранится Firebird / InterBase ^® .

Максимальное количество версий (Max versions): максимальное количество версий для записи. Это указывает на то, что существует одна запись данных с таким количеством различных версий, которую Firebird / InterBase ^® должен хранить, потому что где-то в базе данных еще есть одна активная транзакция, что предотвращает удаление старых версий записей.

В этом случае интересно то, что это происходит не только с обрабатываемыми таблицами, но и со всеми таблицами. В режиме повторяемого чтения моментальный снимок всей базы данных создается сразу после запуска транзакции.

Страницы данных (Data pages): сколько страниц данных используется.

Среднее заполнение (Average fill): объем заполнения страницы данных в%.

Распределение заполнения (Fill distribution) : среднее заполнение рассчитывается исходя из того, сколько данных уже содержится на страницах данных. В Firebird / Interbase ^® Сервер обычно заполняет страницы до максимума 80%. Свободное место необходимо для хранения предыдущей версии; при обновлении одного из наборов данных, хранящихся на этой странице, новый набор данных может быть сохранен на той же странице, что и исходная версия. Это экономит количество страниц, которые необходимо загрузить, если потребуется вернуться к исходному набору данных.

Распределение заполнения также указывает, является ли заполнение отдельной таблицы аномалией или аналогичные проблемы возникают во всех таблицах.

3. Страница таблиц.

Таблицы перечислены в алфавитном порядке по именам, но, как всегда в IBExpert, их можно перемещать или сортировать по любому из перечисленных критериев, щелкнув соответствующий заголовок столбца . Заголовки столбцов можно перетащить в верхнюю часть страницы таблиц, чтобы отобразить данные, сгруппированные по этому столбцу.

(Рис. 8 - Страница таблиц)

Можно вычислить определенные агрегатные функции для отдельных столбцов (см. Столбец % заполнения на рис. 8).

Сетка таблицы дает хорошие отзывы о заполнении и использовании базы данных в ваших таблицах, например, вы можете быстро обнаружить таблицу с тысячами страниц при 50% -ном заполнении - тратя впустую половину пространства и используя буферы кеша в два раза быстрее, чем если бы страницы были заполнены. Это может быть указание на таблицы с большим количеством вставок и удалений, в этом случае пространство будет использовано повторно. Однако это также могло быть связано с недостаточным размером страницы , например, с размером страницы 4 КБ или 8 КБ и таблицами, в которые, возможно, были добавлены поля в течение определенного периода времени. Если наборы данных настолько велики, что на странице умещается только одна или две записи, остается много места.

Вы также можете обнаружить таблицу, которая, хотя и охватывает n страниц данных с использованием всего x байтов, с y количеством записей, но со средней длиной записи 0. В столбцах « Версии» отображается такое же количество записей со средней длиной записи, равной 0 байтов. Это означает, что таблица была удалена и больше не содержит данных. Однако версии записей по-прежнему должны поддерживаться для старых открытых транзакций.

Под сеткой таблицы индексная сетка отображает статистику для всех индексов выбранной таблицы. Для индексов отображается следующая информация: Имя индекса, Поля, Уникальный, Активный, Порядок сортировки, Статистика, Глубина, Конечные сегменты, Узлы , Средняя длина данных, Общее дублирование и Распределение заполнения. Дополнительную информацию можно найти на странице индексов.

Эта информация в табличной форме может быть экспортирована для сохранения информации в файл или распечатана.

Для получения дополнительной информации о том, как использовать статистику базы данных для максимизации производительности базы данных, обратитесь к главе «Администрирование Firebird с использованием IBExpert» , «Использование статистики базы данных IBExpert» .

4. Страница индексов.

Помимо сводной информации, отображаемой на странице " Таблицы", страница " Индексы" позволяет вам глубоко проанализировать все индексы вашей базы данных . Используя раскрывающийся список, вы можете указать, какие типы индексов вы хотите просмотреть:

- Все индексы (All indices)

- Плохие показатели (Bad indices)

- Бесполезные индексы (Useless indices)

- Слишком глубокие индексы (Too deep indices)

- Активные индексы (Active indices)

- Неактивные индексы (Inactive indices)

- Уникальные индексы (Unique indices)

- Неуникальные индексы (Non-unique indices)

(Рис. 9 - Уникальные индексы)

Индексы перечислены по таблице и полю, но, как всегда в IBExpert, их можно перемещать или сортировать по любому из перечисленных критериев, щелкнув соответствующий заголовок столбца. Заголовки столбцов можно перетащить в верхнюю часть страницы индексов, чтобы отобразить данные, сгруппированные по этому столбцу. Вы можете сразу определить тип индекса (Уникальный , Активный , По возрастанию или По убыванию).

В столбце Selectivity отображается фактическая селективность, которая принимается во внимание в Firebird / Interbase^®сервер, при работе, как лучше обработать запрос. В столбце Real Selectivity отображается уровень селективности, которого можно было бы достичь, если бы индекс был пересчитан. Если вы обнаружите расхождения в этих двух столбцах, нажмите кнопку Update Selectivity (Set Statistics) , чтобы пересчитать избирательность. Эти несоответствия возникают из-за того, что селективность вычисляется только во время создания или когда используется пункт меню IBExpert Recompute selectivity of all indices или Recompute all (см. рис. 10).

(Рис. 10 - Recompute selectivity/recompute all)

(Рис. 11 - Recompute selectivity of all indices)

SET STATISTIC INDEX {INDEX_NAME} 

Команда SET STATISTIC INDEX {INDEX_NAME} может использоваться в редакторе SQL (SQL Editor) для пересчета отдельных индексов.

Это автоматически выполняется во время резервного копирования и восстановления базы данных, поскольку сохраняется не индекс, а его определение, и поэтому индекс восстанавливается при восстановлении базы данных.

Первое, что делает оптимизатор при получении запроса, - это подготавливает выполнение. Он принимает решения относительно индексов исключительно на основании их избирательности. Плохие индексы - это те, которые Firebird/InterBase^®считает плохими. Может быть несколько причин, по которым Оптимизатор может считать определенный индекс плохим :

- Оптимизатор использует индексы с избирательностью <0,01 только при отсутствии других доступных индексов.

- Такой индекс вызывает очень медленную сборку мусора в старых версиях Firebird и InterBase^®. Эта проблема была решена , поскольку InterBase^®7.1/7.5 и Firebird 2.0.

- Индекс заставляет процесс восстановления быть очень медленным, и он создается очень медленно (CREATE / ALTER INDEX ACTIVE). Это связано с тем, что цепочка номеров записей велика для одного индексного ключа.

- Если индекс используется в предложении WHERE, использование памяти будет зависеть от искомого значения (размера битовой маски). Поскольку цепочка записей может быть большой (много дубликатов ключей), потребление памяти также будет большим.

- Если индекс используется в ORDER BY и имеется много дубликатов, в основном в нижних значениях ключа (в зависимости от порядка сортировки индекса), будет много чтений страницы индекса, что замедлит выполнение запроса.

Худший случай для индекса - это когда значение в столбце Uniques = 1, то есть, все значения для индексированного столбца одинаковы. Эти индексы перечислены как бесполезные индексы. Конечно, для вашего приложения может возникнуть ситуация, когда такой индекс подходит. Например, если записи имеют флаг «архивировать» в столбце, и ваше приложение выполняет поиск по индексу в этом столбце только для текущих, а не архивированных данных.

Обычно плохие и бесполезные индексы должны быть проверены и, если они не очень важны для вашего приложения (например, если вы не используете его для поиска ключей, имеющих меньше дубликатов, чем другие ключи), удалить. Однако это непросто сделать, если такой индекс создается внешним ключом, потому что вы можете отбросить его, только отбросив внешний ключ. Однако удаление внешнего ключа отключит соответствующее ограничение проверки, что может быть неприемлемым. Возможна замена внешнего ключа триггерами, но есть некоторые ограничения. Внешние ключи управляют отношениями записей с помощью индекса, и индекс видит все ключи для всех записей независимо от состояния транзакции. Однако триггер работает только в контексте транзакции клиента. Таким образом, при замене внешних ключей на триггеры вы должны быть уверены, что, во-первых, записи не будут удалены из главной таблицы или удалены в режиме snapshot table reserving, а во-вторых, убедитесь, что столбец, используемый первичным ключом в главной таблице, никогда не будет изменен. Вы можете ограничить это с помощью триггера перед обновлением .

Если вы соблюдаете эти условия, вы можете отбросить конкретный внешний ключ.

В следующем столбце отображается глубина индекса. Например, глубина индекса 2 означает, что Firebird/InterBase^® необходимо выполнить два шага для получения результата. Обычно значение не должно быть больше трех. В этом случае может помочь резервное копирование и восстановление базы данных.

5. Страница опций. 

Есть возможность автоматически анализировать статистику таблиц/индексов и выделять возможные проблемные таблицы/индексы. Эта функция основана на функциональности IBEBlock, поэтому ее можно полностью настроить.

(Рис. 12 - Страница опций)

Причины и устранение задержек в работе с БД

Причиной тормозов обычно являются:
1. Изменение одной(нескольких) процедур, например после обновления БД. В этом случае нужно перекомпилировать все процедуры и триггеры, а также обновить статистику всех индексов. В IBExpert'е есть соответствующие кнопки.
2. Накопление мусора. Нужно посмотреть результаты утилит statdata.bat и statheader.bat из \_UTILS\_BAT\FB_STATISTIC\

Чтобы не делать backup/restore, можно сначала посмотреть 2 вышеперечисленных пункта.

backup/restore решает обе проблемы.

Долгий перевод смены - решение для версии ДО 146

1. Примените скрипт SP_RECALC_AP_MAXQUANTVISIT_146_20211228_0.sql
2. Перекомпилируйте все процедуры и триггеры
В IBExpert'е выбираете:
\База данных\Перекомпилировать все хранимые процедуры
\База данных\Перекомпилировать все триггеры

Со 146 версии - данный скрипт выполняется автоматически при обновлении базы данных.

 

Иероглифы вместо кириллицы в программах Абонемент и Отчеты

В программах АМ не подтягивается русская кодировка на Windows 10. Версия, например TCPCardReader прошлогодняя, а отчётов актуальная. Но проблема одинаковая. Для программ без поддержки Юникода установлена кодировка по-умолчанию.
Как устранить эту проблему?

Решение приведено ниже.

Потребуется доступ к ПК с правами администратора.
Действовать необходимо незамедлительно следующим образом:
* Запускаем редактор реестра: Пуск > Выполнить и вводим regedit
* Находим в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage строковый параметр 1252, и меняем его значение на c_1251.nls
* В папке C:\WINDOWS\system32\ находим файлы С_1251.nls и С_1252.nls. С_1251.nls копируем в другое место и переименовываем в С_1252.nls
* Файл С_1252 в папке C:\WINDOWS\system32\ удаляем (на всякий случай сделав резервную копию). Копируем измененную версию файла С_1252 в папку C:\WINDOWS\system32\.

Этот пункт самый интересный, т.к. просто так ничего не получится. Для того, чтобы его выполнить, необходимо изменить права доступа к файлу. Но не тут-то было! У нас, вероятнее всего, нет доступа, чтобы изменить права доступа :) Чтобы все получилось вначале указываем себя владельцем файла (свойства > безопасность > дополнительно > владелец), а уже после этого даем себе полный доступ и подменяем файлы.

Идём в Пуск > Панель управления > Язык и региональные установки > Дополнительно. Выбираем в пункте "Текущий язык программ, не поддерживающий Юникод" пункт "Русский (Россия)"
Перезагрузка.
После выполнения всех этих "магических ритуалов" нехитрых действий, кириллические символы начнут отображаться корректно.