Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Delphi Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3 4      [все]
 Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
При работе моего приложения со временем растет размер базы данных Firebird.

Например, за полгода работы размер может вырасти до 600 мегабайт.
Проблема в том, что программа начинает тормозить, причем работать может в 10 раз медленнее, чем изначально.

При этом если сделать backup&restore - скорость работы программы возвращается к нормальной, размер базы становится в несколько раз меньше (например, был 600 Мб, стал 150 Мб).

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

Вопрос - что делать - можно ли встроить в программу функционал - чтобы пользователи могли сами делать backup&restore (причём делать это нужно с защитой от дурака и кривых рук, сложности могут быть еще в том, что для Firebird характерна проблема невосстановимых бэкапов и т. д.)

Если с автоматическим функционалом bvackup&restore сложности - есть ли какая-нибудь команда СУБД Firebird - чтобы не прибегая к backup&restore можно было ускорить работу базы данных, проведя её дефрагментацию и возможно, переиндексацию?
18 ноя 21, 14:04    [22397489]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
wadman
Member

Откуда: Санкт-Петербург
Сообщений: 27313
Наталья87
При этом если сделать backup&restore - скорость работы программы возвращается к нормальной, размер базы становится в несколько раз меньше (например, был 600 Мб, стал 150 Мб).

Размер базы не влияет на скорость работы программы. Именно так, чтоб в разы и заметно на глаз.

Индексы нужно смотреть. Планы. Искать, где сканы без индексов и либо переделывать запросы, либо доделывать индексы.

В общем, нет панацеи. Нужна долгая и вдумчивая работа. Или специалист со стороны.
18 ноя 21, 14:14    [22397497]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
wadman
Member

Откуда: Санкт-Петербург
Сообщений: 27313
wadman
Размер базы не влияет на скорость работы программы. Именно так, чтоб в разы и заметно на глаз.

Уточню: у грамотно спроектированной базы.
18 ноя 21, 14:18    [22397502]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Олег Третьяков
Member

Откуда: Москва
Сообщений: 167
Наталья87
Вопрос - что делать - можно ли встроить в программу функционал - чтобы пользователи могли сами делать backup&restore (причём делать это нужно с защитой от дурака и кривых рук...


Наталья87
Особенно если программа настроена на работу не в режиме embedded, а в режиме работы с несколкьих компьютеров с единой базой данных.

На пользователей надёжи - мало. Нанять(назначить) прямые руки, называются DBA. Дать задание написать скрипт, делающий: 1.Регулярные бэкапы и складывающий в их укромное место. 2. Рестор из последнего бэкапа. 3.Запуск по шедулеру в техническое окно.
18 ноя 21, 14:26    [22397508]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
wadman
wadman
Размер базы не влияет на скорость работы программы. Именно так, чтоб в разы и заметно на глаз.

Уточню: у грамотно спроектированной базы.


Так как вызвать backup&restore?
Или сборщик мусора sweep?
Или дефрагментацию/переиндексацию?

Каким-нибудь системным запросом? Это возможно?
18 ноя 21, 14:27    [22397509]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
Олег Третьяков
Нанять(назначить) прямые руки, называются DBA. Дать задание написать скрипт, делающий: 1.Регулярные бэкапы и складывающий в их укромное место. 2. Рестор из последнего бэкапа. 3.Запуск по шедулеру в техническое окно.


Дело в том, что устанавливают программу сами пользователи. А прямых рук у них нет. И возникает вопрос - как обслуживать базу автоматически. Или одной кнопкой из приложения - которую нажал бы пользователь.
18 ноя 21, 14:28    [22397511]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
_Vasilisk_
Member

Откуда: Украина, Харьков
Сообщений: 13358
Наталья87
Дело в том, что устанавливают программу сами пользователи. А прямых рук у них нет.
А пишет программу программист. Но если программист пишет
Наталья87
А от Firebird мне трудно отказаться будет. У меня такой код, что открывает транзакции, которые долго висят - например, в ожидании диалогов пользователя. Очень удобно. Firebird многоверсионник легко такое переваривает
и этому программисту многократно говорят так не делать, то кто ему доктор?
18 ноя 21, 14:32    [22397514]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54790

Наталья87
Дело в том, что устанавливают программу сами пользователи. А прямых рук у них нет.

А им и не нужно. Прямые руки должны быть у разработчика базы и приложения.

Posted via ActualForum NNTP Server 1.5

18 ноя 21, 14:35    [22397516]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
wadman
Member

Откуда: Санкт-Петербург
Сообщений: 27313
Наталья87
wadman
пропущено...

Уточню: у грамотно спроектированной базы.


Так как вызвать backup&restore?
Или сборщик мусора sweep?
Или дефрагментацию/переиндексацию?

Каким-нибудь системным запросом? Это возможно?

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

ЗЫ. Бекап нужно делать по расписанию в шедулере сервера, а не приложением. Или что, каждый пользователь будет делать бекап только для себя и себе?
18 ноя 21, 14:44    [22397521]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
DmSer
Member

Откуда: Пенза
Сообщений: 1457
Наталья87
При работе моего приложения со временем растет размер базы данных Firebird.

Например, за полгода работы размер может вырасти до 600 мегабайт.
Проблема в том, что программа начинает тормозить, причем работать может в 10 раз медленнее, чем изначально.

При этом если сделать backup&restore - скорость работы программы возвращается к нормальной, размер базы становится в несколько раз меньше (например, был 600 Мб, стал 150 Мб).

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

Вопрос - что делать - можно ли встроить в программу функционал - чтобы пользователи могли сами делать backup&restore (причём делать это нужно с защитой от дурака и кривых рук, сложности могут быть еще в том, что для Firebird характерна проблема невосстановимых бэкапов и т. д.)

Если с автоматическим функционалом bvackup&restore сложности - есть ли какая-нибудь команда СУБД Firebird - чтобы не прибегая к backup&restore можно было ускорить работу базы данных, проведя её дефрагментацию и возможно, переиндексацию?


Сталкивались с такими проблемами. Знаем. Решается просто: разделяем транзакции для чтения и записи. Для чтения можно использовать длинную транзакцию, она не повлияет на накопление мусора в БД. Для записи используем короткие транзакции, которые запускаем только на момент записи в БД. Мусор в этом случае не копится. База не тормозит.
18 ноя 21, 15:07    [22397531]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
DmSer
Member

Откуда: Пенза
Сообщений: 1457
И ещё использовать нужно SSD, иначе, если используется HDD, то тормоза будут связаны с медленным доступом к информации на диске, причем чем дольше база работает, тем больше степень её фрагментированности, тем дольше её страницы читаются из HDD.
18 ноя 21, 15:09    [22397536]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
sg729
Member

Откуда:
Сообщений: 65
Наталья87,
Для начала попробуйте проанализировать результат gstat.exe -a -r
Или почитайте здесь : 45 способов улучшить производительность Firebird
В некоторых случаях может помочь обновление статистики индексов.
18 ноя 21, 15:22    [22397542]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
DmSer
И ещё использовать нужно SSD, иначе, если используется HDD, то тормоза будут связаны с медленным доступом к информации на диске, причем чем дольше база работает, тем больше степень её фрагментированности, тем дольше её страницы читаются из HDD.


Это всё понятно. Но вопрос в другом. Как при текущих базе данных и программе из приложения на Delphi выполнить оптимизацию базы данных в автоматическом режиме? Backup&Restore то помогает - причём делать достаточно раз в полгода - то есть не всё так плохо.
18 ноя 21, 15:22    [22397543]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54790

Наталья87
Как при текущих базе данных и программе из приложения на Delphi выполнить
оптимизацию базы данных в автоматическом режиме?

Никак, обломитесь.

Posted via ActualForum NNTP Server 1.5

18 ноя 21, 15:29    [22397549]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
sg729
Наталья87,
Для начала попробуйте проанализировать результат gstat.exe -a -r
Или почитайте здесь : 45 способов улучшить производительность Firebird
В некоторых случаях может помочь обновление статистики индексов.


ОК, спасибо
18 ноя 21, 15:45    [22397556]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54790

sg729
Или почитайте здесь

Ссылку следовало назвать "45 танцев дождя для начинающих шаманов".

Posted via ActualForum NNTP Server 1.5

18 ноя 21, 15:54    [22397558]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
Dimitry Sibiryakov

Наталья87
Как при текущих базе данных и программе из приложения на Delphi выполнить
оптимизацию базы данных в автоматическом режиме?

Никак, обломитесь.


Не угадали.
select RDB$INDEX_NAME s from RDB$INDICES where RDB$INDEX_NAME not like ''RDB$%''

а потом

alter index .... inactive
alter index .... active

для каждого индекса помогло - хоть и меньше чем backup&restore - но ускорение есть

Ну и еще вызов

gfix.exe" -sweep "......." -user SYSDBA -password masterkey

через ShellExecute

Единственное хотелось бы обойтись без вызова gfix.exe ну и базу уменьшать в горячем режиме научиться (насколько знаю, MS SQL Server умеет, а Firebird так не может ...)
18 ноя 21, 16:08    [22397569]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54790

Наталья87
Не угадали.

Да нет, это вы не угадали.

1. Статистика собирается совсем другим запросом и её сбор не требует блокировки
таблиц на запись.
2. Sweep не нужен если счётчики транзакций не застряли.

Но продолжайте плясать, дождь может скоро начаться.

Posted via ActualForum NNTP Server 1.5

18 ноя 21, 16:15    [22397571]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Vlad F
Member

Откуда:
Сообщений: 1451
Наталья87,

В горячем - не в горячем, но если очень хочется, то кое-что можно и прямо из приложения.
Взгляните на возможности IBX.IBServices.TIBBackupService\TIBRestoreService.
И не забудьте перед использованием закрыть основной коннект приложения.))

