Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Delphi Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
 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]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
Все форумы / Delphi Ответить