Сообщение было отредактировано: 18 ноя 21, 16:22
18 ноя 21, 16:21    [22397576]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
Dimitry Sibiryakov

1. Статистика собирается совсем другим запросом и её сбор не требует блокировки
таблиц на запись.


set statistics index
тоже присобачим


Dimitry Sibiryakov

2. Sweep не нужен если счётчики транзакций не застряли.


Будем на всякий случай делать. При каждом запуске программы (может, даже в отдельном потоке). Хуже ведь не станет?
18 ноя 21, 16:55    [22397602]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54790

Наталья87
Хуже ведь не станет?

Станет. Особенно "при каждом запуске программы".

Posted via ActualForum NNTP Server 1.5

18 ноя 21, 17:02    [22397611]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
fraks
Member

Откуда: Новосибирск
Сообщений: 1836
Судя по тому что у вас раздувается размер базы, но после бэкапа-рестора она сильно сдувается - у вас в базе накапливается много мусора. Мусор накапливается из-за некорректной работы программы, точнее программиста этой программы, с транзакциями.

Смотрите в статистике базы данных какой разрыв между номерами транзакций OIT и OAT.
Если разрыв больше 5000 - уже повод что-то делать, а если разрыв 50 тысяч и больше - то все плохо.

Если вы не в состоянии переписать программу что бы более корректно работала с транзакциями - то хотя бы сделайте орг. метод - не допускайте длительной работы программы, особенно несколько дней подряд. Перезапускайте их - застрявшие транзакции будут отпускаться и мусор собранный ими будет вычищаться в процессе работы с базой.
18 ноя 21, 17:49    [22397640]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
fraks
Если вы не в состоянии переписать программу что бы более корректно работала с транзакциями - то хотя бы сделайте орг. метод - не допускайте длительной работы программы, особенно несколько дней подряд. Перезапускайте их - застрявшие транзакции будут отпускаться и мусор собранный ими будет вычищаться в процессе работы с базой.


Или хотя бы утечки памяти не устранять. Тогда пользователи будут вынуждены сами перезапускать программу 2 раза в день. Шутка Картинка с другого сайта.

Сообщение было отредактировано: 18 ноя 21, 19:48
18 ноя 21, 19:48    [22397684]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
Наталья87
Например, за полгода работы размер может вырасти до 600 мегабайт.

не смешите меня, пожалуйста. Мы сопровождаем десятки серверов с Firebird где базы по 400-500 ГИГАБАЙТ. Остальные сопровождаемые сотни серверов меньше 400 гиг, и единицы серверов с трерабайтными БД.
Наталья87
При этом если сделать backup&restore - скорость работы программы возвращается к нормальной, размер базы становится в несколько раз меньше (например, был 600 Мб, стал 150 Мб).

а потом ФБ и операционная система будут пыжиться, опять расширяя базу до 600мб. Пустое место в базе используется повторно.
Не надо сожалеть о "впустую потраченных мегабайтах", их просто не существует.
Наталья87
Но Firebird - насколько я знаю - не поддерживает горячее восстановление баз данных.

встроенная репликация поддерживается для 2.5 и 3.0 в HQbird, и есть в стандартном Firebird 4. Можно сделать standby кластер.
Наталья87
Вопрос - что делать - можно ли встроить в программу функционал - чтобы пользователи могли сами делать backup&restore

для однопользовательских приложений - ОДНОЗНАЧНО. Не можно, а нужно. К нам регулярно такие пользователи обращаются за ремонтом БД, починить можно процентов 70 баз, но часть данных теряется всегда, а 30% баз в мусорку отправляются.
Наталья87
можно было ускорить работу базы данных, проведя её дефрагментацию и возможно, переиндексацию?

извините, чушь какая-то. База данных это файл с random access, принципиально. Поэтому никакая "дефрагментация" ему не нужна, и "переиндексация" тем более. Зачем "переиндексация" вообще?
18 ноя 21, 21:53    [22397706]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
Наталья87
alter index .... inactive
alter index .... active

для каждого индекса помогло - хоть и меньше чем backup&restore - но ускорение есть

alter index inactive не нужно, потому что active и так индекс перестроит.
То, что "помогло" - видимо статистика по индексам не пересчитывается. А перестраивать индексы было необязательно.
Насчет того, что backup/restore "помогает" - это только кажется. Тем более при вашей микроскопической базе в 600мб это вообще ни о чем. Если у вас при такой базе б/р помогает ускорить что-то, то или у вас база на древнем hdd, или запросы настолько КРИВЫЕ (или нет нужных индексов), что бороться надо (как тут уже сказали) именно за планы запросов.

Ну и см. 22397640. Правда, опять же - база 600мб, и влияние "мусора" - это что-то невообразимое. Но да - транзакциями надо управлять. А в однопользовательских базах проблем с "мусором" не должно быть по определению.
18 ноя 21, 22:00    [22397708]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
Наталья87
Так как вызвать backup&restore?
Или сборщик мусора sweep?
Или дефрагментацию/переиндексацию?

вы на IBX, и про services api ничего не слышали? Фантастика.
http://www.ibase.ru/ibx#servapi

я этот документ написал и опубликовал 15 лет назад.
18 ноя 21, 22:01    [22397709]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
fraks
Судя по тому что у вас раздувается размер базы, но после бэкапа-рестора она сильно сдувается - у вас в базе накапливается много мусора. Мусор накапливается из-за некорректной работы программы, точнее программиста этой программы, с транзакциями.

Смотрите в статистике базы данных какой разрыв между номерами транзакций OIT и OAT.
Если разрыв больше 5000 - уже повод что-то делать, а если разрыв 50 тысяч и больше - то все плохо.

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


На примере висячей базы данных размером в 2 Гб:

Oldest transaction 9600032
Oldest active 9607730
Oldest snapshot 9607730
Next transaction 9607732

Разница 7 с половиной тысяч. После выполнения Sweep (с помощью вызова gfix) и выполнения set inactive index, set active index, set statistics index для всех индексов действительно база стала работать существенно быстрее и разница стала в пределах пары сотен. Даже без прибегания к средству в виде backup&restore. Размер 2 Гб как был, так и остался, но работать стало быстрее (ну и пусть будет 2 Гб в таком случае как я понимаю уменьшить всё равно без backup&restore не выйдет). Все-таки получится значит пользователя сделать счастливым с быстрой базой нажатием одной кнопки в программе.
18 ноя 21, 22:03    [22397711]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
kdv

а потом ФБ и операционная система будут пыжиться, опять расширяя базу до 600мб. Пустое место в базе используется повторно.
Не надо сожалеть о "впустую потраченных мегабайтах", их просто не существует.

извините, чушь какая-то. База данных это файл с random access, принципиально. Поэтому никакая "дефрагментация" ему не нужна, и "переиндексация" тем более. Зачем "переиндексация" вообще?


Но тогда почему backup&restore помогает существенно ускорить работу с базой данных? И даже переиндексация помогает ...
18 ноя 21, 22:05    [22397714]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
Наталья87
разница стала в пределах пары сотен

вас должна интересовать разница между Next transaction и Oldest Active. А она свипом не "убирается". И у вас ее (разницы Next-OAT) практически нет.
С другой стороны, если вы массово обновили данные, а потом запустили отчет - да, отчет будет "собирать" мусор, но это не значит, что свип надо запускать перед каждым отчетом.
Наталья87
уменьшить всё равно

да забудьте вы про "уменьшение базы", пожалуйста. Вы не представляете себе как организована БД внутри, и беспокоитесь об ее уменьшении...

К примеру, тут как-то была жалоба от пользователя - почему при базе в 100мб при выполнении отчета в программе генерится временный файл размером 1 гигабайт. Ну, такой дурацкий запрос написан.
18 ноя 21, 22:11    [22397716]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
kdv

Тем более при вашей микроскопической базе в 600мб это вообще ни о чем. Если у вас при такой базе б/р помогает ускорить что-то, то или у вас база на древнем hdd, или запросы настолько КРИВЫЕ (или нет нужных индексов), что бороться надо (как тут уже сказали) именно за планы запросов.


Ну разумеется, у пользователей не самые новые компы. Pentium 4 с 1-2 Гб оперативы это нормально и HDD не самые новые. И 2 Гб база для них тяжело. Индексы нужные есть - даже местами чересчур.

Backup&Restore помогает в большинстве случаев. Если не помогает - рекомендация пользователю одна - выгрузить то, что нужно из старой базы, загрузить в чистую, свежую и снова быстро работать несколько месяцев с базой в пределах 100 Мб. Вопрос возник по той причине, что юзеры не хотят платить за backup&restore считают, что замедление работы специально встроено в программу, чтобы брать деньги за ускорение (а на самом деле специального замедления нет - это просто кривой код). Поэтому чтобы таких вопросов небыло встроим sweep и переиндексацию в приложение.
18 ноя 21, 22:12    [22397718]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
Наталья87
существенно ускорить работу с базой данных

существенно - это как? Например, дайте select count по вашей самой большой таблице в 600мб или 2 гиг базах, и приведите сюда сколько запрос выполняется, и сколько page reads.
Наталья87
Pentium 4 с 1-2 Гб оперативы это нормально

где нормально - на таком компе нынче даже в браузере тяжело работать, тупо медленно.

Сообщение было отредактировано: 18 ноя 21, 22:14
18 ноя 21, 22:12    [22397719]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
kdv

существенно - это как? Например, дайте select count по вашей самой большой таблице в 600мб или 2 гиг базах, и приведите сюда сколько запрос выполняется, и сколько page reads.


Видимо, после backup&restore ускорение произошло не благодаря уменьшению размера базы, а по другим причинам.

Идеи уменьшения размера базы (и мысли о том, что всё зависит от размера базы данных) пошли от того, что изначально, с пустой базой приложение работает очень быстро, а по мере наполнения базы начинает замедляться.
18 ноя 21, 22:27    [22397724]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54790

Наталья87
Pentium 4 с 1-2 Гб оперативы это нормально и HDD не самые новые. И 2 Гб база для
них тяжело.

База размером меньше ОЗУ "тяжело"? Вот так и рождается мифический "хайлоад"...

Posted via ActualForum NNTP Server 1.5

18 ноя 21, 23:06    [22397732]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
Dimitry Sibiryakov

Наталья87
Pentium 4 с 1-2 Гб оперативы это нормально и HDD не самые новые. И 2 Гб база для
них тяжело.

База размером меньше ОЗУ "тяжело"? Вот так и рождается мифический "хайлоад"...


А зачем сравнивать размер базы с размером ОЗУ? Выше же ответили, что размер базы не влияет ...
18 ноя 21, 23:11    [22397735]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4936
Наталья87
Как при текущих базе данных и программе из приложения на Delphi выполнить оптимизацию базы данных в автоматическом режиме?
Уже и в этой теме несколько раз повторили.
Не держать длинные пишущие транзакции.
И всё, это решит все твои проблемы (описанные в этой теме)
18 ноя 21, 23:26    [22397740]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4936
Наталья87
select RDB$INDEX_NAME s from RDB$INDICES where RDB$INDEX_NAME not like ''RDB$%''

а потом

alter index .... inactive
alter index .... active

для каждого индекса помогло - хоть и меньше чем backup&restore - но ускорение есть
Это не поможет решить основную проблему

Наталья87
Ну и еще вызов

gfix.exe" -sweep "......." -user SYSDBA -password masterkey

через ShellExecute

Это не поможет, если в это время висят старые пишущие транзакции.
Хоть через ShellExecute запускай, хоть через ShellExecuteEx.
18 ноя 21, 23:28    [22397742]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
Наталья87
а по мере наполнения базы начинает замедляться.

дык. например, сумма по продажам. Сегодня их 100, завтра 200, к концу года 36500. Через 3 года - в 3-4 раза больше.
Если каждый раз считать сумму по этим одним и тем же данным, то к гадалке не ходи - будет медленнее и медленнее.
Поэтому... что? надо менять схему подсчета по сырым данным - добавлять хранимые агрегаты, и прочее.
Например, зачем делается в бухгалтерском ПО "закрытие месяца"? Как минимум, чтобы не считать всю эту фигню каждый раз.

Насчет памяти - база не обязана "влезать в ОЗУ", конечно. Но если у вас запросы с сортировками, то на 2гиг RAM они могут "вышибать" (кэшем ОС) память приложений (и ФБ), в результате чего начинается свопирование и прочие тормоза. И их причина - не в FB, а банально в том, что 2 гиг памяти уже давно даже не минимум, а я не знаю что.
Продумайте минимальные требования к железу для вашего ПО. Если клиент такой нищий, что не может докупить 2-6 гиг памяти, то зачем он вам нужен? Более того, подавляющее количество контор скорее заплатит за апгрейд железа, чем за какой-то софт (и тем более его поддержку).
18 ноя 21, 23:33    [22397745]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
white_nigger
Member

Откуда: Тула
Сообщений: 2654
Скорее всего при таком объеме оперативы при росте базы тупо перестаёт хватать памяти на дисковое кеширование винды (+еще внутренние кеши FB) и запросы просаживаются из-за возросших дисковых операций и своппинга оперативы
19 ноя 21, 03:15    [22397760]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
fraks
Member

Откуда: Новосибирск
Сообщений: 1836
Если не рассматривать вопроса раздутия базы каким-то мусором, можно посмотреть на план "тормозящих" запросов.
Т.е. выполнить тормозящий запрос из IBExpert и посмотреть насколько у него кривой план.
И возможно поможет прикручивание хинтов типа +0" или ||''

У меня бывало что при росте базы оптимизатор начинал выдумывать новые планы которые сильно тормозили до этого нормально работающий запрос.
19 ноя 21, 04:10    [22397761]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
wadman
Member

Откуда: Санкт-Петербург
Сообщений: 27313
Наталья87
Идеи уменьшения размера базы (и мысли о том, что всё зависит от размера базы данных) пошли от того, что изначально, с пустой базой приложение работает очень быстро, а по мере наполнения базы начинает замедляться.

Потому что индексы. Планы нужно смотреть.
19 ноя 21, 08:21    [22397777]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4936
wadman
Наталья87
Идеи уменьшения размера базы (и мысли о том, что всё зависит от размера базы данных) пошли от того, что изначально, с пустой базой приложение работает очень быстро, а по мере наполнения базы начинает замедляться.

Потому что индексы. Планы нужно смотреть.
Если база после б/р уменьшается в 4 раза - значит, много мусора.
Кроме того, если индексы создаются перед наполнением таблиц - статистика у них будет нулевой, и планы будут почти рандомные.
Надо статистику у индексов через какой-то промежуток работы обновлять.
19 ноя 21, 08:49    [22397783]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
wadman
Member

Откуда: Санкт-Петербург
Сообщений: 27313
YuRock
wadman
пропущено...

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

Если я удалю половину базы, то она уменьшится?

Я не телепат и не знаю, что там за база и какая/как с ней идёт работа. Поэтому про мусор выводы неоднозначные. А то, что после б/р начинает летать и снова тормозит, когда база распухнет для меня однозначно говорит, что там планы страшные.

Но ТС нам ничего не покажет.
19 ноя 21, 09:03    [22397785]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
YuRock
Наталья87
select RDB$INDEX_NAME s from RDB$INDICES where RDB$INDEX_NAME not like ''RDB$%''

а потом

alter index .... inactive
alter index .... active

для каждого индекса помогло - хоть и меньше чем backup&restore - но ускорение есть
Это не поможет решить основную проблему

Наталья87
Ну и еще вызов

gfix.exe" -sweep "......." -user SYSDBA -password masterkey

через ShellExecute

Это не поможет, если в это время висят старые пишущие транзакции.
Хоть через ShellExecute запускай, хоть через ShellExecuteEx.


Ну программа перезапускается раз в сутки. Комп выключается на ночь. Откуда там висящим транзакциям быть? В моем случае помогло, всё быстрее стало работать. От идей уменьшения файла базы отказалась.
19 ноя 21, 09:44    [22397796]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4936
wadman
Если я удалю половину базы, то она уменьшится?
А при чём тут удаление? Б/р ничего не удаляет, кроме мусора.

wadman
А то, что после б/р начинает летать и снова тормозит, когда база распухнет для меня однозначно говорит, что там планы страшные.
Да нет, кол-во "рабочих" записей-то не меняется до удаления мусора и после, а летать начинает, с теми же планами.
Просто мусора много, и он не чистится из-за висячих транзакций.

И статистика у индексов после б/р уже нормально рассчитанная, т.ч. на нее можно не грешить особо.
19 ноя 21, 09:56    [22397806]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4936
Наталья87
YuRock
пропущено...
Это не поможет решить основную проблему

пропущено...

Это не поможет, если в это время висят старые пишущие транзакции.
Хоть через ShellExecute запускай, хоть через ShellExecuteEx.


Ну программа перезапускается раз в сутки. Комп выключается на ночь. Откуда там висящим транзакциям быть? В моем случае помогло, всё быстрее стало работать. От идей уменьшения файла базы отказалась.
А, ну если клиенты все отваливаются на ночь, то повесь в планировщик на сервере запуск sweep на час ночи, да и всё.
sweep interval можно отключить тогда (через gfix установить 0), если вручную запускать будешь.
19 ноя 21, 10:00    [22397808]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
YuRock
А, ну если клиенты все отваливаются на ночь, то повесь в планировщик на сервере запуск sweep на час ночи, да и всё.


Повесить в планировщик будут сложности, тк юзеры сами устанавливают софт. И для них это будет нестандартной задачей, на которую они будут забивать. В час ночи всё отключено (и сервер тоже) и скрипт в планировщике не запустится.

Потому и хочу сделать - если программа запускается НА СЕРВЕРЕ (где база, сервер - это обычный компьютер, где тоже используется программа) - при запуске программы пусть выполняется этот самый sweep через gfix.exe. Надеюсь, ничего плохого не случится если случайно окажется, что к базе подсоединены в этот момент клиенты (просто очистка должным образом не выполнится).

Сообщение было отредактировано: 19 ноя 21, 10:11
19 ноя 21, 10:10    [22397820]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4936
Наталья87

Потому и хочу сделать - если программа запускается НА СЕРВЕРЕ (где база, сервер - это обычный компьютер, где тоже используется программа) - при запуске программы пусть выполняется этот самый sweep через gfix.exe. Надеюсь, ничего плохого не случится если случайно окажется, что к базе подсоединены в этот момент клиенты (просто очистка должным образом не выполнится).

Это плохая идея.
19 ноя 21, 10:14    [22397822]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
YuRock
Наталья87

Потому и хочу сделать - если программа запускается НА СЕРВЕРЕ (где база, сервер - это обычный компьютер, где тоже используется программа) - при запуске программы пусть выполняется этот самый sweep через gfix.exe. Надеюсь, ничего плохого не случится если случайно окажется, что к базе подсоединены в этот момент клиенты (просто очистка должным образом не выполнится).

Это плохая идея.


А к чему плохому это может привести?

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

Но set statistics index при каждом 10-м запуске программы (чтобы не нервировать пользователей - при каждом запуске не стоит, наверное это делать) ведь не повредит?

P. S. При каждом десятом запуске - чтобы не заморачиваться и определить десятый ли запуск думаю сделать что-то типа if random(10)=9 then ...
19 ноя 21, 10:20    [22397825]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
Наталья87,

Тут проблема в том, что если
- в однопользовательском варианте вы можете и свип запускать из приложения (не через гфикс), и бэкап делать тоже (не через гбак).
- в многопользовательском приложении запускать гбак или гфикс, или пересчитывать статистику через какие-то интервалы - значит у вас в КАЖДОМ приложении такое возможно, а значит вы будете "долбить" сервер этими задачами, причем только в момент работы пользователей. В многопользовательском случае по любому нужен админ, и настройка бэкапов и свипов именно на сервере.

p.s. так что там с 22397719
19 ноя 21, 11:01    [22397852]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
X11
Member

Откуда: Kharkiv, Ukraine
Сообщений: 15425
DmSer
Сталкивались с такими проблемами. Знаем. Решается просто: разделяем транзакции для чтения и записи. Для чтения можно использовать длинную транзакцию, она не повлияет на накопление мусора в БД. Для записи используем короткие транзакции, которые запускаем только на момент записи в БД. Мусор в этом случае не копится. База не тормозит.


Зачем дальнейшая дискуссия и танцы з бубном после этого сообщения?

Читающая транзакция должна быть readonly.
При открытии окна добавления/редактирования товара/объекта не открывать ничего на запись. А вот, когда пользователь нажимает сохранить и выполняется Commit, то для этого использовать пишущую транзакцию. т.е. пишущая транзакция - для записи данных и она - максимально короткая.

У вас накаливается много-много мусора, вероятно из-за того, что вы используете пишущие транзакции для чтения и потом их не подтверждаете, не откатываете.

Сообщение было отредактировано: 19 ноя 21, 11:25
19 ноя 21, 11:23    [22397861]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4936
Наталья87
А к чему плохому это может привести?
К тормозам, которые вы пытаетесь избежать. Вам уже ответили Сибиряков и kdv. Это идиотизм - запускать при каждом запуске программы долгую тяжелую операцию.

Наталья87
Ну не буду тогда это делать. Тем более похоже на то, что sweep не очень то и нужен раз все компы и так выключаются раз в сутки.

Он как раз очень нужен. Ведь это единственный вариант собрать мусор для вас (кроме backup-restore, что еще дольше), раз вы программу не можете переделать в пристойное состояние.

Наталья87
Но set statistics index при каждом 10-м запуске программы (чтобы не нервировать пользователей - при каждом запуске не стоит, наверное это делать) ведь не повредит?

Повредит по тем же причинам - бесполезные тормоза.
Статистику чаще всего достаточно считать один раз - после наполнения базы данными.
Либо вообще 0 раз, если создавать индексы после наполнения базы данными (как делает restore, например).
У вас, видимо, ни разу не считалась на той базе, на которой помогло ускорить.
Да, бывают случаи, когда полезно статистику обновить раз в месяц или около того. Накопление данных может изменить статистику и планы. Но это не ваш случай.
Ну и делать это нужно на сервере, опять же, ночью, ведь это тормозит, а у вас этого нет.

Хотите, раз для вас это допустимо (базы у вас, я так понял, крохотные), делайте backup-restore еженедельно, да и всё. Отмечайте в реестре дату последнего успешного, и проверяйте, чтоб это был 7-й день с тех пор.
Запускайте только на компьютере, где база.
Предварительно остановив службу Firebird и переименовав файл базы.
Ну, что ж. Зато не надо swwep запускать и set stat :))
19 ноя 21, 11:43    [22397870]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
X11
пишущая транзакция - для записи данных и она - максимально короткая.

а потом приходит какой-нибудь чел, лезет ИБЭкспертом в промышленную базу с 500 одновременных пользователей, выполняет там какой-нибудь запрос и бросает ИБЭксперт на пару суток.
И через сутки-двое начинаются вопли "у нас всё тормозит". Если в конторе есть кто-то умный, который знает про mon$ - смотрит и находит негодяя по IP, ИБэксперт отрубают, и дают тому канделябром по башке.
Иногда после этого пишут скрипт, который раз в 1-2 часа отрубает все коннекты, где имя процесса - ibexpert.exe.
Как-то так.
19 ноя 21, 12:04    [22397879]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
kdv
Наталья87,

Тут проблема в том, что если
- в однопользовательском варианте вы можете и свип запускать из приложения (не через гфикс), и бэкап делать тоже (не через гбак).
- в многопользовательском приложении запускать гбак или гфикс, или пересчитывать статистику через какие-то интервалы - значит у вас в КАЖДОМ приложении такое возможно, а значит вы будете "долбить" сервер этими задачами, причем только в момент работы пользователей. В многопользовательском случае по любому нужен админ, и настройка бэкапов и свипов именно на сервере.

p.s. так что там с 22397719


Ну у нас "сервер" только в кавычках. Не какая-то там высоконагруженная система, а программка на 1-3 компьютера. Ну максимум 8. Там где больше 3 компьютеров по любому есть какой нибудь админ и наверное автоматические свипы не нужны ...
19 ноя 21, 12:05    [22397881]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
энди
Member

Откуда: Киров, Россия
Сообщений: 1299
Я правильно понимаю что Вы стартуете транзакцию, а потом вываливаете пользователю диалоговое окно и в это время у вас все еще болтается открытая транзакция?
19 ноя 21, 13:25    [22397926]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54790

YuRock
sweep interval можно отключить тогда (через gfix установить 0)

Не надо обезьянам давать ЭТУ гранату. Уже были прецеденты - угробит базу.

Posted via ActualForum NNTP Server 1.5

19 ноя 21, 13:33    [22397930]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
энди
Я правильно понимаю что Вы стартуете транзакцию, а потом вываливаете пользователю диалоговое окно и в это время у вас все еще болтается открытая транзакция?


Да. Но это не часами длится. Обычно не более 1 минуты, а при нормальной работе секунд 10-15. Очень удобно - если произошла ошибка или пользователь нажал "Отменить" - просто делаем Rollback и всё.
19 ноя 21, 13:42    [22397934]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
Dimitry Sibiryakov

YuRock
sweep interval можно отключить тогда (через gfix установить 0)

Не надо обезьянам давать ЭТУ гранату. Уже были прецеденты - угробит базу.


И правда - да пусть чистится и автоматически тоже. Жалко чтоли.
А как базу можно этим угробить? Разве что тормозить база начнёт.
А угробить базу из практики можно если нет ИБП и мигает свет, либо бэд-блоки на винте, либо очень редко - при сбоях оперативной памяти.
19 ноя 21, 13:45    [22397936]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54790

Наталья87
А как базу можно этим угробить? Разве что тормозить база начнёт.

Да, именно тормозить начнёт. До такой степени, что разработчика увольняют, а
систему мигрируют на другую СУБД.

Posted via ActualForum NNTP Server 1.5

19 ноя 21, 13:47    [22397937]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
X11
DmSer
Сталкивались с такими проблемами. Знаем. Решается просто: разделяем транзакции для чтения и записи. Для чтения можно использовать длинную транзакцию, она не повлияет на накопление мусора в БД. Для записи используем короткие транзакции, которые запускаем только на момент записи в БД. Мусор в этом случае не копится. База не тормозит.


Зачем дальнейшая дискуссия и танцы з бубном после этого сообщения?

Читающая транзакция должна быть readonly.
При открытии окна добавления/редактирования товара/объекта не открывать ничего на запись. А вот, когда пользователь нажимает сохранить и выполняется Commit, то для этого использовать пишущую транзакцию. т.е. пишущая транзакция - для записи данных и она - максимально короткая.

У вас накаливается много-много мусора, вероятно из-за того, что вы используете пишущие транзакции для чтения и потом их не подтверждаете, не откатываете.


Даже не знаю, какие транзакции Delphi использует при работе с TIBTransaction, TIBQuery. Судя по всему - по умолчанию транзакции вида Snapshot. Вполне возможно, что пишущие используются для чтения. Вот только я после чтения их всё равно освобождаю (Free) - надеюсь, это решает проблему. Free делать приходится - так как иначе утечки памяти очень быстро копятся и потребляют все ресурсы компьютера.
19 ноя 21, 13:48    [22397938]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
Dimitry Sibiryakov

Наталья87
А как базу можно этим угробить? Разве что тормозить база начнёт.

систему мигрируют на другую СУБД.


Это нереально. Тем более с вашим подходом "переводите по одной форме с IBX на FireDAC как раз до конца жизни за год и успеете. Перевести 400 тысяч строк кода - тем более что там куча быдлокода и говнокода на другую СУБД невозможно, либо оно того не стоит.

Скорее пользователи в этом случае сделают backup&restrore, поставят помощнее комп или в самом крайнем случае начнут с чистой базы данных.
19 ноя 21, 13:51    [22397940]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54790

Наталья87
Это нереально.

Целый фейсбук переводили на другую СУБД несколько раз. Думаете, у них меньше
говнокода, чем у вас?..

Posted via ActualForum NNTP Server 1.5

19 ноя 21, 13:55    [22397943]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
Dimitry Sibiryakov

Наталья87
Это нереально.

Целый фейсбук переводили на другую СУБД несколько раз. Думаете, у них меньше
говнокода, чем у вас?..


Но там и бюджеты и масштабы другие. В наших небольших проектах не знаю стоит ли оно того ...
19 ноя 21, 14:09    [22397948]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54790

В ваших небольших бюджетах обычно просто берут 1С.

Posted via ActualForum NNTP Server 1.5

19 ноя 21, 14:11    [22397950]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
goldmi45
Member

Откуда:
Сообщений: 1288
Наталья87
энди
Я правильно понимаю что Вы стартуете транзакцию, а потом вываливаете пользователю диалоговое окно и в это время у вас все еще болтается открытая транзакция?


Да. Но это не часами длится. Обычно не более 1 минуты, а при нормальной работе секунд 10-15. Очень удобно - если произошла ошибка или пользователь нажал "Отменить" - просто делаем Rollback и всё.

Не делайте так никогда. Это вы думаете, что не более 1 минуты, а пользователь, открыв диалог, отвлёкся, потом пошёл на обед. И в итоге транзакция может висеть очень долго.
Пишущая транзакция должна быть по времени максимально короткой. Стартовать в момент, когда пользователь нажал "Сохранить".
Дайте угадать, вы используете DBWare-компонеты, типа TDBEdit и поэтому не можете отказаться от старта транзакции перед изменением данных?
19 ноя 21, 14:26    [22397958]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54790

goldmi45
Это вы думаете, что не более 1 минуты, а пользователь, открыв диалог, отвлёкся,
потом пошёл на обед. И в итоге транзакция может висеть очень долго.

Приведённые ею статистики такого не показывают.

Posted via ActualForum NNTP Server 1.5

19 ноя 21, 14:34    [22397965]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
goldmi45
Member

Откуда:
Сообщений: 1288
Dimitry Sibiryakov

goldmi45
Это вы думаете, что не более 1 минуты, а пользователь, открыв диалог, отвлёкся,
потом пошёл на обед. И в итоге транзакция может висеть очень долго.

Приведённые ею статистики такого не показывают.

Я лишь сказал, что не нужно начинать транзакцию при открытии диалога.
К тому же неизвестно, в какой момент эти статистики были собраны. Может быть, автоматический сборщик мусора запустился и всё колом встало.
19 ноя 21, 14:49    [22397977]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54790

goldmi45
Может быть, автоматический сборщик мусора запустился и всё колом встало.

Если запустился автосвип (который часто путают со сборщиком мусора), то это
должно быть отражено в firebird.log. И "колом встало" при его работе это не про
приложение на полтора пользователя, там нужна гораздо более интенсивная нагрузка.

Запуск автосвипа неизбежен после отключения электричества, но я не слышал
упоминаний от аффтарши о "база тормозит после отключения электричества", только
"через некоторое время".

Posted via ActualForum NNTP Server 1.5

19 ноя 21, 14:59    [22397987]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
goldmi45,

да всё это теоретизирование. Я вот пока не вижу результата select count по самой большой таблице с execute time и page reads.
19 ноя 21, 15:01    [22397988]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
ъъъъъ
Member

Откуда:
Сообщений: 2657
ТС уже раз пять прямо сказала, что НЕ БУДЕТ переделывать "как правильно", а они все равно скачут перед ней, как самцы павианов перед самкой, "короткие трпнзакции", "сборка мусора"...
19 ноя 21, 16:11    [22398023]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
ъъъъъ
ТС уже раз пять прямо сказала, что НЕ БУДЕТ переделывать "как правильно", а они все равно скачут перед ней, как самцы павианов перед самкой, "короткие трпнзакции", "сборка мусора"...


Почему же нет? Буду переделывать. Только переделки времени требуют. Особенно если речь про 400 000 строк кода.
И требование писать новый код никто не отменял :(
И понять, как не открывать пишущие транзакции для чтения в Delphi тоже.
Плохо тут то, что данные ошибки не проявляют себя сразу, а потом привыкаешь так писать.

Столько советов, что мозг уже не соображает, за что схватиться. Извините, если туплю :(

Хотя вопрос по сути уже решён, совет с "set statistics index" помог. Да 2 гигабайтной базе много и нее надо наверное ...



kdv
goldmi45,

да всё это теоретизирование. Я вот пока не вижу результата select count по самой большой таблице с execute time и page reads.


IBExpert (Execute and Fetch All) показывает так (cтоит сказать, что у меня Intel Core i7 и SSD, а у пользователей Pentium 4 и HDD потому сложно понять их проблемы с тормозами ...):

Исходная база 2 Гб:

------ Performance info ------
Prepare time = 0ms
Execute time = 1s 452ms
Avg fetch time = 0,01 ms
Current memory = 13 053 936
Max memory = 48 897 120
Memory buffers = 2 048
Reads from disk to cache = 3 949
Writes from cache to disk = 4
Fetches from cache = 316 413

После set statistics index Sweep (размер базы остался 2 Гб):

------ Performance info ------
Prepare time = 10ms
Execute time = 1s 472ms
Avg fetch time = 0,01 ms
Current memory = 12 719 024
Max memory = 71 616 052
Memory buffers = 2 048
Reads from disk to cache = 3 950
Writes from cache to disk = 0
Fetches from cache = 316 393

После Backup&Restore (размер бэкапа 47 Мб) база стала вместо 2 Гб - 117 Мб:

И запрос:

------ Performance info ------
Prepare time = 10ms
Execute time = 1s 412ms
Avg fetch time = 0,01 ms
Current memory = 9 146 440
Max memory = 9 365 804
Memory buffers = 2 048
Reads from disk to cache = 4 162
Writes from cache to disk = 4
Fetches from cache = 284 673

Сообщение было отредактировано: 19 ноя 21, 17:23
19 ноя 21, 17:13    [22398056]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Vlad F
Member

Откуда:
Сообщений: 1451
Наталья87

И понять, как не открывать пишущие транзакции для чтения в Delphi тоже.

Двойной клик мышью по объекту TIBTransaction открывает некий диалог, где все это, решив разобраться, можно настроить.
Т.е. в самом минимальном варианте нужны будут два объекта: TIBTransactionReadOnly и TIBTransactionReadWrite.

Сообщение было отредактировано: 19 ноя 21, 17:33
19 ноя 21, 17:29    [22398063]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54790

Наталья87
Хотя вопрос по сути уже решён, совет с "set statistics index" помог.

А не должен был по идее.

Posted via ActualForum NNTP Server 1.5

19 ноя 21, 17:34    [22398068]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
ъъъъъ
Member

Откуда:
Сообщений: 2657
Наталья87


kdv
...Я вот пока не вижу результата select count по самой большой таблице с execute time и page reads.


IBExpert (Execute and Fetch All) показывает так (cтоит сказать, что у меня Intel Core i7 и SSD, а у пользователей Pentium 4 и HDD потому сложно понять их проблемы с тормозами ...):

Исходная база 2 Гб:

------ Performance info ------
Prepare time = 0ms
Execute time = 1s 452ms
Avg fetch time = 0,01 ms
Current memory = 13 053 936
Max memory = 48 897 120
Memory buffers = 2 048
Reads from disk to cache = 3 949
Writes from cache to disk = 4
Fetches from cache = 316 413

После set statistics index Sweep (размер базы остался 2 Гб):

------ Performance info ------
Prepare time = 10ms
Execute time = 1s 472ms
Avg fetch time = 0,01 ms
Current memory = 12 719 024
Max memory = 71 616 052
Memory buffers = 2 048
Reads from disk to cache = 3 950
Writes from cache to disk = 0
Fetches from cache = 316 393

После Backup&Restore (размер бэкапа 47 Мб) база стала вместо 2 Гб - 117 Мб:

И запрос:

------ Performance info ------
Prepare time = 10ms
Execute time = 1s 412ms
Avg fetch time = 0,01 ms
Current memory = 9 146 440
Max memory = 9 365 804
Memory buffers = 2 048
Reads from disk to cache = 4 162
Writes from cache to disk = 4
Fetches from cache = 284 673

Это п....ц.
Соответствие ответа вопросу - меньше, чем у виртуального собеседника уровня ELIZA, 1966г.
19 ноя 21, 17:55    [22398072]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
Наталья87,

ок, спасибо. Хотя размер страницы из (gstat -h) тоже бы не помешал. Ну да ладно.
Допустим, размер страницы 8к. Хотя, если соотнести с уровнем знаний, то должен быть 4к.
Итого. 4162 страниц размером (допустим) 8к прочитано за 1.4 сек. Это получается 23мб/в секунду.
Для 4к страниц это 11.6мб в секунду.

То есть, база на каком-то ноутбучном диске HDD примерно 10летней давности, не меньше.
Наталья87
После set statistics index Sweep (размер базы остался 2 Гб):

ну почему вы считаете что после каких-то операций размер базы должен уменьшиться?
Размер базы НИКОГДА не уменьшается, ни при каких операциях - удаление, свип, реиндексация, и т.д.
Уменьшение файла БД вообще никакой СУБД никогда не делается.
А рестор - это создание новой БД и заполнение ее данными из бэкапа. Весь файл БД строится заново.

Кроме того - ну уменьшилась у вас база в 20 раз. И что? Как было время выполнения запроса 1.4 секунды, так и осталось. Потому что читалось одно и то же (примерно) количество страницы. Результат page reads 4162 относительно 3950 предыдущих, видимо, из-за заполнения кэша (там плюс-минус 2048 страниц кэша).
Fetches меньше? Ну, м.б. чуть поплотнее данные на страницах стали. и всё.
Наталья87
cтоит сказать, что у меня Intel Core i7 и SSD

не верю. по цифрам никакого ssd у вас нет.

Сообщение было отредактировано: 19 ноя 21, 19:37
19 ноя 21, 19:36    [22398129]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
Наталья87,

Для примера. База 26 гиг, tpcc. размер страницы 16к. amd 3700x.
select count(*) from order_line
(если что - результат = 90млн записей)
Execute time = 46s 687ms
Memory buffers = 2 048
Reads from disk to cache = 532 637
Firebird 3 (версия ФБ тут без разницы, т.к. фактически меряется скорость обращения к диску)

вычисляем, получаем ... 178 мегабайт в секунду. На HDD ST200DM01.

Вам надо CrystalDiskMark запустить, посмотреть диск. А то ваш диск на ssd не тянет совершенно, и даже на hdd.

Скопировал базу на ssd (samsung 860 evo, sata3), получил
Execute time = 22s 500ms

То есть, 369 мегабайт в секунду (столько же показывает и диспетчер задач).

p.s. и последнее - fetch All для select count зачем? там 1 запись выводится.
19 ноя 21, 19:55    [22398140]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54790
kdv
p.s. и последнее - fetch All для select count зачем? там 1 запись выводится.

Ты сильный оптимист если думаешь, что она делала запрос с count...

Наталья87
Столько советов, что мозг уже не соображает, за что схватиться.

Естественно. Поэтому обычно обучение происходит постепенно, начиная с азов. Сначала просто счёт с палочками, потом сложение-вычитание, потом таблица умножения и только через четыре года тригонометрия с синусами-косинусами. А Вы решили ворваться в высшую математику, размахивая счётными палочками. Конечно же будет больно.

Сообщение было отредактировано: 19 ноя 21, 20:10
19 ноя 21, 20:01    [22398142]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4936
Dimitry Sibiryakov
goldmi45
Это вы думаете, что не более 1 минуты, а пользователь, открыв диалог, отвлёкся,
потом пошёл на обед. И в итоге транзакция может висеть очень долго.

Приведённые ею статистики такого не показывают.
Я не уверен, что приведенная статистика была не от недавно отресторенной базы.
19 ноя 21, 21:28    [22398177]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
YuRock,

там всё какое-то секретное, и я даже вывода gstat -h не видел, только набор маркеров транзакций скопирован оттуда.
19 ноя 21, 21:40    [22398183]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
pva86
Member

Откуда:
Сообщений: 2
Наталья87, это Вы разрабатываете Курс: школа?
19 ноя 21, 22:30    [22398200]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
Да - размер страницы у меня, разумеется, 4 Кб.

По информации - да, запрос был без count. Сейчас то же самое с count. На всякий случай перед каждым тестом перезапуск сервера Firebird и свежий запуск IBExpert.


1) Исходная база 2 Гб:

------ Performance info ------
Prepare time = 0ms
Execute time = 40ms
Avg fetch time = 40,00 ms
Current memory = 9 110 532
Max memory = 9 357 108
Memory buffers = 2 048
Reads from disk to cache = 3 950
Writes from cache to disk = 0
Fetches from cache = 284 232


2) После set statistics index + Sweep (база 2 Гб):

------ Performance info ------
Prepare time = 0ms
Execute time = 50ms
Avg fetch time = 50,00 ms
Current memory = 9 106 432
Max memory = 9 352 988
Memory buffers = 2 048
Reads from disk to cache = 3 950
Writes from cache to disk = 0
Fetches from cache = 284 232


3) После Backup&Restore (база 117 Мб):

------ Performance info ------
Prepare time = 0ms
Execute time = 40ms
Avg fetch time = 40,00 ms
Current memory = 9 120 068
Max memory = 9 365 492
Memory buffers = 2 048
Reads from disk to cache = 4 161
Writes from cache to disk = 0
Fetches from cache = 284 654
19 ноя 21, 23:25    [22398206]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4936
Наталья87
Да - размер страницы у меня, разумеется, 4 Кб.

По информации - да, запрос был без count. Сейчас то же самое с count. На всякий случай перед каждым тестом перезапуск сервера Firebird и свежий запуск IBExpert.


1) Исходная база 2 Гб:

------ Performance info ------
Prepare time = 0ms
Execute time = 40ms
Avg fetch time = 40,00 ms
Current memory = 9 110 532
Max memory = 9 357 108
Memory buffers = 2 048
Reads from disk to cache = 3 950
Writes from cache to disk = 0
Fetches from cache = 284 232


2) После set statistics index + Sweep (база 2 Гб):

------ Performance info ------
Prepare time = 0ms
Execute time = 50ms
Avg fetch time = 50,00 ms
Current memory = 9 106 432
Max memory = 9 352 988
Memory buffers = 2 048
Reads from disk to cache = 3 950
Writes from cache to disk = 0
Fetches from cache = 284 232


3) После Backup&Restore (база 117 Мб):

------ Performance info ------
Prepare time = 0ms
Execute time = 40ms
Avg fetch time = 40,00 ms
Current memory = 9 120 068
Max memory = 9 365 492
Memory buffers = 2 048
Reads from disk to cache = 4 161
Writes from cache to disk = 0
Fetches from cache = 284 654

Результаты идентичны, в пределах порешности на квант времени, отводимого ос потоку.
Вывод: вы тестируете [уже] не тормозящую базу.

Сообщение было отредактировано: 19 ноя 21, 23:29
19 ноя 21, 23:29    [22398210]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

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


1) Исходная тормозящая БД
------ Performance info ------
Prepare time = 0ms
Execute time = 4s 436ms
Avg fetch time = 4 436,00 ms
Current memory = 9 191 116
Max memory = 9 357 108
Memory buffers = 2 048
Reads from disk to cache = 9 070
Writes from cache to disk = 8 674
Fetches from cache = 8 352 295


2) После set statistics index + Sweep
------ Performance info ------
Prepare time = 0ms
Execute time = 1s 312ms
Avg fetch time = 1 312,00 ms
Current memory = 9 107 400
Max memory = 9 352 988
Memory buffers = 2 048
Reads from disk to cache = 7 292
Writes from cache to disk = 0
Fetches from cache = 707 354


3) После backup&restore
------ Performance info ------
Prepare time = 0ms
Execute time = 500ms
Avg fetch time = 500,00 ms
Current memory = 9 120 772
Max memory = 9 365 492
Memory buffers = 2 048
Reads from disk to cache = 7 243
Writes from cache to disk = 0
Fetches from cache = 707 257
19 ноя 21, 23:43    [22398213]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
Наталья87
1) Исходная тормозящая БД
Reads from disk to cache = 9 070
Writes from cache to disk = 8 674

как вы это всё меряете. Ну например, на тормозящей - выполнили запрос, дисконнект, и опять запрос? Во второй раз запрос сколько выполняется?
Вы же видите, что у вас на читающий запрос почти столько же writes сколько и reads. Т.е. вся таблица замусорена, и мусор этим запросом убрался.
Непонятно, на что вы жалуетесь - сначала наплодили версий во всей таблице, а потом "запрос медленно работает".

Статистику по базе (gstat -r ...) смотрели? Версии есть? Или после первого запроса они исчезли? Или еще не исчезли, раз у вас superserver (как я понял), и он просто не успел еще собрать мусор?

Но нет - мы стартанем свип (просто наобум), и не глядя в firebird.log будем считать что станет быстрее. Хотя мусор собрался уже перед свипом.

И почему вы считаете что для базы 2 гиг размер страницы 4к - это нормально? Сделайте 8к, и сразу заметите что стало быстрее.

Короче, я уже устал. :-) Читайте ibase.ru про транзакции, версионность, и т.д.
20 ноя 21, 01:15    [22398230]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
pva86
Member

Откуда:
Сообщений: 2
kdv,
Если речь таки о Курс: школа, то там полная печаль: бекапы базы делаются путем копирования файла базы перед каждым запуском программы, клиентов десятки тысяч на самых разных конфигурациях ПК. А сама база, в основном, содержит информацию всего лишь о 2-3 тисячах человек
20 ноя 21, 12:07    [22398280]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
pva86
бекапы базы делаются путем копирования файла базы перед каждым запуском программы

ну, 1с локальные базы "бэкапит" тоже записью в zip или сжатую папку.
20 ноя 21, 18:51    [22398382]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54790

kdv
1с локальные базы "бэкапит" тоже записью в zip или сжатую папку

Галактика в своё время делала так же. Самое забавное, что из-за какого-то бага в
pkzip архив на определённых данных получался битый и не мог распаковаться.

Posted via ActualForum NNTP Server 1.5

20 ноя 21, 18:54    [22398385]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
X11
Member

Откуда: Kharkiv, Ukraine
Сообщений: 15425
Наталья87
энди
Я правильно понимаю что Вы стартуете транзакцию, а потом вываливаете пользователю диалоговое окно и в это время у вас все еще болтается открытая транзакция?


Да. Но это не часами длится. Обычно не более 1 минуты, а при нормальной работе секунд 10-15. Очень удобно - если произошла ошибка или пользователь нажал "Отменить" - просто делаем Rollback и всё.


но это в корне неправильно
21 ноя 21, 16:30    [22398683]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54790

X11
но это в корне неправильно

Да нет, при соблюдении определённых условий это нормально. Жаль, что аффтарша
эти условия соблюсти не смогла.

Posted via ActualForum NNTP Server 1.5

21 ноя 21, 17:02    [22398698]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
Dimitry Sibiryakov

kdv
1с локальные базы "бэкапит" тоже записью в zip или сжатую папку

Галактика в своё время делала так же. Самое забавное, что из-за какого-то бага в
pkzip архив на определённых данных получался битый и не мог распаковаться.


Не у меня все по феншую. Бэкапы делаются с помощью gbak, не простым копированием файла базы, также проверяется восстановление из бэкапов. Если же бэкапы перестали делаться - пользователю выводится табличка с предупреждением. Обычно если бэкапы перестали делаться означает что база сильно повреждена, что даже бэкапы перестали делаться.

Для новых пользователей и размер страницы будет 8К. А старым 4К останется тут уже ничего не сделаешь ...
22 ноя 21, 00:52    [22398846]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4936
Наталья87
А старым 4К останется тут уже ничего не сделаешь ...
При восстановлении из бэкапа это можно легко изменить.
22 ноя 21, 02:44    [22398855]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
shalamyansky
Member

Откуда:
Сообщений: 290
Наталья87

с пустой базой приложение работает очень быстро, а по мере наполнения базы начинает замедляться.

Оценить зависимость времени выполнения запросов от размера базы (числа строк больших таблиц) можете? Если зависимость линейная, значит, где-то индекса не хватает, или он не используется. Вместо логарифмического поиска используется линейный. Почему B/R в таком случае помогает? Меньше страниц серверу просматривать приходится. Как гипотеза.
22 ноя 21, 03:30    [22398856]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
shalamyansky
Наталья87

с пустой базой приложение работает очень быстро, а по мере наполнения базы начинает замедляться.

Оценить зависимость времени выполнения запросов от размера базы (числа строк больших таблиц) можете? Если зависимость линейная, значит, где-то индекса не хватает, или он не используется. Вместо логарифмического поиска используется линейный. Почему B/R в таком случае помогает? Меньше страниц серверу просматривать приходится. Как гипотеза.


От этого и возникают идеи "дефрагментации базы данных". Чтобы упорядочить данные внутри файла. Чтобы они не были раскиданы по всему файлу в хаотичном виде. Я так понимаю, после Backup&Restore именно это и происходит (данные таблиц становятся более упорядоченными внутри файла и идут последовательно). Но в целом рекомендации выше и так уже помогли. Всё стало работать с приемлемой скоростью и без backup&restrore. А у кого это не поможет (таких теперь явно будет меньше после выполнения всех рекомендаций) можно по старинке и backup&restore сделать (и индексов добавить где запросы тормозят).
22 ноя 21, 12:26    [22399013]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
энди
Member

Откуда: Киров, Россия
Сообщений: 1299
"Я так понимаю", а почитать?
22 ноя 21, 14:13    [22399107]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
Наталья87
. Чтобы упорядочить данные внутри файла. Чтобы они не были раскиданы по всему файлу в хаотичном виде. Я так понимаю, после Backup&Restore именно это и происходит (данные таблиц становятся более упорядоченными внутри файла и идут последовательно).

еще раз - база данных (любая) - это файл произвольного доступа (random access). У операционной системы при чтении файлов есть "предиктивное" чтение. Поэтому, если 2 страницы одной и той же таблицы лежат подряд, то файловый кэш ОС скорее всего при обращении к такой первой странице считает и вторую.
Поэтому, как бы, последовательный перебор записей в таблицах быстрее после restore. Потому что рестор заливает таблицы по очереди.
Однако, последовательность данных в таблицах всегда случайная - т.е. как их записали, или как обновили в зависимости от "дырок" после удалений.
А обычно из БД стараются получить данные в каком-то упорядоченном виде. Который абсолютно точно не соответствует расположению записей в таблицах.
Индексы, которые способствуют выдаче по нужному порядку, строятся "потом". Например, в самом конце restore. И они расположены далеко от таблиц.
Опять возвращаемся к random access. Если на HDD "предиктивное чтение" ОС еще как-то помогало, то на SSD оно абсолютно бесполезно, т.к. чтение случайных страниц одинаково быстро.
И вообще, "дефрагментация" с SSD теряет смысл. Дефрагментация раньше нужна была только для того, чтобы файлы копировались быстрее. А копирование - это последовательное чтение страниц (блоков) файла.
Чего (последовательного чтения) при выборке данных из БД не бывает почти никогда.

p.s. вся эта идея "дефрагментации" она как из прошлого, лет 20-30 назад. Тем более по отношении к БД. И сейчас просто СТЫДНО упоминать такую бредятину. Как минимум, это индикатор того, что вы вообще не понимаете внутреннее устройство баз, дисков, ssd и прочего. А надо бы.
22 ноя 21, 14:32    [22399121]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
svd
Member

Откуда:
Сообщений: 223
Наталья87,

Если вам нужно делать backup/restore раз в полгода, ну создайте bat/cmd/sh, который это делает. Записываете вызов в скедалер и наслаждаетесь.

Что мешает делать это программно? У нас так и сделано. Правда идет управление роботом, контроль ведется несколькими программами одновременно. При старте компьютера специальная программа рапуска контролирующих программ проверяет статус запуска серверов, запуска соединения с железом и на минутку задерживается, чтоб сделать бэкап/рестор базы.
26 ноя 21, 12:17    [22401188]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3 4      [все]
Все форумы / Delphi Ответить