Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3 4 5 6 7 8 9 10      [все]
 Быстрый рост объема базы Interbase/Firebird  [new]
MS_INTERBASE
Guest
Всем привет.
Есть проблема с тем, что быстро растет база у одного из клиентов. За несколько дней с 30 MB до 500 MB. Реальными данными база наполняется примерно по 2-3 MB в неделю. Это происходит и под Interbase 5.6 и под FireBird 1.5. Есть 6 рабочих станций и сервер. Сервер ставили на 2 разных компа: один Windows 2000 Professional, другой Windows XP. База пухнет одинаково быстро. Backup-Restore восстанавливает объем базы до нормального размера ~30-40 MB. Все настройки СУБД стандартные (по умолчанию) , размер страницы соответствует кластеру. Сеть Wi-Fi
У прочих клиентов (их более 100) таких проблем нет.
1. Какие причины такого быстрого роста базы? Как их устранить?
2. Как уменьшить объем gdb-файла без Backup-Restore?
18 янв 08, 13:53    [5172094]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32520
Плодятся версии записей...
18 янв 08, 13:57    [5172137]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Утёс
Member

Откуда:
Сообщений: 394
без b/r никак.
а пухнет потому, что активно работают с ней
18 янв 08, 13:58    [5172146]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32520
MS_INTERBASE
Сеть Wi-Fi
Каменты нужны?
18 янв 08, 13:59    [5172154]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Dimitry Sibiryakov
Member

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

MS_INTERBASE

1. Какие причины такого быстрого роста базы? Как их устранить?

Неправильно разработанное приложение. Нанять программиста для рефакторинга.

Posted via ActualForum NNTP Server 1.4

18 янв 08, 14:00    [5172164]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
WildSery
Member

Откуда: да, оттуда.
Сообщений: 18989
Сдаётся мне, что вопрос неверно сформулирован.
А растёт ли база ДАЛЬШЕ, за 500Мб? Если не растёт - то сюда.
18 янв 08, 14:05    [5172204]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
MS_INTERBASE
Guest
Понятно, что плодятся, вопрос, почему не удаляются старые версии?
sweep interval 20000
18 янв 08, 14:06    [5172217]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
MS_INTERBASE
Guest
Di_LIne
MS_INTERBASE
Сеть Wi-Fi
Каменты нужны?

Нужны. Какие могут быть проблемы с беспроводной сетью?
18 янв 08, 14:09    [5172240]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Семён Р
Member

Откуда:
Сообщений: 11
MS_INTERBASE
Всем привет.
Есть проблема с тем, что быстро растет база у одного из клиентов. За несколько дней с 30 MB до 500 MB. Реальными данными база наполняется примерно по 2-3 MB в неделю. Это происходит и под Interbase 5.6 и под FireBird 1.5. Есть 6 рабочих станций и сервер. Сервер ставили на 2 разных компа: один Windows 2000 Professional, другой Windows XP. База пухнет одинаково быстро. Backup-Restore восстанавливает объем базы до нормального размера ~30-40 MB. Все настройки СУБД стандартные (по умолчанию) , размер страницы соответствует кластеру. Сеть Wi-Fi
У прочих клиентов (их более 100) таких проблем нет.
1. Какие причины такого быстрого роста базы? Как их устранить?
2. Как уменьшить объем gdb-файла без Backup-Restore?

Что-то мне подсказывает, что на клиенте как то неправильно построено управление транзакциями. Клиент на DELPHI ?
18 янв 08, 14:10    [5172249]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
WildSery
Member

Откуда: да, оттуда.
Сообщений: 18989
MS_INTERBASE
Понятно, что плодятся, вопрос, почему не удаляются старые версии?
sweep interval 20000
Ну и что, что "свип интервал"?
Ты IBAnalyst'ом смотрел? Чего показвает?
18 янв 08, 14:10    [5172252]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
WildSery
Member

Откуда: да, оттуда.
Сообщений: 18989
Семён Р
Клиент на DELPHI ?
Тут дельфи никто не знает (ц)
Думаешь, на Сях будут существенные отличия?
18 янв 08, 14:12    [5172269]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
MS_INTERBASE
Guest
Утёс
без b/r никак.
а пухнет потому, что активно работают с ней

Больше сотни клиентов работают нормально, из которых этот один из самых неактивных.
18 янв 08, 14:12    [5172271]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
MS_INTERBASE
Guest
Семён Р
Что-то мне подсказывает, что на клиенте как то неправильно построено управление транзакциями. Клиент на DELPHI ?

Клиент написан в основном на DELPHI. Используются IBX и FIB
18 янв 08, 14:16    [5172305]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
MS_INTERBASE
Guest
WildSery
MS_INTERBASE
Понятно, что плодятся, вопрос, почему не удаляются старые версии?
sweep interval 20000
Ну и что, что "свип интервал"?
Ты IBAnalyst'ом смотрел? Чего показвает?

что именно смотреть IBAnalyst'ом?
18 янв 08, 14:24    [5172375]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Семён Р
Member

Откуда:
Сообщений: 11
WildSery
Семён Р
Клиент на DELPHI ?
Тут дельфи никто не знает (ц)
Думаешь, на Сях будут существенные отличия?

Delphi и Builder верней их компоненты позволяют написать приложения не использую транзакции. Получается, что местами это даже работает. Поэтому и спросил. Другими словами смотри клиента.
18 янв 08, 14:24    [5172378]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
222333
Guest
Может блобы часто update-тите?
18 янв 08, 14:24    [5172379]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Игорь Горбонос
Member

Откуда: Днепропетровск
Сообщений: 4236


> Автор: Семён Р
> WildSery
> Семён Р
> Клиент на DELPHI ?
> Тут дельфи никто не знает (ц)
> Думаешь, на Сях будут существенные отличия?
>
> Delphi и Builder верней их компоненты позволяют написать приложения
> не использую транзакции. Получается, что местами это даже работает.
> Поэтому и спросил. Другими словами смотри клиента.

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

Posted via ActualForum NNTP Server 1.4

18 янв 08, 14:30    [5172415]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
MS_INTERBASE
Guest
222333
Может блобы часто update-тите?

Не часто. На этом клиенте блобы вообще не задействованы.
Я вижу разницу с со всеми другими нормально работающими клиентами только в том, что у проблемного клиента используется Wi-Fi, а у всех прочих кабельная сеть
18 янв 08, 14:31    [5172426]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
mtv3mtv
Member

Откуда: Киев
Сообщений: 41
1. Т.к. у других клиентов (заказчиков) работает, то клиент (программа) написана коректно...
2. Т.к. также пробовали с разными серверами, то железо и ПО СУБД тоже исключаем...

ИМХО копать нужно базу. Есть ли доступ к ней у пользователей через IBExpert? Может шибко умный юзер, интересуясь "что там такое?", методом тыка включит ведение логов изменений для парочки таблиц? Или иную бяку сотворил...
Необходим допрос с пристрастием... Чудес не бывает.
18 янв 08, 14:37    [5172470]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Семён Р
Member

Откуда:
Сообщений: 11
Игорь Горбонос


> Автор: Семён Р
> WildSery
> Семён Р
> Клиент на DELPHI ?
> Тут дельфи никто не знает (ц)
> Думаешь, на Сях будут существенные отличия?
>
> Delphi и Builder верней их компоненты позволяют написать приложения
> не использую транзакции. Получается, что местами это даже работает.
> Поэтому и спросил. Другими словами смотри клиента.

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

Posted via ActualForum NNTP Server 1.4

Я тоже так думал. Но видел поделку, верней говорил с её автором, так вот он очень удивился узнав о транзакциях
18 янв 08, 14:38    [5172478]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Семён Р
Member

Откуда:
Сообщений: 11
Если в приложении всё нормально, попробуй создать к основным таблицам триггеры которые будут протоколировать работу этих таблиц.
18 янв 08, 14:43    [5172517]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
WildSery
Member

Откуда: да, оттуда.
Сообщений: 18989
Семён Р
Я тоже так думал. Но видел поделку, верней говорил с её автором, так вот он очень удивился узнав о транзакциях
Прекрати уж, пока тут народ с канделябром/битой не подтянулся.
И ты, и тот "автор" только думают, что не используют транзакции. А на самом деле просто ими не управляют.
18 янв 08, 14:44    [5172519]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
WildSery
Member

Откуда: да, оттуда.
Сообщений: 18989
Семён Р
Если в приложении всё нормально, попробуй создать к основным таблицам триггеры которые будут протоколировать работу этих таблиц.
Я думаю, что уже кто-то создал, потому база и пухнет

Автор так и не ответил, до каких пределов пухнет база. Или бесконечно?
18 янв 08, 14:44    [5172528]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Семён Р
Member

Откуда:
Сообщений: 11
WildSery
Семён Р
Я тоже так думал. Но видел поделку, верней говорил с её автором, так вот он очень удивился узнав о транзакциях
Прекрати уж, пока тут народ с канделябром/битой не подтянулся.
И ты, и тот "автор" только думают, что не используют транзакции. А на самом деле просто ими не управляют.

Извини не так выразился, сами компоненты конечно и управляют, но я всегда предпочитаю это делать вручную.
18 янв 08, 14:48    [5172563]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
MS_INTERBASE
Guest
mtv3mtv
1. Т.к. у других клиентов (заказчиков) работает, то клиент (программа) написана коректно...
2. Т.к. также пробовали с разными серверами, то железо и ПО СУБД тоже исключаем...

ИМХО копать нужно базу. Есть ли доступ к ней у пользователей через IBExpert? Может шибко умный юзер, интересуясь "что там такое?", методом тыка включит ведение логов изменений для парочки таблиц? Или иную бяку сотворил...
Необходим допрос с пристрастием... Чудес не бывает.

Просмотр IBExpert'om показал, что никто в базу не лазит. Даже если пользователь включит ведение логов или даже создаст свою таблицу или мою завалит ее спамом, в это случае база будет заполнена реальными данными и после backup-restore вместо 500 будет примерно те же 500 (чуть меньше на объем мусора) МБ. Здесь же Объем базы падает с 500 до 30 Мб. Это как раз очищается мусор.
18 янв 08, 14:50    [5172577]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
MS_INTERBASE
Guest
WildSery
Семён Р
Если в приложении всё нормально, попробуй создать к основным таблицам триггеры которые будут протоколировать работу этих таблиц.
Я думаю, что уже кто-то создал, потому база и пухнет

Автор так и не ответил, до каких пределов пухнет база. Или бесконечно?

Максимум было примерно 680МБ. Потом в очередной раз сделали backup-restore и объём уменьшился до нормальных 30-40МБ
18 янв 08, 14:52    [5172593]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
WildSery
Member

Откуда: да, оттуда.
Сообщений: 18989
MS_INTERBASE
что именно смотреть IBAnalyst'ом?
Как это что? Статистику. Хотя бы заглавную страничку, раздел "Информация о БД".
18 янв 08, 14:53    [5172595]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
WildSery
Member

Откуда: да, оттуда.
Сообщений: 18989
MS_INTERBASE
Максимум было примерно 680МБ.
Скорость роста постоянная?
Есть ли моменты времени, когда в БД нет ни одного коннекта?
18 янв 08, 14:53    [5172604]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
MS_INTERBASE
Guest
WildSery
MS_INTERBASE
Максимум было примерно 680МБ.
Скорость роста постоянная?
Есть ли моменты времени, когда в БД нет ни одного коннекта?

С базой работают круглосуточно примерно с одинаковой интенсивностью по дням. В пределах суток, ночью работают меньше, днем больше. Скорость роста примерно одинаковая.
18 янв 08, 14:56    [5172623]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
MS_INTERBASE
Guest
WildSery
MS_INTERBASE
что именно смотреть IBAnalyst'ом?
Как это что? Статистику. Хотя бы заглавную страничку, раздел "Информация о БД".


Database header page information:
Flags 0
Checksum 12345
Generation 68639
Page size 4096
ODS version 10.1
Oldest transaction 68627
Oldest active 68628
Oldest snapshot 68628
Next transaction 68629
Bumped transaction 1
Sequence number 0
Next attachment ID 0
Implementation ID 16
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 1
Creation date Dec 20, 2007 12:04:14

Variable header data:
Sweep interval: 20000
*END*


Database file sequence:

Database log page information:
Creation date
Log flags: 2
No write ahead log

Next log page: 0

Variable log data:
Control Point 1:
File name:
Partition offset: 0 Seqno: 0 Offset: 0
Control Point 2:
File name:
Partition offset: 0 Seqno: 0 Offset: 0
Current File:
File name:
Partition offset: 0 Seqno: 0 Offset: 0
*END*
18 янв 08, 15:00    [5172652]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Утёс
Member

Откуда:
Сообщений: 394
mtv3mtv
1. Т.к. у других клиентов (заказчиков) работает, то клиент (программа) написана коректно...
2. Т.к. также пробовали с разными серверами, то железо и ПО СУБД тоже исключаем...

ИМХО копать нужно базу. Есть ли доступ к ней у пользователей через IBExpert? Может шибко умный юзер, интересуясь "что там такое?", методом тыка включит ведение логов изменений для парочки таблиц? Или иную бяку сотворил...
Необходим допрос с пристрастием... Чудес не бывает.


Скажем так, чудеса закончились 2000 лет назад
18 янв 08, 15:02    [5172677]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
MS_INTERBASE
Guest
Утёс
mtv3mtv
1. Т.к. у других клиентов (заказчиков) работает, то клиент (программа) написана коректно...
2. Т.к. также пробовали с разными серверами, то железо и ПО СУБД тоже исключаем...

ИМХО копать нужно базу. Есть ли доступ к ней у пользователей через IBExpert? Может шибко умный юзер, интересуясь "что там такое?", методом тыка включит ведение логов изменений для парочки таблиц? Или иную бяку сотворил...
Необходим допрос с пристрастием... Чудес не бывает.


Скажем так, чудеса закончились 2000 лет назад

Остаётся вопрос про беспроводную сеть.
18 янв 08, 15:17    [5172778]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32520
Вот сам и ответил...
MS_INTERBASE
... что у проблемного клиента используется Wi-Fi, а у всех прочих кабельная сеть
... Стабильность ВайФая - вещь относительная, и не постоянная, и прочая, прочая, прочая...
18 янв 08, 15:18    [5172782]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Dimitry Sibiryakov
Member

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

Di_LIne

Стабильность ВайФая - вещь относительная, и не постоянная

Но тем не менее статистика показывает, что зависших транзакций нет.

Posted via ActualForum NNTP Server 1.4

18 янв 08, 15:21    [5172799]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
WildSery
Member

Откуда: да, оттуда.
Сообщений: 18989
Di_LIne
Стабильность ВайФая - вещь относительная, и не постоянная, и прочая, прочая, прочая...
И как оно может повлиять на рост БД? Тем более, что
MS_INTERBASE
Oldest transaction 68627
Oldest active 68628
Oldest snapshot 68628
Next transaction 68629
18 янв 08, 15:24    [5172823]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32520
Dimitry Sibiryakov

Di_LIne

Стабильность ВайФая - вещь относительная, и не постоянная

Но тем не менее статистика показывает, что зависших транзакций нет.
... что не исключает наличие большого кол-ва конфликтов, которые все же успешно решаются со временем. Нужно посмотреть динамику счетчика транзакций...
18 янв 08, 15:25    [5172837]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
MS_INTERBASE
Guest
WildSery
Di_LIne
Стабильность ВайФая - вещь относительная, и не постоянная, и прочая, прочая, прочая...
И как оно может повлиять на рост БД? Тем более, что
MS_INTERBASE
Oldest transaction 68627
Oldest active 68628
Oldest snapshot 68628
Next transaction 68629

И при этом объем базы до backup'a 189MB
18 янв 08, 15:26    [5172848]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Dimitry Sibiryakov
Member

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

MS_INTERBASE
И при этом объем базы до backup'a 189MB

А винты на сервере все еще гигабайтные? И не дохнут от старости? Вот
это, я понимаю, чудо...

Transaction Monitor тебе в руки и смотреть кто и когда отращивает мусор
в базе.

Posted via ActualForum NNTP Server 1.4

18 янв 08, 15:29    [5172872]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
MS_INTERBASE
Guest
Dimitry Sibiryakov

MS_INTERBASE
И при этом объем базы до backup'a 189MB

А винты на сервере все еще гигабайтные? И не дохнут от старости? Вот
это, я понимаю, чудо...

Transaction Monitor тебе в руки и смотреть кто и когда отращивает мусор
в базе.
Posted via ActualForum NNTP Server 1.4

ты представляешь, о чем ты говоришь?
18 янв 08, 15:36    [5172928]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Dimitry Sibiryakov
Member

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

MS_INTERBASE
ты представляешь, о чем ты говоришь?

Да. А что не так?

Posted via ActualForum NNTP Server 1.4

18 янв 08, 15:41    [5172965]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
MS_INTERBASE
Guest
Dimitry Sibiryakov

MS_INTERBASE
ты представляешь, о чем ты говоришь?

Да. А что не так?
Posted via ActualForum NNTP Server 1.4

Хочется слышать разумные версии и предложения
18 янв 08, 15:46    [5173011]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Dimitry Sibiryakov
Member

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

MS_INTERBASE
Хочется слышать разумные версии и предложения

Нет, ты все-таки скажи - в чем неразумность предложенного мною алгоритма
твоих действий:
If <места на винте хватает>
  then <забить>
  else
   begin
    <Скачать Transaction Monitor>;
    <Настроить Transaction Monitor>;
    <Выяснить кто и когда забивает БД мусором>;
    <Покарать виновного>;
   end;

Posted via ActualForum NNTP Server 1.4

18 янв 08, 15:50    [5173036]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
MS_INTERBASE
Guest
Dimitry Sibiryakov

MS_INTERBASE
Хочется слышать разумные версии и предложения

Нет, ты все-таки скажи - в чем неразумность предложенного мною алгоритма
твоих действий:
If <места на винте хватает>
  then <забить>
  else
   begin
    <Скачать Transaction Monitor>;
    <Настроить Transaction Monitor>;
    <Выяснить кто и когда забивает БД мусором>;
    <Покарать виновного>;
   end;
Posted via ActualForum NNTP Server 1.4

Нельзя оставлять нерешенную проблему. Нельзя забить на непонятный рост базы 200МБ в неделю. И нельзя отключать клиентов для нового подключения после backup-restore. Как ты предлагаешь анализировать Transaction Monitor. Засим я предлагаю закончить с обсуждением твоих алгоритмов.
18 янв 08, 15:59    [5173129]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Dimitry Sibiryakov
Member

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

MS_INTERBASE

Нельзя оставлять нерешенную проблему. Нельзя забить на непонятный рост
базы 200МБ в неделю. И нельзя отключать клиентов для нового подключения
после backup-restore. Как ты предлагаешь анализировать Transaction
Monitor. Засим я предлагаю закончить с обсуждением твоих алгоритмов.

Можно, если рост нелинейный и имеет горизонтальную ассимптоту, чья
величина меньше размера свободного места на винчестере. В этом случае
проблемы нет.
Производить backup-restore вместо решения проблемы (даже если она есть)
это метод страуса.
То, что ты не знаешь, что такое Transaction Monitor от ibase.ru не дает
тебе право говорить, что он непригоден для решения данной проблемы (если
она существует).
Ну и (напоследок) то, что IBAnalist ты использовал не по назначению -
тоже плохой симптом.

Засим измерение степени твоего кретинизма можно закончить и подождать
пока ты предоставишь описание хода расследования и выявленных данных.
Как я уже говорил - статистика идеальная и БД пухнуть не должна.

Posted via ActualForum NNTP Server 1.4

18 янв 08, 16:11    [5173236]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32520
MS_INTERBASE
... Засим я предлагаю закончить с обсуждением твоих алгоритмов.

- Значит будут бить.
18 янв 08, 16:11    [5173237]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32520
- эх, не успел предупредить.
18 янв 08, 16:12    [5173253]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Игорь Горбонос
Member

Откуда: Днепропетровск
Сообщений: 4236


> Автор: Di_LIne
> MS_INTERBASE
> ... Засим я предлагаю закончить с обсуждением твоих алгоритмов.
>
> - Значит будут бить.
Только это понимал Паниковский :(

Posted via ActualForum NNTP Server 1.4

18 янв 08, 16:13    [5173265]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Семён Р
Member

Откуда:
Сообщений: 11
Чем не нравиться вариант с добавлением триггеров и записью протоколирования во внешнею таблицу
18 янв 08, 16:15    [5173291]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32520
Семён Р
Чем не нравиться вариант с добавлением триггеров и записью протоколирования во внешнею таблицу
Как всегда: Самое сложное решение простейшего вопроса.
Нет, даже задачки из учобника....
18 янв 08, 16:17    [5173314]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Семён Р
Member

Откуда:
Сообщений: 11
Di_LIne
Семён Р
Чем не нравиться вариант с добавлением триггеров и записью протоколирования во внешнею таблицу
Как всегда: Самое сложное решение простейшего вопроса.
Нет, даже задачки из учобника....

Поясните в чем сложность.
18 янв 08, 16:22    [5173352]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Dimitry Sibiryakov
Member

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

Семён Р

вариант с добавлением триггеров и записью протоколирования во внешнею
таблицу

Это потом - когда выяснится когда и в какой таблице образуется гора мусора.

Posted via ActualForum NNTP Server 1.4

18 янв 08, 16:22    [5173357]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
MS_INTERBASE
Guest
Всем спасибо, особенно Di_LIne
Будем искать проблемы в Wi-Fi
18 янв 08, 16:36    [5173506]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32520
MS_INTERBASE
Всем спасибо, особенно Di_LIne
Будем искать проблемы в Wi-Fi

Фай-Вай оно конечно да... Но...
Где-то, имхо, в софтике есть "некорректное место", не все варианты конфликтов, ошибок продуманы.
18 янв 08, 16:55    [5173704]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Пьяный Винни-Пух
Member

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

Как я уже говорил - статистика идеальная и БД пухнуть не должна.


Статистика, поди, снята при разогнанных юзерах перед снятием бакапа для замещения. А там одна транзакция на резинке оттягивалася-оттягивалася, а когда юзер вышел - бздынь! - и подтянулася.
18 янв 08, 16:59    [5173742]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
mtv3mtv
Member

Откуда: Киев
Сообщений: 41
Пьяный Винни-Пух +1

Меня еще смущает Database dialect 1, хотя у других заказчиков все ок.
Di_LIne

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

Вывод - все-таки придется мониторить базу во время реальной работы юзеров...
18 янв 08, 21:44    [5174809]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
mtv3mtv
Member

Откуда: Киев
Сообщений: 41
Тынц
18 янв 08, 22:14    [5174884]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Пьяный Винни-Пух
Member

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

Меня еще смущает Database dialect 1


Меня как-то больше по жизни смущает Dialect 3
18 янв 08, 22:27    [5174920]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
mtv3mtv
Member

Откуда: Киев
Сообщений: 41
Еще 1 тынц
Еще бы взглянуть на InterBase/firebird.log
18 янв 08, 22:56    [5174991]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
mtv3mtv
Member

Откуда: Киев
Сообщений: 41
Хотелось бы все-таки узнать чем дело закончилось? Наши победили?
6 фев 08, 00:36    [5249056]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Ivan_Pisarevsky
Guest
И чем все ж виноват вай-фай, я вот его вполне себе пользую, нихто не пухнет, работает стабильно, отваливается редко.

Сталю 5 копеек на ОЧЕНЬ длинные снапшот транзакции и коммит ретайнинг. :)
6 фев 08, 10:50    [5250109]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
MS_INTERBASE
Member

Откуда:
Сообщений: 4
mtv3mtv
Хотелось бы все-таки узнать чем дело закончилось? Наши победили?

Дело в том же состоянии, и на момент написания первого поста. Некогда заниматься. Так что пока раз в неделю делаем бэкап-рестор. Если будет решение, то отпишу.
8 фев 08, 03:03    [5260724]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
так ответ был дан сразу - у вас в приложениях хреновое управление транзакциями. есть долгоживущие транзакции, которые препятствуют сборке мусорных версий. вот и все. По-моему, никакого другого решения, кроме как как исправлять работу с транзакциями, нет.
8 фев 08, 10:23    [5261387]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
NextMan
Member

Откуда:
Сообщений: 9744
fasrvgfsbdhnyjtynjfbd
проголосуйте +5 !!!!!!!!!!!!!!!!!!!
http://foto.mail.ru/mail/yurik-naum/2/12.html

Швабра накрашеная/
Думает, что сможет удержать дерево. Или фотку нужно повернуть на 90°?
10 фев 08, 00:51    [5268245]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

Откуда:
Сообщений: 77
Dimitry Sibiryakov
MS_INTERBASE
Хочется слышать разумные версии и предложения

Нет, ты все-таки скажи - в чем неразумность предложенного мною алгоритма
твоих действий:
If <места на винте хватает>
  then <забить>
  else
   begin
    <Скачать Transaction Monitor>;
    <Настроить Transaction Monitor>;
    <Выяснить кто и когда забивает БД мусором>;
    <Покарать виновного>;
   end;



Та же ситуация вылезла. База после рестора 16Гб и скачками растет по 5-10Гб. За день на то на 15, то на 7, то вообще не растет.
Очень хочу настроить "Настроить Transaction Monitor", но не знаю нюансов. На что смотреть, что бы понять что именно этот аттачмент базу увеличивает? Тот у кого больше всех пейдж врайт? Какие мониторы могут это делать автоматом? В принципе, могу и сам написать, только не знаю какую именно величину мониторить. И какая она нормальная, а какая уже нет?
3 июл 13, 14:34    [14516691]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

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

IBTM только даст представление о том, насколько плохо или хорошо приложения работают с транзакциями.
Основные причины роста базы:
- хреновое управление транзакциями ("нет-нет, мы транзакциями не управляем!"), из-за чего копятся версии, и они не убираются как мусор, а значит не освобождают пространство в БД, и БД растет
- использование функциии LIST в запросах или конкатенации блобов в процедурах/триггерах, вместе с предыдущим пунктом.

посмотреть сколько версий накапливается можно сняв gstat -r сразу после restore и например в конце дня. Будет видно, есть версии, где, и т.д. IBTM просто покажет, что с транзакциями хорошо или плохо.

Кол-во операций по аттачментам - см. MON$, тут даже думать не надо. Но это не даст понимания, почему БД растет. Ну Page writes, и что? можно сделать миллион page writes одной странице, от этого база не увеличится.

p.s. еще есть естественная причина - добавление большого количества записей.
3 июл 13, 14:41    [14516761]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

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

гос предприятие. одинаковые базы стоят во всех "филиалах". размеры баз от 10 до 50Гб (есть "филиалы" больше, есть меньше). И только в этом такая вот беда. Клиентское приложение везде одинаковое (кривое, с БДЕ и прочее)... Но проблема страшного роста та только тут и появилась только две недели назад.
Бекап/рестор восстанавливает базу в нормальный размер (16Гб)

Как вот это сделать???
<Настроить Transaction Monitor>
<Выяснить кто и когда забивает БД мусором>
3 июл 13, 14:58    [14516893]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Dimitry Sibiryakov
Member

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

Drag
Как вот это сделать???

Разница цифр в выводе gstat -r до и после внезапного роста укажет где именно накапливается
"жир".

Posted via ActualForum NNTP Server 1.5

3 июл 13, 15:06    [14516987]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
Drag
Как вот это сделать???
<Настроить Transaction Monitor>
<Выяснить кто и когда забивает БД мусором>


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

"настроить transaction monitor" - скачайте уже и поставьте IBTM.
"выяснить кто забивает базу мусором" - тоже уже сказал, gstat -r, анализ статистики в IBAnalyst, плюс просмотр mon$attachments на тему длительных коннектов и mon$transactions на тему длительных транзакций. Если у вас, конечно, Firebird 2.1, а не 2.0 или ниже.

Собственно, выясните вы все это или нет, значения практически не имеет, т.к. сделать вы ничего (скорее всего) не сможете. Данная проблема решается только исправлением приложений.
3 июл 13, 15:28    [14517212]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Dimitry Sibiryakov
Member

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

kdv
например. подключение в IBExpert к базе с утра, и "ничегонеделание" с этим
открытым коннектом до конца дня.

А я бы поставил на update без where. Уж если подозревать кого-то в кретинизме, так не
мелочась. Твой вариант подразумевает, что легитимные пользователи генерят 15 гиг изменений
в день. Я в таких пользователей не верю.

Posted via ActualForum NNTP Server 1.5

3 июл 13, 15:31    [14517246]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

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

ну база одним махом выросла в 16ти до 31го!!
это надо апдейты без веров во всех таблицах сделать!

завтра утром сделаю б/р и соберу статистику. потом подожду когда распухнет и соберу опять... отпишусь.
3 июл 13, 16:03    [14517481]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 6919
Drag
ну база одним махом выросла в 16ти до 31го!!
это надо апдейты без веров во всех таблицах сделать!

или сдуру написать
insert into TAB select * from TAB
и через полчаса, протрезвев, срубить свой коннект...
3 июл 13, 16:18    [14517596]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

Откуда:
Сообщений: 77
dimitr,

Взял я статистику большой БД (31ГБ), сделал Б/Р и статистику маленькой (16ГБ).
ДО б/р (большая 31ГБ)
Database header page information: 
        Flags                   0 
        Checksum                12345 
        Generation              954123 
        Page size               4096 
        ODS version             11.1 
        Oldest transaction      935599 
        Oldest active           935670 
        Oldest snapshot         935670 
        Next transaction        935671 
        Bumped transaction      1 
        Sequence number         0 
        Next attachment ID      18440 
        Implementation ID       26 
        Shadow count            0 
        Page buffers            0 
        Next header page        0 
        Database dialect        3 
        Creation date           Jun 19, 2013 21:25:59 
        Attributes              multi-user maintenance 
 
    Variable header data: 
        Sweep interval:         20000 
        *END* 

После б/р (маленькая 16ГБ)
Database header page information: 
        Flags                   0 
        Checksum                12345 
        Generation              954116 
        Page size               4096 
        ODS version             11.1 
        Oldest transaction      935599 
        Oldest active           935665 
        Oldest snapshot         935665 
        Next transaction        935666 
        Bumped transaction      1 
        Sequence number         0 
        Next attachment ID      18438 
        Implementation ID       26 
        Shadow count            0 
        Page buffers            0 
        Next header page        0 
        Database dialect        3 
        Creation date           Jun 19, 2013 21:25:59 
        Attributes              multi-user maintenance 
 
    Variable header data: 
        Sweep interval:         20000 
        *END*


Подожду конечно когда опять вырастет, но что-то не уверен, что будет разница.
4 июл 13, 10:22    [14520568]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
Drag
Взял я статистику большой БД (31ГБ), сделал Б/Р и статистику маленькой (16ГБ).

данные header page это как бы не статистика.
Статистику вам сказали собирать gstat -r
при этом будут здоровые файлы. Которые сюда цитировать не надо. Смотрите их сами IBAnalyst-ом.
И, вы процитировали один и тот же файл.

кстати
Attributes              multi-user maintenance 
4 июл 13, 11:05    [14520830]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

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

это я IBExpert-ом собрал. файлы вышли вообще одинаковые кроме этих заголовков. Сейчас IBAnalyst-ом соберу.
4 июл 13, 11:09    [14520854]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
Drag
это я IBExpert-ом собрал.

галочку полной статистики включить забыл.
4 июл 13, 11:12    [14520870]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

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

еще раз напомню - сюда в тексте полную статистику цитировать не надо, потому что ее надо
а) сравнивать со статистикой после бэкапа
б) смотреть в инструменте, который показывает статистику "в гриде".

если уж ты хочешь комментариев - получи те обе полные статистики, запакуй в zip/rar, и приложи сюда.
4 июл 13, 11:15    [14520886]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

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

ну это ясно, что сюда не надо :)
я вставляю их в ВинМерж и сравниваю.
Галку я ставил, но эти два файла вышли одинаковые кроме заголовков.
Сейчас Аналистом делаю, сравню...
Таблицы глазами сравнивать сложнее, потому я текстовый вариант в ВинМерж пихаю.
Правильно же я понял, что все данные, что в таблицах, есть и в тексте?
4 июл 13, 11:25    [14520968]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Gallemar
Member

Откуда: г.Новосибирск
Сообщений: 5367
Drag,если база после рестора почему счетчики не обнулились?
Oldest transaction 935599
Oldest active 935665
Oldest snapshot 935665
4 июл 13, 11:35    [14521053]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Gallemar
Member

Откуда: г.Новосибирск
Сообщений: 5367
И Creation date Jun 19, 2013 21:25:59 не поменялась
Вы точно рестор делаете?
4 июл 13, 11:37    [14521060]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Vad72
Member [заблокирован]

Откуда: KYIV
Сообщений: 4613
а если изменить размер PAGE у базы данных, то что-то измениться?
4 июл 13, 12:11    [14521300]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
Drag
Таблицы глазами сравнивать сложнее

что? запустить 2 ibanalyst-а, отсортировать например таблицы по кол-ву записей и сравнить - сложнее чем колупаться тексте, пусть даже и в windiff и подобных???
вы IBAnalyst хотя бы запускали? :-)
4 июл 13, 12:16    [14521344]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

Откуда:
Сообщений: 77
Gallemar,

тоже удивлен, но база та стала 16Гб. а как иначе кроме рестора файл базы может уменьшиться?
4 июл 13, 12:17    [14521353]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
Vad72
а если изменить размер PAGE у базы данных, то что-то измениться?

ТСЯ. Да, по идее страница 4к для 16 гиг базы маловато. Надо 8к или 16к.
Но - нет, размер страницы на флуктуации размера БД никак не повлияет.
4 июл 13, 12:17    [14521358]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

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

я где-то читал что размер страницы лучше указывать как размер кластера на венике, а там 4к.
да. аналистом я эти проверки и делал. Только странно как-то. в текстовой версии он не все цифры показывает. Видать интерфейс на лету что-то еще рассчитывает. Типа "Процент версий данных 0.00% - записей: 4418 mb, версий: 0 mb, страниц 7112 mb, индексы 3022 mb".

Да. понял свою ошибку. Действительно не с того файла скопировал который после рестора.
после рестора вот такое:
Database header page information: 
        Flags                   0 
        Checksum                12345 
        Generation              489 
        Page size               4096 
        ODS version             11.1 
        Oldest transaction      476 
        Oldest active           477 
        Oldest snapshot         477 
        Next transaction        478 
        Bumped transaction      1 
        Sequence number         0 
        Next attachment ID      5 
        Implementation ID       26 
        Shadow count            0 
        Page buffers            0 
        Next header page        0 
        Database dialect        3 
        Creation date           Jul 4, 2013 6:20:56 
        Attributes               
 
    Variable header data: 
        Sweep interval:         20000 
        *END* 
4 июл 13, 12:29    [14521450]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
Drag
после рестора вот такое:

ну и зачем оно нам надо? я вам таких же могу 1001 штуку прислать. Вы, похоже, вообще не понимаете, какая информация в этом куске текста содержится.
Drag
я где-то читал что размер страницы лучше указывать как размер кластера на венике, а там 4к.

при размере базы в 16 гиг это уже не важно. Другие критерии вступают в силу.
4 июл 13, 12:39    [14521549]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

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

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

т.к. такого рода информацию я публиковать тут не очень имею право, то могу вам только выслать по почте эти два лога.
Или давайте дождемся когда она вырастет опять и тогда отправить до б/р (большую), после б/р (маленькую) и опять выросшую.
высылать?
4 июл 13, 12:47    [14521644]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10635
Значит скорее всего дело в блобах. До тройки в статистике нет информации о заполнении блоб. Ищи запрос/ХП, где используется фунция LIST или конкатенация блобов
4 июл 13, 12:52    [14521694]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
Drag
В этом анализаторе размер мусора не указывается.

"в этом" - в каком?
Drag
то могу вам только выслать по почте эти два лога.

support@ibase.ru
можно и сейчас и потом. в zip/rar.

и, версию FB мы пока не увидели (хотя о ней можно догадаться по ODS из статистики).
Кстати, приложения сейчас все еще модифицируются, или уже давно нет?
4 июл 13, 12:55    [14521722]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Dimitry Sibiryakov
Member

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

Drag
я где-то читал что размер страницы лучше указывать как размер кластера на
венике

Ошибочка: не "как", а "не меньше чем".

Posted via ActualForum NNTP Server 1.5

4 июл 13, 13:02    [14521780]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

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

письмо отправил.
ФБ 2.1.5
Приложение модифицируется.

Спасибо.
4 июл 13, 13:11    [14521849]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Dimitry Sibiryakov
Member

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

Drag
Приложение модифицируется.

Вот среди модификаций, вступивших в силу перед началом неприятностей и ищи злоупотребление
BLOB-ами.

Posted via ActualForum NNTP Server 1.5

4 июл 13, 13:14    [14521876]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

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

значит действительно, функция LIST и конкатенация блобов. Потому что в статистике объем данных и индексов до и после б-р не сильно меняется.
Непонятно, почему вы удивились, что "раньше такого не было, а сейчас есть", раз у вас разработчики до сих пор модифицируют приложения. Я понимаю, если бы приложение пару лет никто не трогал, и "вдруг!".
У вас еще и не то может быть. Обычно в отрыве администратора и разработчика разработчики "лепят горбатого", а администратор в недоумении.

дальше
- В статистике "большая база" не вижу версий, вообще. Вероятно, статистика собрана или после sweep, или в какой-то такой момент. Читать.

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

- какого рожна в списке таблиц вылезла RDB$RELATION_CONSTRAINTS? Возможно, покореженная структура БД, т.к. есть еще совершенно левая по отношению к rdb$ таблица RDB$STORED_DATA.

В общем, передавайте привет разработчикам.
4 июл 13, 13:35    [14522043]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

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

я то и есть разработчик :)
админы не справились, я разбираюсь.
листы и конкатенации сейчас будем смотреть.
1. Версий нет, потому что все в кеш датасетах. И транзакции моментально открываются и закрываются. Открытыми не держим.
2. Про глубину еще руки не дошли до понимания что такое, где-то читал что увеличение размера страниц уберет эту проблему.
3. :) если посмотрите внимательно, она там на одну букву не так называется. Это наши "спец таблицы", что б никто не видел.

Привет принят, спасибо :)
4 июл 13, 13:46    [14522123]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

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

В логе есть после трех часов работы вот такая штука:
	Размер TIP для Snapshot	42352 транзакций, 14 килобайт
	Active transactions	42351, 99% от ежедневных


Это не странно?
4 июл 13, 13:49    [14522136]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
Drag
Это не странно?

нет. если вы работаете через БДЕ, то "транзакции моментально открываются и закрываются" - это вряд ли.
Drag
2. Про глубину еще руки не дошли до понимания что такое, где-то читал что увеличение размера страниц уберет эту проблему.

то есть, прочитать рекомендации IBAnalyst-а нет сил? А "где-то читал", это или тут, или на ibase.ru.
4 июл 13, 16:37    [14523493]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

Откуда:
Сообщений: 77
В общем админ базы пропал. Видать ничего не растет больше, он и замолчал. Хоть бы сказал что всё хорошо :)
А так как очень не вежливо не отписаться о результатах предлагаемой помощи.
Посему предполагаю результат:
1. БД росла страшными темпами
2. Бекапы/ресторы не помогали
3. Анализы и проверки ничего необычного не показывали.
4. Единственное что я ему изменил - это выставил forced write.

Я так понял, что это то, что ему помогло.

Спасибо всем за помощь.
25 июл 13, 17:18    [14617730]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Ivan_Pisarevsky
Member

Откуда: НН
Сообщений: 8612
Drag
Я так понял, что это то, что ему помогло.
бред.
хотя эффект плацебо...
25 июл 13, 21:06    [14618667]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

Откуда:
Сообщений: 77
Ivan_Pisarevsky,

Вы правы, накаркал. Сегодня же утром позвонил админ, база из 15Гб до 48Гб выросла за вчерашний день.
Так что вопрос не решен.
Создал у него на сервере батник с логированием размера БД. Засунул его в планировщик на каждые 5 мин.
Будем ловит момент когда растет...
26 июл 13, 13:32    [14621766]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Dimitry Sibiryakov
Member

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

Drag
Так что вопрос не решен.

Естественно вопрос не будет решён если его не решать.
Напустить на выросшую базу dbinfo, чтобы посмотреть каких страниц стало больше, Вы хотя бы
попытались?
http://ibsurgeon.com/products/firebird_interbase/monitoring/dbinfo

Posted via ActualForum NNTP Server 1.5

26 июл 13, 13:37    [14621806]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
Drag
база из 15Гб до 48Гб выросла за вчерашний день.

ставлю на неуемный LIST или конкатенацию блобов. (фраза в воздух) непонятно, почему разработчик не понимает, почему у него растет база.
26 июл 13, 14:00    [14621959]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Dimitry Sibiryakov
Member

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

kdv
непонятно, почему разработчик не понимает, почему у него растет база.

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

Posted via ActualForum NNTP Server 1.5

26 июл 13, 14:03    [14621983]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
Dimitry Sibiryakov,

ну запросы-то он и процедуры/триггеры не мышью писал.

p.s. "- это невозможно, это не имеет смысла - "мышью открывать окна". иконки.... [пауза] все сделаем, товарищ Сталин!"
26 июл 13, 14:56    [14622359]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Гаджимурадов Рустам
Member

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

kdv> p.s. "- это невозможно, это не имеет смысла - "мышью открывать окна".
kdv> иконки.... [пауза] все сделаем, товарищ Сталин!"

Хороший ролик, да. "Мне нужно много мышей и оконных рам".

P.S. Мне ещё нравится ролик, когда он чечетку танцевал. :)

Posted via ActualForum NNTP Server 1.5

26 июл 13, 16:46    [14623467]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

Откуда:
Сообщений: 77
Ув. коллеги, прошу без оскорблений.
Проект у меня большой (модулей 500), разрабатывается он уже лет 15. Достался мне по наследству "как есть".
Причесываем как можем, но конечно всякое бывает.
Так вот последовательно:
Dimitry Sibiryakov
Напустить на выросшую базу dbinfo, чтобы посмотреть каких страниц стало больше

Да, это делал. Как и говорил раньше полезного объема 15Г все остальное в графе "Unused (free)".
kdv
ставлю на неуемный LIST или конкатенацию блобов

Как вы понимаете, проект начал свою жизнь в древние времена и к FB 2.1 пришли не очень давно. Потому всяких супер фичей отличных от нативного SQL в проекте очень мало.
kdv
непонятно, почему разработчик не понимает, почему у него растет база

Потому что всё было как обычно. Туча разных мелких и крупных доработок. Всем всё нравится и у всех всё работает. А вот тут только у одного такая вот история.
Как найти причину?
Стараюсь делаю, всё что вы предлагаете.
Мой то вопрос в саааамом начале и сводился к вопросу как выполнить предложенное в сообщении 5173036
26 июл 13, 18:18    [14624092]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

Откуда:
Сообщений: 77
Так что избавиться от всех LISTов в проекте?
26 июл 13, 18:19    [14624099]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10635
Если использовать их только когда необходимо, то можно не избавляться. Просто часто его пихают куда не надо.
26 июл 13, 18:23    [14624119]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Dimitry Sibiryakov
Member

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

Drag
Да, это делал. Как и говорил раньше полезного объема 15Г все остальное в графе
"Unused (free)".

Ну и забей: дальше база расти уже не будет.

Posted via ActualForum NNTP Server 1.5

26 июл 13, 18:24    [14624132]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
Drag
Потому что всё было как обычно. Туча разных мелких и крупных доработок. Всем всё нравится и у всех всё работает. А вот тут только у одного такая вот история.
Как найти причину?
Стараюсь делаю, всё что вы предлагаете.
Мой то вопрос в саааамом начале и сводился к вопросу как выполнить предложенное в сообщении 5173036


то ли я совсем старый стал, то ли в последнее время солнечная активность лишает людей логики (я вообще, ибо тенденция просматривается).

1. операция LIST или конкатенация блобов производится через временные блобы
2. временные блобы хранятся в базе
3. временные блобы живут до окончания транзакции, в которой они были созданы (тут че-то я не очень помню, в какой точно момент они освобождаются)
4. если есть большое кол-во операций из пункта 1, в одной длинной транзакции, или в одной процедуре/триггере, то разумеется, база будет пухнуть.

в связи с этим тебя сразу отослали в IBTM посмотреть, хорошо в твоем приложении с транзакциями, или плохо.
Судя по росту базы - плохо. В IBTM можно было бы увидеть, насколько. В FB 2.1/2.5 можно увидеть долгие транзакции в mon$transactions.
Долгие транзакции надо лечить.

Уже не помню, "внезапно" у вас начался рост базы, или он всю жизнь такой был, читать опять 3 страницы неинтересно. Если "внезапно", то нужно искать момент, когда это случилось, и что менялось в метаданных или в приложении (или в управлении транзакциями).
Я уже опух в тысячный раз объяснять все эти банальные вещи, которые логически следуют одна из другой при наличии хоть малейшего понимания версионности и транзакций.
Все, что я написал, уже написали в ответах на ваш вопрос.

Как найти LIST в запросах?
Как найти конкатенацию блобов в процедурах/триггерах?
Как найти через mon$ сколько какой аттачмент и т.д. наменял страниц?
26 июл 13, 19:07    [14624374]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Arioch
Member

Откуда:
Сообщений: 11101
kdv
Долгие транзакции надо лечить.


долгая read-only транзакция тоже опухнуть может?
26 июл 13, 19:16    [14624415]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Dimitry Sibiryakov
Member

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

Arioch
долгая read-only транзакция тоже опухнуть может?

Всенепременно.

Posted via ActualForum NNTP Server 1.5

26 июл 13, 19:20    [14624424]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
Arioch
долгая read-only транзакция тоже опухнуть может?

видишь ли, создание временного блоба - это по факту операция записи. Но в read-only операции изменения и удаления запрещены, в то время как list и конкатенация блобов такими операциями не считаются.
Вот если базу в read-only перевести - тогда да, шиш.
26 июл 13, 19:28    [14624450]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

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

Спасибо за консультацию по принципу конкатенации блобов, учту на будущее.
К TM слали не меня, я просто поинтересовался как его настраивать (позже уже понял, что речь идет оменно о IBTM, а он платный и не дешевый).

Начался внезапно. Пересматривал много раз что меняли с тех пор (240 ревизий), ничего прям явного не увидел.
Не верю, что "версионность и транзакции" (кое что в них смыслю) могут 3 недели не проявляться при активной работе пользователей, а потом одним махом увеличить базу в 3 раза! с 16 до 48 ГБ!

Теперь про вопросы:
kdv
Как найти LIST в запросах?

Поиском по проекту в SQL запросах слова "LIST"
kdv
Как найти конкатенацию блобов в процедурах/триггерах?

Поиском по метаданным во вьюхах, триггерах и процедурах слова "LIST"
kdv
Как найти через mon$ сколько какой аттачмент и т.д. наменял страниц?

Тут всё описано: http://www.firebirdsql.org/file/documentation/reference_manuals/reference_material/html/fbcache-mon-io-stats.html

Вы не подумайте, я очень ценю вашу помощь. И стараюсь пробовать всё предложенное.

Давайте эту тему закроем, я решу данную проблему путем авто бэкап/рестора скажем раз в неделю в данной конкретной базе да и всё. А там в 2.5 или 3.0 авось что изменится...

Спасибо.
26 июл 13, 19:30    [14624452]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Dimitry Sibiryakov
Member

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

Drag
я решу данную проблему путем авто бэкап/рестора скажем раз в неделю в данной
конкретной базе да и всё

Какую проблему? Какое слово из "забей, дальше база расти не будет" тебе непонятно?

Posted via ActualForum NNTP Server 1.5

26 июл 13, 19:33    [14624459]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Arioch
Member

Откуда:
Сообщений: 11101
kdv
Arioch
долгая read-only транзакция тоже опухнуть может?

видишь ли, создание временного блоба - это по факту операция записи. Но в read-only операции изменения и удаления запрещены, в то время как list и конкатенация блобов такими операциями не считаются.


Так почему и заинтересовался. Загогулина получается.

Вроде как ro-транзакции запускаются уже закрытыми. Т.е. все блобы такие должны мгновенно освобождаться. Но может быть надо периодически явно commit retaining делать? или savepoint ? или ничего не поможет и только переоткрывать по расписанию ?
26 июл 13, 19:37    [14624467]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Arioch
Member

Откуда:
Сообщений: 11101
Drag
kdv
Как найти конкатенацию блобов в процедурах/триггерах?

Поиском по метаданным во вьюхах, триггерах и процедурах слова "LIST"


а можно я встряну ? Сказку расскажу, а уж правда в ней или ложь - саим решайте.

допустим есть у нас вьюха

CREATE VIEW FIOs as SELECT Fam || ' ' || Nam || ' ' || Sur as FIO FROM Persons 


Или аналогичный столбец

ALTER TABLE Persons ADD FIO COMPUTED BY Fam || ' ' || Nam || ' ' || Sur 


Никакого слова LIST у нас нет, а конкатенация есть. Правда, пока не блобов.

И вот однажды случился матёрый человечище, у которого имя в выбранный VARCHAR не влезло.
Ну и чтобы дважды предел длины не менять - решили разработчики поменять этим столбцам тип на текстовый BLOB.

И все заработало, имена стали болшие-большие, а отчества - ещё больше. И слова LIST не появилось. А конкатенация блобов...
26 июл 13, 19:44    [14624481]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Dimitry Sibiryakov
Member

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

Arioch
Вроде как ro-транзакции запускаются уже закрытыми. Т.е. все блобы такие
должны мгновенно освобождаться.

Было так. И был зарегистрировать баг "blob id not found" в ro-транзакции. И был пофикшен.
Так что теперь временные блобы таких транзакций не освобождаются до коммита. Или даже до
дисконнекта - точно не помню.

Posted via ActualForum NNTP Server 1.5

26 июл 13, 19:51    [14624506]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
кстати, hvlad, ау, напомни, когда временные блобы освобождаются. commit/rollback, disconnect?
собрать бы все это в один текст. Вроде кто-то (Таблоид? Влад?) даже тест делал, который этим делом базу резко увеличивает.
А я от вашего имени статейку на ibase.ru положу...

p.s. поиском пытался найти зерна, но очень много плевел, тонны сообщений надо пересматривать.
26 июл 13, 20:00    [14624535]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 61751
Временные блобы освобождаются по завершении транзакции.
Насчёт статьи - я не уверен, что по этому вопросу можно
написать целую статью, но буде такой статья - почитал бы.

Насчёт теста и примеров - я бы побоялся такое выкладывать,
это же готовый пример "как угробить БД (в т.ч. чужую)".
26 июл 13, 23:46    [14625557]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
Гаджимурадов Рустам
Насчёт статьи - я не уверен, что по этому вопросу можно
написать целую статью, но буде такой статья - почитал бы.

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

Мне более страшно, что проблема начинает принимать массовый характер. Потому я и хочу документ с объяснениями.
27 июл 13, 00:08    [14625680]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Таблоид
Member

Откуда:
Сообщений: 9456
Блог
kdv
Вроде кто-то (Таблоид? Влад?) даже тест делал, который этим делом базу резко увеличивает.
https://www.sql.ru/forum/850850/odnokratnoe-chtenie-bolshogo-blob-a-otkuda-writes-v-statistike?hl=
27 июл 13, 00:18    [14625725]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Таблоид
Member

Откуда:
Сообщений: 9456
Блог
Да, и вот еще, капитальный топег от Микросекунды:
https://www.sql.ru/forum/934487/prichiny-rosta-razmera-bazy
27 июл 13, 00:22    [14625745]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Гаджимурадов Рустам
Member

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

kdv> под "статьей" я имею в виду документ хоть на пол-страницы.

ОК, щас накидаю для наиболее частых случаев.
Только без рецептов "как угробить", это без меня.

Posted via ActualForum NNTP Server 1.5

27 июл 13, 00:23    [14625749]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
спасибо, завтра подсоберу.
27 июл 13, 00:41    [14625813]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 61751
Вроде всё, основные вопросы перечислил. Уточни все сомнительные моменты
у ДЕ/Влада - мало ли, я мог чего и напутать по усталости и давности событий.
+
Firebird и временные BLOB-ы

По мотивам https://www.sql.ru/forum/516139 и других топиков на эту тему

У неопытных пользователей может возникнуть ситуация, когда размер файла БД вырос (возможно, даже кратно), хотя в работе с ней «особо» ничего не менялось – количество пользователей не увеличилось, объём информации остался примерно тем же, импорта данных не производилось и т.д. Причиной такого увеличения размера файла БД могут служить BLOB-ы, а точнее временные BLOB-объекты, которые могут формироваться незаметно для пользователя и даже неопытного разработчика.

Что такое временные BLOB-ы?
Это в общем-то обычные BLOB-ы, которые сформированы, но пока не записаны (не «присвоены») в обычную таблицу БД. При создании и даже изменении любого не временного BLOB-объекта всегда сначала создаётся временный BLOB-объект, который позже будет либо удалён, либо материализован (превращён в обычный) путём записи в таблицу БД. Содержимое временного BLOB-а (тело, поток байтов) хранится в БД, точнее, в страничном кеше (на специальных BLOB-страницах). Можно было бы хранить временные BLOB-ы не в самой БД (страничном кеше), а во временном файле (общем или отдельном), но тогда при необходимости сохранить этот BLOB в таблицу БД пришлось бы его заново копировать целиком. Поэтому из двух зол было выбрано наименьшее с целью уменьшения дискового I/O. Таким образом, материализация BLOB-а представляет собой простую и быструю операцию без необходимости копирования тела BLOB-а. Удаление BLOB-а тоже быстрая операция – занятые им страницы просто помечаются как свободные и могут быть повторно использованы для других BLOB-ов или по другому назначению.

В каких случаях могут создаваться временные BLOB-ы?
Временные BLOB-ы создаются при многих операциях, но наиболее частым и потенциально приводящими к увеличению БД являются следующие:

– все операции конкатенации, в которых участвуют BLOB-ы (даже временные),
т.е. если BLOB складывается со строкой, результатом операции будет временный BLOB (а не строка), при чём если операция конкатенации будет делаться в цикле – будут созданы временные BLOB-ы по количеству отработавших операций конкатенации (не по количеству итераций);

select cast('1' as BLOB) || '2' || '3' from rdb$database- создаст 3 временных BLOBa, а не 1

– функция LIST – результатом функции всегда является BLOB, независимо от типа операндов и содержимого, хотя функция не создаёт промежуточных BLOB-ов во время своего выполнения (несмотря на то, что внешне алгоритм похож на конкатенацию, временный BLOB формируется всего один);

- функции и операторы, использующие или возвращающие не созданный заранее BLOB-объект – case, iif, coalesce, substring, cast и т.д. (этот момент надо уточнить, насколько я знаю, движок не умеет вытаскивать наружу уже существующие BLOB – в исходниках 2.5 ничего подобного не нашел).

-- сюда надо бы наглядный прикладной пример
-- сбацать, но что-то мне на ум ничего не пришло


Когда удаляются временные BLOB-ы?
Временные BLOB-ы удаляются (занятые ими страницы помечаются как свободные) при завершении транзакции. Хотя теоретически можно было бы, наверное, освобождать временные BLOB-ы при завершении statementa-а (клиентского запроса), если BLOB-id не был отправлен клиенту, но тут есть нюансы и ничего похожего в коде я не заметил.

Касательно места хранения временных BLOB-ов нужно отметить ещё 2 нюанса:

1. Даже BLOB-ы «предназначенные» для GTT всё равно сначала являются временными и хранятся в БД (поскольку на момент и создания/редактирования ещё неизвестно в какую таблицу они попадут или вообще будут удалены), но после update/insert в GTT будут перенесены в «её» временный файл и освобождены в БД. Почему это будет делаться сразу, не дожидаясь окончания транзакции? Потому что если он понадобится для записи в обычную таблицу БД, его всё равно придётся копировать (дублировать).

2. Начиная с версии 2.1, появилась возможность при создании BLOB-а с клиента сразу сохранять его во временный файл, а не в БД путём присвоения параметру isc_bpb_storage значения isc_bpb_storage_temp (по умолчанию isc_bpb_storage_main, т.е. в БД). Но лично я не знаю ни одну библиотеку доступа к Firebird, которая это поддерживает.


P.S. Бонус в виде небольшого текста про хранение/чтение самого тела БЛОБа
будет позже, если не забуду. Там немного и несложно.
27 июл 13, 08:30    [14626085]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Молочный Александр
Member

Откуда:
Сообщений: 79
Гаджимурадов Рустам,

автор
В каких случаях могут создаваться временные BLOB-ы?
– все операции конкатенации, в которых участвуют BLOB-ы (даже временные)
...


А сохраненные процедуры, возвращающие BLOB?
27 июл 13, 11:02    [14626164]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Гаджимурадов Рустам
Member

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

Молочный Александр> А сохраненные процедуры, возвращающие BLOB?

Не понял вопроса.

Если ХП формирует тело блока каким-то образом на PSQL
(конкатенацией, функцией и т.д.), то ничего не меняется,
всё так же - временный БЛОБы и их количество то же.

Если ХП сама БЛОБы не трогает, а только из таблиц их
достаёт, не меняя, и саспендит - это уже не временные,
а обычные с настоящим BLOB-ID (в т.ч. для GTT).

Posted via ActualForum NNTP Server 1.5

27 июл 13, 12:12    [14626232]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Alex Truhin
Member

Откуда:
Сообщений: 536
Гаджимурадов Рустам
2. Начиная с версии 2.1, появилась возможность при создании BLOB-а с клиента сразу сохранять его во временный файл, а не в БД путём присвоения параметру isc_bpb_storage значения isc_bpb_storage_temp (по умолчанию isc_bpb_storage_main, т.е. в БД). Но лично я не знаю ни одну библиотеку доступа к Firebird, которая это поддерживает.

Что подразумевается под "при создании BLOB-а с клиента"?
- отправка блоба с клиента
- вызов с клиента list
- вызов любой SP создающей временный блоб
27 июл 13, 13:09    [14626286]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Гаджимурадов Рустам
Member

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

Alex Truhin> Что подразумевается под "при создании BLOB-а с клиента"?

Отправка блоба с клиента, конечно.
Вызов List и SP происходят на сервере.

Posted via ActualForum NNTP Server 1.5

27 июл 13, 13:23    [14626303]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 6919
Гаджимурадов Рустам
теоретически можно было бы, наверное, освобождать временные BLOB-ы при завершении statementa-а (клиентского запроса), если BLOB-id не был отправлен клиенту, но тут есть нюансы и ничего похожего в коде я не заметил

там было что-то на этот счет, но не помню при каких случаях...
27 июл 13, 22:25    [14627400]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
а с какой версии началась конкатенация блобов? не могу найти.
27 июл 13, 22:39    [14627411]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Сисдба Мастеркеевич
Member

Откуда:
Сообщений: 402
Вот это: 12623305 еще не вылечили ?

Posted via ActualForum NNTP Server 1.5

28 июл 13, 07:43    [14628275]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Гаджимурадов Рустам
Member

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

dimitr> там было что-то на этот счет, но не помню при каких случаях...

Ну, я слишком глубоко не копал, времени много ушло бы.
Подскажи, где смотреть. BLB_garbage_collect вроде бы не то.

Posted via ActualForum NNTP Server 1.5

28 июл 13, 16:52    [14628943]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Гаджимурадов Рустам
Member

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

kdv> а с какой версии началась конкатенация блобов? не могу найти.

С 2.1.

Posted via ActualForum NNTP Server 1.5

28 июл 13, 16:52    [14628944]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
Гаджимурадов Рустам,

черновик. Возможно местами написана ересь.
http://www.ibase.ru/devinfo/dbgrowth.html

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

"создаст 3 временных BLOBa, а не 1" - а не 4 временных блоба?
28 июл 13, 17:09    [14628964]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Гаджимурадов Рустам
Member

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

kdv> черновик. Возможно местами написана ересь.
kdv> http://www.ibase.ru/devinfo/dbgrowth.html

Как черновик сойдёт. Мог бы исправить мои
грамматические ошибки, запятые расставить. :)

> "создаст 3 временных BLOBa, а не 1" - а не 4 временных блоба?

3. Если ты про формирование БЛОБов для литералов -
то, во-первых, они не формируются, во-вторых, если
бы формировались, то БЛОБов было бы 5, а не 4.

Posted via ActualForum NNTP Server 1.5

28 июл 13, 17:50    [14629030]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Гаджимурадов Рустам
Member

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

P.S. Про автономки ты уверен? Если это так,
то это можно оптимизировать, хотя само по
себе явление довольно редкое.

Posted via ActualForum NNTP Server 1.5

28 июл 13, 17:52    [14629033]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
Гаджимурадов Рустам
P.S. Про автономки ты уверен?

это dimirt уверен.
Гаджимурадов Рустам
Если ты про формирование БЛОБов для литералов -
то, во-первых, они не формируются, во-вторых, если
бы формировались, то БЛОБов было бы 5, а не 4

тогда я не понял, почему тут 3 временных блоба
select cast('1' as BLOB) || '2' || '3' from rdb$database
ну допустим один на cast. а второй на результат конкатенации. где третий?
Гаджимурадов Рустам
Мог бы исправить мои грамматические ошибки, запятые расставить.

грамматического вроде ничего не было, чуть пару фраз поправил, а запятые расставлю.
28 июл 13, 19:57    [14629264]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Гаджимурадов Рустам
Member

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

kdv> это dimirt уверен.

Странно. Это не бага, конечно, но недоработка, хоть и очень редкая.

> тогда я не понял, почему тут 3 временных блоба
> select cast('1' as BLOB) || '2' || '3' from rdb$database
> ну допустим один на cast. а второй на результат конкатенации. где третий?

Первый на каст, второй - результат первой конкатенации,
третий (результирующий) результат второй конкатенации.

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

Я всё не перечитывал, а когда писал, мог и ошибиться.
Там где "случаи" -перевод строки незадуманный, форумный.
И "поскольку на момент и создания" - "их создания", конечно.
Кажется, ещё что-то было, но уже не вижу.

Posted via ActualForum NNTP Server 1.5

28 июл 13, 20:13    [14629305]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 6919
Гаджимурадов Рустам
Странно. Это не бага, конечно, но недоработка, хоть и очень редкая.

так специально сделано
28 июл 13, 21:21    [14629439]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Гаджимурадов Рустам
Member

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

dimitr> так специально сделано

А с какой целью, в чём польза?

Posted via ActualForum NNTP Server 1.5

28 июл 13, 21:55    [14629557]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 6919
Гаджимурадов Рустам
А с какой целью, в чём польза?

насколько помню - из-за невозможности отследить, возвращался ли блоб из автономки наружу (в контекст родительской тр-ции или клиенту). Лучше перебдеть.
28 июл 13, 21:59    [14629571]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Гаджимурадов Рустам
Member

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

dimitr> из-за невозможности отследить, возвращался ли блоб из автономки наружу

Ясно. Ну ладно, коли это невозможно (хотя почему - непонятно).

Posted via ActualForum NNTP Server 1.5

28 июл 13, 22:06    [14629597]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Arioch
Member

Откуда:
Сообщений: 11101
Гаджимурадов Рустам
> тогда я не понял, почему тут 3 временных блоба
> select cast('1' as BLOB) || '2' || '3' from rdb$database
> ну допустим один на cast. а второй на результат конкатенации. где третий?

Первый на каст, второй - результат первой конкатенации,
третий (результирующий) результат второй конкатенации.


а что, есть оператор BLOB || VARCHAR ?

мне вот тоже кажется разумным увидеть 5 блобов - три на тайпкасты плюс два на конкатенации.

Ну, а если 4 - то три на тайпкасты + две SQL-конкатенации одной внутренней varargs процедурой типа CONCAT(a,b,c,d,e,...) - вызов один, а конкатенаций несколько
29 июл 13, 12:52    [14631481]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Arioch
Member

Откуда:
Сообщений: 11101
kdv
черновик. Возможно местами написана ересь.
http://www.ibase.ru/devinfo/dbgrowth.html


1) IMHO Давать ссылк ина форум неплохо, но лучше бы скопировать текст в саму статью, маленькой врезкой. Форум - олн сегодня есть,а завтра лежит или движок поменял или ещё что.

2) IMHO обязательно надо разъяснить о сохранении/очистке блобов в следующих ситуациях:

a) SAVEPOINT
b) ROLLBACK (да, должны дуалиться, а лучше сказать явно, раз FAQ)
c) COMMIT RETAINING
d) ROLLBACK RETAINING

e) Read-only транзакции: ещё в общем недавно пропагандировалась работа "в два соединения", где один из них -"вечная" r/o транзакция READ COMMITED. И то, что "такие транзакции запускаются уже закомммиченными" представлялась как гарантия, что в БД ничего лишнего не будет накапливаться и такие транзакции для движка не напряжны. А тут вдруг оказалось, что старые советы на новые дрожжи приводят к неожиданным проблемам.

Просьба добавить эти пункты в FAQ пусь даже пока заглушками с добавкой to-do - чтобы и самому не забыть и читателям было видно, что статья ещё не раскрыла всю тему
29 июл 13, 13:01    [14631552]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Arioch
Member

Откуда:
Сообщений: 11101
dimitr,

а нельзя blob id сделат ьсо счётчиколм ссылок ? какой-нибудь shared_ptr ?
29 июл 13, 13:02    [14631560]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Arioch
Member

Откуда:
Сообщений: 11101
ну вот, собственно: https://www.sql.ru/forum/1037666/dlinnaya-pishushhaya-tranzakciya-i-korotkaya-chitaushhaya

до сих пор рассматривается как нормальная архитектура, и никто не предупреждает, что в результат её применения будет лопнувшая от блобов БД
29 июл 13, 13:05    [14631578]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 6919
Arioch,

у тебя shared_ptr сам находит все места в коде, где ему надо увеличивать/уменьшать счетчик?
29 июл 13, 13:06    [14631587]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
Arioch
но лучше бы скопировать текст в саму статью

не понял, какой текст? в документе отсылки только на доп. информацию. Твой рассказ (спасибо) я ужал до одного предложения, расширять не вижу смысла.

Arioch
2) IMHO обязательно надо разъяснить о сохранении/очистке блобов в следующих ситуациях:
a) SAVEPOINT

ты серьезно?

Arioch
b) ROLLBACK (да, должны дуалиться, а лучше сказать явно, раз FAQ)

завершение - это commit или rollback. и rollback тут не имеет скрытого смысла. Впрочем, могу добавить.

Arioch
c) COMMIT RETAINING
d) ROLLBACK RETAINING

вот тут не знаю.

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

я вроде уже писал, что если не работает логика, то проблема кажется неожиданной.
Если бы read_only транзакция не давала писать временные блобы, то она бы выдала ошибку в этот момент. А отмазы типа "у меня же транзакция READ only!" это для детского сада.
Но специально, конечно, упомяну.
29 июл 13, 13:44    [14631848]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Arioch
Member

Откуда:
Сообщений: 11101
kdv
Arioch
но лучше бы скопировать текст в саму статью

не понял, какой текст? в документе отсылки только на доп. информацию. Твой рассказ (спасибо) я ужал до одного предложения, расширять не вижу смысла.


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

2) Тогда зачем ссылка, если это предложение полностью передаёт ? А на мой взгляд не полностью. Прочитав твое предложение читатель может подумать "Не, дуракам закон не писан ,но мы-то не дураки!", а я писал именно как пробелмка возникает из-за отдельных шагов, каждый из которых сам по себе безвреден, но просто так сложилось...

На мой вкус сама такая гипотетическая история как "ничего не делали, оно само" был бы полезен встатье. Просто потому что обсуждалось же "а как искать такие места" и был сделаны (и не был оспорены!!!) тезис, что дастаточно грепнуть LIST по скрипту базы. Т.е. помимо вопросы "что может проихойти" хорошо бы осветить несколько сценариев "как может проихойти", просто чтобы людям легче было искать чёрные грабли в тёмной для них комнате.

Arioch
2) IMHO обязательно надо разъяснить о сохранении/очистке блобов в следующих ситуациях:
a) SAVEPOINT

ты серьезно?


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

Понимаешь, FAQ пишутся не для тех, кому и так всё очевидно, а вовсе даже для тех, кому - наоборот.

Arioch
b) ROLLBACK (да, должны дуалиться, а лучше сказать явно, раз FAQ)

завершение - это commit или rollback. и rollback тут не имеет скрытого смысла. Впрочем, могу добавить.


IMHO В статьях "для чайников", особенно в статьях которые - не отжизни хорошей, но тем не менее - будут служить квази-документацией, лучше где-то explicitly и педантично сделать нужную табличку, чем "а дальше вы самивсё поймёте". Хотя бы для того, чтобы сверяясь с табличкой чайник мог проверить, действительно ли он понял суть.

Ну и возможно позже пригодится - отслеживать изменения через версии сервера.

Arioch
c) COMMIT RETAINING
d) ROLLBACK RETAINING

вот тут не знаю.

...похоже, что и авторы не знают, не задумывались :-)

Видишь сколко интересных вопросов мудрецам может задать один невовремя подвернувшийся дурак :-)

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

И кстати, ты пропустил пункт e :-)

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

я вроде уже писал, что если не работает логика, то проблема кажется неожиданной.
Если бы read_only транзакция не давала писать временные блобы, то она бы выдала ошибку в этот момент. А отмазы типа "у меня же транзакция READ only!" это для детского сада.
Но специально, конечно, упомяну.


Ты пытаешься утверждать, что чайник, который думает написать первую программу для FB должен знать его на уровне людей, который годами его пишу тили ремонтирует его БД. Это не так.
Если человек видит где-то рекомендацию по использованию долгоживущих ro-транзакций, то многие простослепо применят этот совет. хороший чайник проверит этот совет по офиц. документациям, релнотам или изветсным сборникам FAQ.

Так вот вопрос, "хороший чайник", который откроет релноты по FB 2.1+ или описание транзакций в FB 2.1+ или FAQ по транзакциям у тебя на сайте - он там найдет предостережения жирным шрифтом, что вконкретной и рядовой ситуации r/o транзакции могут записать в БД кучу мусора ?

more emotional ranting about FAQs in general follows
+
Если холодильник иногда вместо заморозки овощей начинает их варить - это должно быть отражено в его документации и в FAQ.
И детский сад как раз в том, чтобы упрекать потом "использованный компрессор ABC-234DE по другому не умеет, это прекраснно знают все компрессороремонтные заводы Союза"

Я, надеюсь, не Годвин, но если бы в документации по РБМК было бы написано, что при глушении реактора он сначала разгоняется, а только через несколько секунд реально глушится - то не случилось бы одного неприятного взрыва. А ведь устройство РБМК его операторы учили так, как никто здесь не учит устройство FB.

Извини, конечно, но тезис что любой чайник знает, что при вычислении строки 'Мама ' || 'мыла ' || 'раму.' в БД обязательно пишутся новые временные блобы (и что это вообще такое???) это сильная передержка.
FAQ пишутся для дураков, и если известно, что рядом лежат грабли - надо вешать флажок "дурак! срочно погугли ещё вот тут и вот тут, пока живой"

Ведь не даром борманы вводили некогда 2-й диалект, могли бы просто послать куда подальше и сказать "тестируйте как следует и потихоньку разберётесь". А ведь специально сделали средство, которое старается подсветить и привлечь внимание ко всем потенциальным проблемам.
29 июл 13, 15:26    [14632590]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 61751
Arioch
а что, есть оператор BLOB || VARCHAR ?
Конечно. Я даже больше скажу - грубо говоря есть BLOB || почти_any_type и даже
почти_any_type || почти_any_type. Остальной поток сознания без комментариев.
29 июл 13, 15:33    [14632644]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Гаджимурадов Рустам
Member

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

Кстати, Дим - название статьи ИМХО не очень, хоть
бы в скобках пояснил, что про временные BLOB-ы.
Вариантов увеличения размера БД-то масса, тот же
классический Insert-Select.

Так что скорее уж tempblobs.html, а не dbgrowth.html.

Posted via ActualForum NNTP Server 1.5

29 июл 13, 15:39    [14632694]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Arioch
Member

Откуда:
Сообщений: 11101
Гаджимурадов Рустам,

именно оператор в смусле operator overloading напрямую принимающий разные типы и работающий над ними без промежуточныx implicit typecast ? Ну надо же...
29 июл 13, 15:41    [14632711]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Гаджимурадов Рустам
Member

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

У меня такое чувство, что ты с другой планеты.
Ты знаешь какой-то способо конкатенации строки и,
например, даты "без промежуточныx implicit typecast"?
Бред про operator overloading без комментариев.

Posted via ActualForum NNTP Server 1.5

29 июл 13, 15:45    [14632747]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
Arioch
...похоже, что и авторы не знают, не задумывались

тут разве что hvlad или dimitr ответят. Или Таблоид тестом проверит.

Arioch
И кстати, ты пропустил пункт e

не пропустил. см. третий абзац в Причины.

Arioch
Ты пытаешься утверждать, что чайник, который думает написать первую программу для FB должен знать его на уровне людей

я пытаюсь утверждать, что у программиста должно быть хорошо развито логическое мышление. И он должен уметь анализировать факты. Если фактов не хватает, он должен их добыть.

p.s. расширил, углубил, reload.
29 июл 13, 15:47    [14632769]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Гаджимурадов Рустам
Member

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

Забавные чайники, которые делают вьюхи/вычисляемые столбцы, а потом
меняют тип базового поля на BLOB. Кто-нибудь таких встречал вообще?

Posted via ActualForum NNTP Server 1.5

29 июл 13, 15:53    [14632827]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Arioch
Member

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

ну вот, раз не ответили (при том что в топике были) - я и делаю вывод, что саим пока этот вопрос не продумывали и без доп-исследований (когда у них время будет) сами в точности не знают.
29 июл 13, 15:54    [14632834]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Arioch
Member

Откуда:
Сообщений: 11101
Гаджимурадов Рустам,

а у меня такое чувство - что ты - с другой планеты. И что теперь ?

Я - думаю, что делать такие операторы никто не будет - их просто слишком много будет. Поэтому я считаю, что оператора BLOB || date нету.

А ты считаешь - что такой оператор есть и значит тайпкаст выполняется уже где-то внутри оператора, implementation details.

А как-то от тебя не ожидал рассуждений на уровне "раз что-то компилируется - то это и есть спецификация", потому и не уточнял, как мне казалось, очевидное.
29 июл 13, 15:58    [14632862]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Arioch
Member

Откуда:
Сообщений: 11101
ibase.ru
Начиная с версии 2.1, в Firebird API появилась возможность при создании BLOB-а с клиента сразу сохранять его во временный файл


...и что потом ? файлы начнут удаляться ? или винчестер начнёт забиваться туевой хучей временных файлов ? или вместо FDB начнёт неуджержимо пузнуть pagefile ?

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

...предположу, что диск будет забиваться мусором, пока система не отстрелит сервер нафиг по превышению количества open file handles
29 июл 13, 16:01    [14632894]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Гаджимурадов Рустам
Member

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

Arioch> а у меня такое чувство - что ты - с другой планеты. И что теперь ?

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

> Я - думаю, что делать такие операторы никто не будет

Конечно, не будет, они уже есть. Впрочем, я уверен, что
ты сумеешь извернуться и выдать что-то очередное типа
"так не считается, это неявное преобразование типов".

> Поэтому я считаю, что оператора BLOB || date нету.

О, это сколько угодно. Ложки тоже нет, FB нет, меня нет, тебя нет.

> А как-то от тебя не ожидал рассуждений

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

P.S. Модуль и функцию не нужно подсказывать, надеюсь,
ты ведь сам найдёшь, знаток ты наш?

Posted via ActualForum NNTP Server 1.5

29 июл 13, 16:04    [14632918]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Гаджимурадов Рустам
Member

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

Оооо, Остапа понесло...
Arioch
...и что потом ? файлы начнут удаляться ? или винчестер начнёт забиваться туевой хучей временных файлов ? или вместо
FDB начнёт неуджержимо пузнуть pagefile ?

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

Ну хорош уже пургу нести-то, остановись... Кому неизвестно,
а у кого логика есть и голова на плечах. Да, будет расти не БД,
а временные файлы (которые итак будут созданы, без BLOB).
Это хорошо или плохо, по-твоему? Только не переспрашивай
меня, сам покумекай. Да, распухания (места на диске) никак не
миновать, потому как всё равно эти БЛОБы надо где-то хранить -
у тебя есть иные варианты кроме БД и файлов на диске?

Arioch
...предположу, что диск будет забиваться мусором, пока система не отстрелит сервер нафиг по превышению количества
open file handles

Ты когда это (превышение кол-ва открытых файлов) последний
раз видел-то? Какой год на дворе? И уж сам как-нибудь прикинь,
сколько и чего нужно наколбасить, чтобы это превышение таки
наступило - ещё не факт, что самому сервере от такой нагрузки
не поплохеет, без всяких БЛОБов...

Posted via ActualForum NNTP Server 1.5

29 июл 13, 16:11    [14632960]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Arioch
Member

Откуда:
Сообщений: 11101
http://www.ibase.ru/devinfo/ibtrans.htm

о чём и говорил.

в Firebird, Yaffil и InterBase 6.5 транзакции read_committed read (read only) стартуют сразу в состоянии committed, поэтому не удерживают мусорные записи. Т.е. такая транзакция может длиться часами без ущерба для производительности сервера. Наиболее характерный пример использования - работа со справочниками.


Понадобилось в справочник внести особенно длинную строку. Новичок чайник поменял VarChar(32000) на BLOB и... и понеслась.

Т.е. вот такие документы сейчас неявно предлагают новичкам (если кому-то не нравится слово "чайник") пробежаться по "всем хорошо известным" граблям.

Кстати, интересно было бы записать базу на CD-ROM, как там предлагается, и поконкатенировать блобы и посчитать LIST-другой.

http://www.firebirdsql.org/refdocs/langrefupd21-aggrfunc-list.html
Тут нет никаких ограничений на read-only бд или на долгоживущие транзакции.
И кстати, интересная вещь сказана: что все переметры функции преобразуются к строкам, т.е не к BLOB, а к VARCHAR неизвестного размера...

Тут лучше: http://firebirdsql.su/doku.php?id=list - но это НЕ документация.
Кроме того, тут говорится не о распухании файла базы, о распухании ОЗУ.



И простите за резкость, речь не о том что документация - дрянь, а пишут её криворучки. Ради этого не стоило бы расписывать.
А вот что мне не нравится, это идея что по всем документациям и FAQам раскиданы грабли (и это, увы, естественно. bit rotting никто не отменял), но вместо того, чтобы это признать, "отцы" говорят - всё хорошо, все и так давно это всё уже знают. Никого ни о чём заранее предупреждать не надо. Даже дети знают что read-only транзакция при обычной работе что-то все время пишет в БД. Вот это вот "все и так это знают" меня добивает, уж извините.
29 июл 13, 16:16    [14632989]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Dimitry Sibiryakov
Member

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

"Распухание базы" != "ущерб для производительности". Производительности вообще на размер
наплевать. Опытным пользователям - тоже. Это только новички почему-то трясутся за свою
коллекцию порнушки, которую пришлось бы стереть для освобождения винта.

Posted via ActualForum NNTP Server 1.5

29 июл 13, 16:21    [14633032]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Гаджимурадов Рустам
Member

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

Dimitry Sibiryakov> Производительности вообще на размер наплевать.

Это ты сильно двинул.

Posted via ActualForum NNTP Server 1.5

29 июл 13, 16:23    [14633047]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
Arioch
это идея что по всем документациям и FAQам раскиданы грабли

уже не первый раз, когда новая фича в ФБ неожиданно вызывает попаболь у применившего ее разработчика. Разработчики сервера не могут предусмотреть все варианты. Я знаю только один случай мотивированного отказа в фиче по причине плохого прогноза - это * в events.
29 июл 13, 16:26    [14633063]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Arioch
Member

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

да, но речь не о том немного. Речь о том, что когда описываешь недостатки документации - может быть три варианта ответа.

* Спасибо, исправили.
* Да, недостаток, но исправить не хватает рук и времени.
* Нет недостатков. Знатоки и без документации все знают, а чайников не жалко.

И вот последний подход он как раз и раздражает.
29 июл 13, 16:34    [14633105]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11038
Arioch
ibase.ru
Начиная с версии 2.1, в Firebird API появилась возможность при создании BLOB-а с клиента сразу сохранять его во временный файл


...и что потом ? файлы начнут удаляться ? или винчестер начнёт забиваться туевой хучей временных файлов ? или вместо FDB начнёт неуджержимо пузнуть pagefile ?
Речь о временном файле с данными GTT. Который один на процесс и удаляется вместе с ним.
29 июл 13, 16:48    [14633201]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11038
Arioch
"отцы" говорят - всё хорошо, все и так давно это всё уже знают.
Какие-такие "отцы" ? :)

Arioch
Речь о том, что когда описываешь недостатки документации
Для этого тоже есть трекер, между прочим
29 июл 13, 16:51    [14633224]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11038
kdv
кстати, hvlad, ау, напомни, когда временные блобы освобождаются
При наличии возможности - по завершению запроса (первого в стеке вызовов).
При отсутствии - по завершению тр-ции.
Временные блобы, созданные в автономной тр-ции, закрепляются не за ней, а за её родительской тр-цией.
retaining на то и retaining, чтобы удерживать контекст тр-ции до окончательного её завершения, так что он ничего не освобождает.

PS развели тут бурю в стакане воды, как дети малые прям :)
29 июл 13, 16:59    [14633271]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Arioch
Member

Откуда:
Сообщений: 11101
hvlad,

увы, в практическом смысле документация - не только ваши PDF, но и крупные стороние сайты, тот же Ibase
если бы на них тже можно было вешать баги в вашем трекере :-)

Но тогда мы возвращаемся обратно, если по * RETAINING нельзя освобождать блобы, то любая долгаю транзакция превращается в потенциальную бомбу. Вы же вроде движок на C++ переписали ? почему нельзя поменять тип blob-id на что-нибудь со счётчиком ссылок ?

Ну и если никак нельзя, то подумайте тогда над warning'ами. Что-то типа OIT, но для блобов. Если временный блоб не освобождён и не материализован в течении, например 5 минут - то надо начинать регулярно жаловаться в firebird.log
29 июл 13, 17:07    [14633307]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Arioch
Member

Откуда:
Сообщений: 11101
hvlad
kdv
кстати, hvlad, ау, напомни, когда временные блобы освобождаются
При наличии возможности - по завершению запроса (первого в стеке вызовов).
При отсутствии - по завершению тр-ции.


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

просто ведь копья тут ломаем уже семь страниц, именно пытаясь нащупать, что же это за "возможности" такие, где они ещё есть ,а где уже нету
29 июл 13, 17:10    [14633329]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
Arioch
почему нельзя поменять тип blob-id на что-нибудь со счётчиком ссылок ?

каких ссылок?
например, select substring(...блоб...) from 1mlnrecordstable. миллион временных блобов по 1й ссылке.
как тут поможет счетчик ссылок, вообще???

imho надо успокоиться, и перестать нервничать по этому поводу. С тем же успехом можно жаловаться на здоровенные временные файлы при
select varchar(32000), varchar(32000) from 1mlnrecordstable
order by 1, 2.
и много еще чего такого запредельного можно придумать.
29 июл 13, 17:14    [14633362]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Гаджимурадов Рустам
Member

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

hvlad> При наличии возможности - по завершению запроса (первого в стеке вызовов).

Как это определяется? И почему нельзя делать это же
при невозвращении БЛОБа из автономной транзакции?

Posted via ActualForum NNTP Server 1.5

29 июл 13, 17:21    [14633414]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11038
Arioch
Вы же вроде движок на C++ переписали ? почему нельзя поменять тип blob-id на что-нибудь со счётчиком ссылок ?
Можно. Но не тривиально.
И С++ тут не при чём :)

Arioch
временные блобы типа промежуточных результатов при конкатенации, в таком случае и должны чиститься сразу ?
Они и чистятся - по завершению топ-запроса, если наружу не выдаются.

Arioch
копья тут ломаем уже семь страниц
А зачем ? :)
29 июл 13, 17:32    [14633481]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11038
kdv
imho надо успокоиться, и перестать нервничать по этому повод
+1

PS Но и оставлять навсегда это тоже нельзя. Дойдут руки - сделаем и это.
29 июл 13, 17:33    [14633490]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Arioch
Member

Откуда:
Сообщений: 11101
kdv> каких ссылок?

http://www.rsdn.ru/article/cpp/smartptr.xml
TInterfacedObject :-)

> как тут поможет счетчик ссылок, вообще???

Я не могу точно сформулировать критерии - для этого нужно очень детально знать детали реализации.

1) если запрос unidirectional и данную строку клиент уже отфетчил и вытянул блоб - то удалять. (потребуется, чтобы клиент тоже считал ссылки и сообщал серверу, про получение первой и удаление последней. Сервер же будет считать ссчлки, по числу клиентов, кто может этот ID прочитать - т.е. кто его получал через какой-нибудь select и отрапортовал про первую ссылку)

2) если запрос (курсор) закрыт, то почему бы не считат ьвсе в нём промелькнувшие временные блобы освобождёнными ? Не надо миллионами коллекционировать ID на клиенте.

С тем же успехом можно жаловаться на здоровенные временные файлы при
select varchar(32000), varchar(32000) from 1mlnrecordstable order by 1, 2.


1) Эти файлы будут неконтролируемо расти, или будут уничтожены по закрытию курсора?

2) Они не являются базой данных. Для человека естественно предположить, что если транзакция "тоьлко-чтение" то и с Бд она совершает "только-чтение". Когда на клетке одна табличка, а внутри сидит что-то противоположное, это получается ловушка для всех, кроме археологов и аксакалов (да все уже три века знают, что 330 лет назад было решщено сделать так!). Когда описано одно, а реально делается другое - это надо описывать. Временные данные - это естественный процесс жизни любых программ. А вот запись новых данных в БД из read-only транзакции противоречит здравому смыслу, если только не знать "деталей реализации2 или не отслеживать форумы годами.
29 июл 13, 17:41    [14633550]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Arioch
Member

Откуда:
Сообщений: 11101
ну и до кучи. Проcили - получайте :-) http://tracker.firebirdsql.org/browse/DOC-89

Хотя я действительно был бы рад, если бы внутри "documentation" можно бы было вещать баги на ibase.ru, firebirdsql.su и т.д.
29 июл 13, 17:43    [14633562]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
Arioch
если запрос unidirectional и данную строку клиент уже отфетчил и вытянул блоб - то удалять. (потребуется, чтобы клиент тоже считал ссылки и сообщал серверу, про получение первой и удаление последней. Сервер же будет считать ссчлки, по числу клиентов, кто может этот ID прочитать

вообще не то. я привел пример. blob id передается на клиента. Дальше клиент МОЖЕТ получить содержимое по blob id. А может и выкинуть его. Никто этого не знает. И "счетчик" тут можно сделать только в том случае, если есть кэш одинаковых запросов, а его нет.

hvlad
Они и чистятся - по завершению топ-запроса, если наружу не выдаются.

то есть, в примере Таблоида 10653155
для запроса
select max(char_length(s) - char_length(replace(s,'ABC','')) ) from t
временые блобы будут освобождены при закрытии запроса? (EOF, и т.д.)
29 июл 13, 17:53    [14633633]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11038
Arioch
А вот запись новых данных в БД из read-only транзакции противоречит здравому смыслу
Ты не прав, остынь и подумай ещё раз.

Сортировки в read-only тр-ции можно делать ? А кто сказал, что завтра временные данные сортировки не будут жить в БД (как у MSSQL, например) ?

Тебя не смущает, что при старте RO тр-ции есть запись в header page и в TIP ?

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

На этом предлагаю завершить дискуссию на тему "абсолютности" RO тр-ции :)
29 июл 13, 18:11    [14633704]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11038
kdv
в примере Таблоида 10653155
для запроса
select max(char_length(s) - char_length(replace(s,'ABC','')) ) from t
временые блобы будут освобождены при закрытии запроса? (EOF, и т.д.)
Если там не зарыто что-то, чего я не знаю\не помню, то - да.
29 июл 13, 18:12    [14633713]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
hvlad
Тебя не смущает, что при старте RO тр-ции есть запись в header page и в TIP ?

и генераторы тоже.
29 июл 13, 18:19    [14633754]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Arioch
Member

Откуда:
Сообщений: 11101
hvlad,

а как же kdv'шный FAQ по записи файла базы на CD-ROM ?
29 июл 13, 19:51    [14634156]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
Arioch
а как же kdv'шный FAQ по записи файла базы на CD-ROM ?

и что там? необходимость режима read-only всей базы для true read-only взрывает мозг?
29 июл 13, 20:23    [14634239]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11038
Arioch
а как же kdv'шный FAQ по записи файла базы на CD-ROM ?
А что с ним ?
29 июл 13, 20:29    [14634257]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Arioch
Member

Откуда:
Сообщений: 11101
hvlad,

с тем что работа r-o транзакций без модификации файла реализована и считать, что вдруг это отменится ипридется обязательно что-то писать... ну не более вероятно, чем убивание любого другого функционала.

А кто сказал, что завтра временные данные сортировки не будут жить в БД (как у MSSQL, например) ?


"Ух ты!"

А как мне, клиенту, получить ID этих временных данных и вычитать их в свою программу? никак? Тогда можно считать, что их не существует: курсор закрыт - данные освобождены. Хранить их "до востребования" как болбы с публичным id движку не нужно.

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

PS. что же касается модификации генераторов из r-o транзакций, на мой взгляд сама такая возможность - недоработка сервера.
Да, для предотвращения изменения генераторов и внешних таблиц нужны будут проверки в других местах, чем у обычных таблиц.
Тем не менее сама возможность по ошибке изменять данные в рамках r-o операции неприятна и чревата не пойманными вовремя ошибками.
30 июл 13, 11:07    [14636092]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11038
Arioch,

Аргументы и объяснения тебе привели. Ты с ними не согласен, твоё право.
Аргументов от тебя, кроме субъективного интуитивного восприятия термина read-only transaction - нет.
Ты споришь ради самого спора, нет конструктива.
Не вижу смысла в этом участвовать.
30 июл 13, 11:13    [14636131]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
Arioch
Тем не менее сама возможность по ошибке изменять данные в рамках r-o операции неприятна и чревата не пойманными вовремя ошибками.

ты сейчас договоришься. По твоему, для r-o транзакций надо запретить любые модификации, то есть
- возможность сортировок
- возможность работы с GTT
- модификацию генераторов
- временные блобы
- сборку мусора

то есть, любые операции записи, которые могут происходить в движке для RO транзакций. так, что ли? И, по какой еще "ошибке" могут изменяться данные в r-o?
(присоединяюсь к hvlad, ибо дискуссия переходит в неконструктив).
30 июл 13, 11:19    [14636172]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
CyberMax
Member

Откуда: Хабаровск
Сообщений: 1390
Arioch,

Реализация Владом изменения GTT в RO-транзакции сделала возможным запускать в ней отчеты (раньше приходилось использовать RW-транзакцию). Так же появилась возможность делать кое-какие финты из постоянной RO-транзакции. В общем, жизнь облегчило, однозначно.
30 июл 13, 11:19    [14636173]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
Arioch
с тем что работа r-o транзакций без модификации файла реализована и считать

не реализована она была никогда. r-o транзакции существуют сто лет, и они read-only только в том смысле, что в них запрещен модифицирующий DML/DDL, не более того.
read-only для БД - совершенно другая фишка, и появилась она в IB 6.0, и к r-o транзакциям не имеет ни малейшего отношения.
30 июл 13, 11:21    [14636181]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Arioch
Member

Откуда:
Сообщений: 11101
"возможность сортировок" - а давно это стало записьюю данных, которые пользователь может читать/изменять напрямую ?

"- сборку мусора" - код на IBX, который читает мусор - в студию!

"временные блобы" - то, что их размножение недоработка - согалсились, кажется, все. Не совсем понятно как это подвлять ,не запрещая долгосрочные транзакции в целом.

"- модификацию генераторов" - да, я так считаю.

"возможность работы с GTT" уже спорно. Но как минимум GTT не сохраняюстя в БД на постоянной основе и могут в каком-то смысле рассматриваться как внутренние переменные соединения. Как и временные блобы. Но в отличие от последний GTT поддаются контрорлю имогут быть сознательно почищшены в любой нужный момент.

"возможность делать кое-какие финты из постоянной RO-транзакции. В общем, жизнь облегчило, однозначно" Не новость - любая отмена ограничений упрощает жизнь. По крайней мере поначалу и в каких-то пределах. Вообще - любая и везде.

В общем, никто никого не убедит, на этом можно расходиться. Все кто хотел высказаться - высказались. Баг повешен, информацией омбенялись, далее будет только бег по кругу.
30 июл 13, 12:00    [14636378]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Arioch
Member

Откуда:
Сообщений: 11101
ах да, пропустил.

kdv
Arioch
потребуется, чтобы клиент тоже считал ссылки и сообщал серверу

Дальше клиент МОЖЕТ получить содержимое по blob id. А может и выкинуть его. Никто этого не знает.


тут мы казали одно и то же по сути.

да, потребуется модифицировать клиентские либы, но для того чтобы они могли модифицироваться - должен сначала появиться соотв. API в сервере

И "счетчик" тут можно сделать только в том случае, если есть кэш одинаковых запросов, а его нет.


а вот тут не понял.

Ну хорошо, Вася и Маша прислали одинаковый запрос, он закэшировался... И как это поможет понять можно уже удалять блоб или пока ещё нет, пока транзакции обоих живые ?
30 июл 13, 14:45    [14637740]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
Arioch
Ну хорошо, Вася и Маша прислали одинаковый запрос, он закэшировался... И как это поможет понять можно уже удалять блоб или пока ещё нет, пока транзакции обоих живые ?

счетчик ссылок можно делать только если объект может использоваться более чем одним "другим объектом" (пользователем, и чем угодно).
например, я сделал
select cast('1' as blob) from rdb$database
сервер сделал временный блоб, отдал мне blobid, ждет когда я закрою транзакцию.

Вася сделал
select cast('2' as blob) from rdb$database
сервер сделал временный блоб, отдал blobid, ждет когда Вася закроет транзакцию.

Кроме меня никому мой blobid не интересен. Также и в отношении Васи. Куда тут уперся "счетчик ссылок"?

Второй вариант. Я и Вася сделали запрос
select cast('3' as blob) from rdb$database

сейчас мы получаем разные blobid. Но если бы был кэш запросов, то сервер бы отдал УЖЕ СФОРМИРОВАННЫЙ РЕЗУЛЬТАТ, включая blobid, тому, кто выполнил этот запрос вторым. Вот тут - да, нужен счетчик ссылок.
Во всех остальных случаях счетчик ссылок на временный блоб не имеет смысла.
30 июл 13, 16:31    [14638575]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Dimitry Sibiryakov
Member

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

kdv
Во всех остальных случаях счетчик ссылок на временный блоб не имеет смысла.

В ряде случаев имело бы смысл конструкцию blob = blob||something преобразовывать в
seg_append(blob, something) как это делается внутри LIST.

Счётчик ссылок на перманентные блобы имел бы смысл для ускорения UPDATE записи с блобом
при которой сейчас создаётся его копия вне зависимости от того изменялось его значение или
нет.

Posted via ActualForum NNTP Server 1.5

30 июл 13, 16:36    [14638615]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11038
kdv
Второй вариант. Я и Вася сделали запрос
select cast('3' as blob) from rdb$database

сейчас мы получаем разные blobid. Но если бы был кэш запросов, то сервер бы отдал УЖЕ СФОРМИРОВАННЫЙ РЕЗУЛЬТАТ, включая blobid
Нет. Ваши blobid могут даже быть одинаковыми, но по ним вы будете доставать физически разные временные блобы.
30 июл 13, 16:58    [14638791]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11038
Dimitry Sibiryakov
UPDATE записи с блобом
при которой сейчас создаётся его копия вне зависимости от того изменялось его значение или
нет.
Выдыхай, Дима :)
30 июл 13, 16:59    [14638797]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Arioch
Member

Откуда:
Сообщений: 11101
hvlad
Нет. Ваши blobid могут даже быть одинаковыми, но по ним вы будете доставать физически разные временные блобы.


а два соединения одного клиента? две транзакции одного соединения ? вообще это как-то стрёмно, ведь в БД эти блобы лежат одновременно и должны отличаться по id
30 июл 13, 17:21    [14638934]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29176
hvlad
Нет. Ваши blobid могут даже быть одинаковыми, но по ним вы будете доставать физически разные временные блобы.

да пофиг. кэша запросов нет, поэтому и говорить не о чем. Был бы кэш, получили бы разные blob_id, или одинаковые blobid, но получили бы одно содержимое, одного временного блоба.
30 июл 13, 17:27    [14638967]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Arioch
Member

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

...а кэша запросов не будет ,потому что за одним-то клиентом не можем отследить, а за сотней - вообще труба.

тут опять курица и яйцо. Нет механизма отслеживать использование id ( через счетчик или еще как-нибудь) - нельзя их разделять - нельзя делать кэш запросов с временными блобами - не нужен механизм отслеживания использования блобов. Всё, вышли на круг.
30 июл 13, 17:36    [14639014]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11038
kdv
кэша запросов нет, поэтому и говорить не о чем. Был бы кэш, получили бы разные blob_id, или одинаковые blobid, но получили бы одно содержимое, одного временного блоба.
Ты говоришь о кеше результатов запросов.
Ибо кеш запросов - это кеш их планов выполнения. И он (частично) у нас есть.
Не путай меня :)
30 июл 13, 17:56    [14639108]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11038
Arioch
вообще это как-то стрёмно, ведь в БД эти блобы лежат одновременно и должны отличаться по id
Для временных блобов blob_id привязан к создавшей его тр-ции и только она знает реальный адрес блоба в БД. Не надо фантазировать.
30 июл 13, 17:57    [14639116]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

Откуда:
Сообщений: 77
гмм... в общем ясно, что ничего не ясно.
Задачку по доке нашел изучил, но так и не понял запланировано ли что-нибудь на доработку или остается как есть?

Спасибо.
4 окт 13, 15:40    [14924764]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11038
Drag,

что-нибудь всегда запланировано на доработку.
Спрашивай конкретнее.
4 окт 13, 15:52    [14924898]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

Откуда:
Сообщений: 77
В воскресение база бекап/рестор 16Гб, в понедельник уже 30, а вчера с 2:00 до 2:30 быренько выросла до 60ти. Как понять из-за чего, из-за какого запроса... монитор какой-то на сервере с логированием лепить... не знаю такого хорошего...

Ну в результате ваших обсуждений последние 4 стр. форума какие-то задачки появились?

Спасибо.
4 окт 13, 16:03    [14924991]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
чччД
Guest
Drag
В воскресение база бекап/рестор 16Гб, в понедельник уже 30, а вчера с 2:00 до 2:30 быренько выросла до 60ти...

А не должна была?
4 окт 13, 16:19    [14925119]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10635
Drag,

сам то выводы сделал? Конкатенацию блобов убрал?
4 окт 13, 16:20    [14925129]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

Откуда:
Сообщений: 77
чччД
Drag
В воскресение база бекап/рестор 16Гб, в понедельник уже 30, а вчера с 2:00 до 2:30 быренько выросла до 60ти...

А не должна была?


после бекап/рестора опять 16

Симонов Денис
Drag,

сам то выводы сделал? Конкатенацию блобов убрал?


да выводы то я сделал. Но найти иголку в стоге сена не реально. Инструментов для поиска нет :(
Не воспроизводится у меня. Не знаю я что там эти хитрые юзеры вытворяют...
4 окт 13, 18:04    [14925734]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10635
Drag,

да ладно. IBExpert поиск по метаданным. Ищем функцию LIST и все столбцы/параметры объявленные как BLOB, а по ним уже смотрим зависимости. Вот в приложении уже посложней будет найти, но тоже можно.
4 окт 13, 18:33    [14925810]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11038
Drag
Но найти иголку в стоге сена не реально. Инструментов для поиска нет :(
Есть трейс в 2.5 и FBScanner\FBDataGuard для всех версий

Drag
Не знаю я что там эти хитрые юзеры вытворяют...
Только то, что позволяет им их ПО
4 окт 13, 18:36    [14925819]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Ованес Сусанян
Guest
Drag
Но найти иголку в стоге сена не реально.
Затолкай в планировщик задание "фоткать" каждые 3-5 минут размер файла. Если он стал "странно сильно" увеличиваться, то запускай в этот момент трейс через fbsvcmgr (в том же самом скрипте добавь соотв-щий вызов и засеки время). Через 20-30 минут останови трейс и посмотри в его лог.
4 окт 13, 19:09    [14925875]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Dimitry Sibiryakov
Member

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

Ованес Сусанян
запускай в этот момент трейс через fbsvcmgr

А почему не запустить его сразу, поставив фильтр запросов на "LIST("?..

Posted via ActualForum NNTP Server 1.5

4 окт 13, 19:40    [14925934]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

Откуда:
Сообщений: 77
hvlad
Drag
Но найти иголку в стоге сена не реально. Инструментов для поиска нет :(
Есть трейс в 2.5 и FBScanner\FBDataGuard для всех версий

Drag
Не знаю я что там эти хитрые юзеры вытворяют...
Только то, что позволяет им их ПО


Согласен, классная штука, сам активно пользую, купил бы даже ее. Но гадость такая работает только на один процессор (ядро). В промышленной эксплуатации ставить нельзя.

Ованес Сусанян
Drag
Но найти иголку в стоге сена не реально.
Затолкай в планировщик задание "фоткать" каждые 3-5 минут размер файла. Если он стал "странно сильно" увеличиваться, то запускай в этот момент трейс через fbsvcmgr (в том же самом скрипте добавь соотв-щий вызов и засеки время). Через 20-30 минут останови трейс и посмотри в его лог.


Так сделал такое. Но я не админ, не могу следить что у него там в Днепропетровске происходит... Хотя может набросать побыстрому какую-то мониторилку размера файла, что бы сразу мне имейл слала... О! вот это мысль. Надо обдумать... туда (в имейл) можно сразу и все запросы активные пихать...

Спасибо за идею :)
4 окт 13, 19:47    [14925948]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Dimitry Sibiryakov
Member

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

Drag
работает только на один процессор (ядро)

Чего-чего?

Posted via ActualForum NNTP Server 1.5

4 окт 13, 19:55    [14925974]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

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

да вот незадача. он же (fbscanner) как прокси выступает. Все клиенты коннектятся к нему, а он транслирует на FB Server. Так вот он нагружает только одно ядро. Все простаивают, а одно на 100%.
4 окт 13, 20:00    [14925992]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Таблоид
Member

Откуда:
Сообщений: 9456
Блог
Dimitry Sibiryakov
Ованес Сусанян
запускай в этот момент трейс через fbsvcmgr

А почему не запустить его сразу, поставив фильтр запросов на "LIST("?..
Не взлетает оно. Несмотря на то, что штатный пример трейс-конфига гласит:
    39          # SQL query filters.
40 #
41 # Only SQL statements falling under given regular expression are reported
42 # in the log.
43 #include_filter
- нижеследующий пример говорит, что нем все регулярки понимаются парсером конфига трейса.

Сначала пробуем на зуб SIMILAR TO (ведь именно оно используется парсером конфига трейса!) в ISQL:
SQL> set list on;
SQL> select iif('select f01,f02,list(s01) from t' similar to '%list`(%' escape '`', 1, 0) from rdb$database;

CASE 1
-- (т.е. всё пучком, раскатываем дальше губу и идём в конфиг трейса с этим регэкспом...)

Однако, в ответ на вот это:
<database (%[\\/](ccc|foo|bar|test%).fdb)|(foo|bar|idx_test|test_alias)>
  enabled true

  include_filter = '%list`(%' escape '`'
  # and also poor for:
  # include_filter = %list`(% escape '`'
  # include_filter = %list`(% escape `
  ...
</database>
- первый же селект при включенном трейсе вывалит в логе последнего ошибку:
Error creating trace session for database "C:\MIX\FIREBIRD\FB25\FOO.FDB":
error while compiling regular expression "%list`(%"
4 окт 13, 20:30    [14926068]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Таблоид
Member

Откуда:
Сообщений: 9456
Блог
Drag
не могу следить что у него там в Днепропетровске происходит...
Тогда я знаю, кому должен в ДП этот админ накрыть поляну... Но промолчу

Drag
Хотя может набросать побыстрому какую-то мониторилку размера файла, что бы сразу мне имейл слала...
Дык про то и речь: пущай не админ, а робот следит за этим. И включит (ненадолго!) трейс, когда база попрёт вверх.
4 окт 13, 20:34    [14926081]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Dimitry Sibiryakov
Member

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

Таблоид
первый же селект при включенном трейсе вывалит в логе последнего ошибку

Возможно, потому, что кляуза escape там не поддерживается и escape-символ - фиксированный
заднеслэш.

Posted via ActualForum NNTP Server 1.5

4 окт 13, 20:43    [14926106]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11038
Dimitry Sibiryakov
Таблоид
первый же селект при включенном трейсе вывалит в логе последнего ошибку

Возможно, потому, что кляуза escape там не поддерживается и escape-символ - фиксированный
заднеслэш.
+100500
:)

2Таблоид: нет, настраиваемого escape в конфиге не будет
4 окт 13, 20:51    [14926124]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Таблоид
Member

Откуда:
Сообщений: 9456
Блог
hvlad
2Таблоид: нет, настраиваемого escape в конфиге не будет
гы... а ведь точно - пропёрло! :-)
2 Drag: добавь в конфиг трейса вот это:
include_filter = %list\(% escape \
- вроде бы показывает только их. Но проверь, чтобы у тебя не было UDF'ок с именами вида ...list... - а то путаться будут. Ну, или сам доковыривай этот регексп - практика всегда полезна :-)
4 окт 13, 20:58    [14926142]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Таблоид
Member

Откуда:
Сообщений: 9456
Блог
2 hvlad: а насколько реально показывать в статистике стейтмента объем временного блоба, который был создан при его выполнении ? (я про ФБ-3.х, разумеется)
4 окт 13, 21:01    [14926148]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11038
Таблоид,

ну какой нафиг escape ???
Вся строка справа от "=" есть регулярное выражение, вся целиком
4 окт 13, 21:03    [14926156]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11038
Таблоид
2 hvlad: а насколько реально показывать в статистике стейтмента объем временного блоба, который был создан при его выполнении ? (я про ФБ-3.х, разумеется)
А что тебе это даст ?
А что ты на самом деле хочешь узнать ?
4 окт 13, 21:05    [14926164]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Таблоид
Member

Откуда:
Сообщений: 9456
Блог
hvlad
ну какой нафиг escape ???
Вся строка справа от "=" есть регулярное выражение, вся целиком
Не понял тебя... у мну именно ЭТОТ вариант работает так, как надо: фильтрует только стейтменты с наличием в них "list(" и отбрасывает всё остальное.
Покажи, плз, тот вариант, который ты считаешь правильным.
4 окт 13, 21:09    [14926170]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Таблоид
Member

Откуда:
Сообщений: 9456
Блог
hvlad
Таблоид
2 hvlad: а насколько реально показывать в статистике стейтмента объем временного блоба, который был создан при его выполнении ? (я про ФБ-3.х, разумеется)
А что тебе это даст ?
А что ты на самом деле хочешь узнать ?
Хочу видеть число таких стейтментов, причём не всех, а тех, что в пределах одной транзакции. Ибо они приведут к росту размера базы. Не ?
4 окт 13, 21:11    [14926179]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11038
Таблоид
Хочу видеть число таких стейтментов
OMG, каких - таких ???
4 окт 13, 22:17    [14926478]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11038
Таблоид
hvlad
ну какой нафиг escape ???
Вся строка справа от "=" есть регулярное выражение, вся целиком
Не понял тебя... у мну именно ЭТОТ вариант работает так, как надо: фильтрует только стейтменты с наличием в них "list(" и отбрасывает всё остальное.
Или в парсере регэкспов есть недокументированные возможности, или ты снова морочишь мне голову...
Таблоид
Покажи, плз, тот вариант, который ты считаешь правильным.
Ну какой может получиться вариант из этого
Таблоид
%list\(% escape \
БЕЗ escape ?

PS Это у меня затмение под вечер (не пил!), или у вас там вирус-тупирус зверствует ? :)
4 окт 13, 22:20    [14926483]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Таблоид
Member

Откуда:
Сообщений: 9456
Блог
hvlad
Таблоид
Хочу видеть число таких стейтментов
OMG, каких - таких ???
Которые приводят к созданию временных блобов, сохраняемых в .fdb-файле - даже если ни одна из fixed-таблиц в таком стейтменте не упоминается вообзе.
5 окт 13, 00:02    [14926951]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Таблоид
Member

Откуда:
Сообщений: 9456
Блог
hvlad
Ну какой может получиться вариант из этого
Таблоид
%list\(% escape \
БЕЗ escape ?
мну подумкалось, что без дописки "escape \" это не будет работать, т.к. внутри шаблона юзается круглая скобка.
Но оказалось, что работает :-)
Правда, трейс с таким шаблоном не отлавливает вот такой изврат:
SQL> select char_length( list    (rdb$field_name) ) from rdb$fields; -- да-да, пробелы между `list` и `(`

 CHAR_LENGTH
============
        3999
Но вряд ли это вообще есть у кого-то из ФБ-собратьев :-)
5 окт 13, 00:09    [14926973]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Dimitry Sibiryakov
Member

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

Таблоид
Правда, трейс с таким шаблоном не отлавливает вот такой изврат:

А добавить в шаблон "[:WHITESPACE:]*" мешает что?..

Posted via ActualForum NNTP Server 1.5

5 окт 13, 00:23    [14927023]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Таблоид
Member

Откуда:
Сообщений: 9456
Блог
Dimitry Sibiryakov
Таблоид
Правда, трейс с таким шаблоном не отлавливает вот такой изврат:

А добавить в шаблон "[:WHITESPACE:]*" мешает что?..
мне ? ничего :-)
Но пущай Drag займётся усовершенствованием, это ведь ему надо.
5 окт 13, 00:32    [14927042]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11038
Таблоид,

Ты опять напоролся на багофичу, на этот раз в парсере конфигурации трейса.
Он игнорирует второе и остальные слова в значениях параметров, т.е. из твоего шаблона

%list\(% escape \

он взял только %list\(% и выкинул остальную ересь.

Для того, чтобы учитывались все слова, нужно взять в шаблон в кавычки, вот так
<database>
enabled true
include_filter "%list\(% escape \"
...
</database>

И при первом же коннекте, в трейсе появляется
Error creating trace session for database "xxx.FDB":
error while compiling regular expression "%list\(% escape \"

Насколько я помню, эта багофича даже обсуждалась. Изменяться в 2.5 это не будет.
В 3 я это не проверял, но парсер конфигов там другой.
5 окт 13, 01:08    [14927131]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
oleg_m
Member

Откуда:
Сообщений: 1101
Drag
да вот незадача. он же (fbscanner) как прокси выступает. Все клиенты коннектятся к нему, а он транслирует на FB Server. Так вот он нагружает только одно ядро. Все простаивают, а одно на 100%.


Какое количество соединений пропущено через FBScanner? Ну и покажи FBScannerSVC.cfg
Было недавно похожее обращение в саппорт про CPU 100%, но там была явная ошибка в настройках.
(пока не исправил этот случай)

У меня стоит в продакшене, коннектов < 80шт, никогда не видел нагрузки на одно ядро даже в 15%.
Сейчас специально поделил время работы сервиса на CPUTime. Получилось в среднем 3,8% CPU usage (от одного ядра).
6 окт 13, 00:03    [14929157]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

Откуда:
Сообщений: 77
oleg_m
Drag
да вот незадача. он же (fbscanner) как прокси выступает. Все клиенты коннектятся к нему, а он транслирует на FB Server. Так вот он нагружает только одно ядро. Все простаивают, а одно на 100%.


Какое количество соединений пропущено через FBScanner? Ну и покажи FBScannerSVC.cfg
Было недавно похожее обращение в саппорт про CPU 100%, но там была явная ошибка в настройках.
(пока не исправил этот случай)

У меня стоит в продакшене, коннектов < 80шт, никогда не видел нагрузки на одно ядро даже в 15%.
Сейчас специально поделил время работы сервиса на CPUTime. Получилось в среднем 3,8% CPU usage (от одного ядра).


Может быть из-за того, то пользовал бесплатную версию?
Если да, то завтра же пойду к начальству вытряхивать на покупку полной версии.

-----

По поводу листов... пересмотрел опять все упоминания этих (г)Листов в коде, нет ничего подозрительного... так что трейсить буду всё... скажем раз в 30 сек все активные запросы... тот что нужен мне скорее всего будет светится так долго как будет расти база...
6 окт 13, 01:36    [14929510]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
oleg_m
Member

Откуда:
Сообщений: 1101
Drag
Может быть из-за того, то пользовал бесплатную версию?

Нет. Бесплатная версия отличается не количеством багов.
6 окт 13, 03:07    [14929654]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

Откуда:
Сообщений: 77
oleg_m,

написал. правда, решил смотреть только MON$STATE = 1... не знаю правильно ли...
Кстати... вывел все колонки, что и в IBExpert'e в датабейс мониторинге.
Какая из них должна стать невероятно огромная? MON$PAGE_WRITES?
6 окт 13, 15:16    [14930154]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

Откуда:
Сообщений: 77
Вот такие колонки вывожу. Какие из них мне убрать (для анализа причин увеличения не нужны?):
A.MON$USER
ST.MON$STATEMENT_ID
ST.MON$ATTACHMENT_ID
ST.MON$TRANSACTION_ID
ST.MON$TIMESTAMP
ST.MON$SQL_TEXT
R.MON$RECORD_SEQ_READS
R.MON$RECORD_IDX_READS
R.MON$RECORD_INSERTS
R.MON$RECORD_UPDATES
R.MON$RECORD_DELETES
R.MON$RECORD_BACKOUTS
R.MON$RECORD_PURGES
R.MON$RECORD_EXPUNGES
IO.MON$PAGE_READS
IO.MON$PAGE_WRITES
IO.MON$PAGE_FETCHES, IO.MON$PAGE_MARKS
6 окт 13, 15:20    [14930161]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
oleg_m
Member

Откуда:
Сообщений: 1101
Drag
oleg_m,

написал.

куда?


Drag
правда, решил смотреть только MON$STATE = 1...

по таблицам монитоинга - не ко мне :-)
не практикую.
6 окт 13, 23:52    [14931522]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

Откуда:
Сообщений: 77
oleg_m,

сорри, вы оказались правы. перепроверил у себя локально. запустил 4 IBExpert'a и в каждом по запросу... нагрузились все ядра равномерно...
Что-то значит я просмотрел... почему же было все на одно ядро?...
7 окт 13, 09:14    [14932054]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

Откуда:
Сообщений: 77
oleg_m,

Извините, что пишу здесь, но на iBase.ru меня не авторизируют, а по почте support@ib-aid.com не отвечают.

Как можно сформировать платежку и оплатить FBScanner?
Или хоть ткните где об этом можно почитать.

Спасибо.
10 окт 13, 14:55    [14951126]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

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

а что, на sales@ibase.ru надо авторизоваться? Отправляете запрос, в ответ шлют счет, оплачиваете, и т.д.
10 окт 13, 18:03    [14952652]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

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

я говорил про форум. (от kdv@ibase.ru: Ваша учётная запись в настоящее время неактивна и должна быть одобрена
администратором прежде, чем вы сможете войти на конференцию.)
А за имейл спасибо. сейчас отправлю.
10 окт 13, 19:27    [14952991]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
kdv
Member

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

обращаться за покупкой на форум - по-моему это странно. На ibase.ru все явки и пароли есть. Да и на ib-aid.com есть вверху ссылка Russian, которая тупо указывает на ibase.ru.
IBSurgeon работает на зарубеж, iBase.ru - на Россию. Две компании, а люди одни и те же. Все русские.

Drag
Ваша учётная запись в настоящее время неактивна и должна быть одобрена
администратором прежде, чем вы сможете войти на конференцию.

там засилье спам-регистраций, поэтому активацию учетных записей пришлось перевести в ручной режим, но поскольку из них 99.999% спам, я их и не проверяю вообще.
10 окт 13, 20:36    [14953202]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

Откуда:
Сообщений: 77
!!!РАЗОБРАЛСЯ!!!

Написал такую вот утилитку.
Раз в пол минуты мониторит размер БД и если он больше на 100МБ по отношению к прошлому замеру, смотрит все текущие запросы и шлет мне по почте.

Если кому пригодится, то вот код
PAS
+

unit fmMain;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, IdStackWindows,
  Dialogs, IdBaseComponent, IdComponent, DB, FIBDataSet,
  pFIBDataSet, FIBDatabase, pFIBDatabase, cxGraphics, cxControls, cxLookAndFeelPainters, cxContainer,
  cxEdit, cxMaskEdit, cxDropDownEdit, cxMRUEdit, cxTextEdit, cxLabel, cxGroupBox, ExtCtrls, StdCtrls,
  IdMessage, IdTCPConnection, IdTCPClient, IdExplicitTLSClientServerBase, IdMessageClient,
  IdSMTPBase, IdSMTP, cxLookAndFeels;

type
  TfMain = class(TForm)
    cxGroupBox1: TcxGroupBox;
    lblLogin: TcxLabel;
    edLoginA: TcxTextEdit;
    lblPassword: TcxLabel;
    edPasswordA: TcxTextEdit;
    lbServer: TcxLabel;
    edServerNameA: TcxMRUEdit;
    lbDataBase: TcxLabel;
    edDBPathA: TcxMRUEdit;
    Timer1: TTimer;
    Button1: TButton;
    DBArch: TpFIBDatabase;
    pFIBTransaction1: TpFIBTransaction;
    ds: TpFIBDataSet;
    SMTP: TIdSMTP;
    IdMsgSend: TIdMessage;
    Button2: TButton;
    procedure Button1Click(Sender: TObject);
    procedure Timer1Timer(Sender: TObject);
    procedure Button2Click(Sender: TObject);
  private
    LastSize: Int64;
    procedure SendMail(AIsTest: Boolean);
    procedure Send;
    function CheckSize(AIsTest: Boolean): Boolean;
    { Private declarations }
  public
    { Public declarations }
  end;

var
  fMain: TfMain;

implementation

{$R *.dfm}

procedure TfMain.Send;
var
  i: Integer;
begin
  IdMsgSend.From.Text := 'user@mail.ua';
  IdMsgSend.Recipients.EMailAddresses := 'my@mail.ua';
  IdMsgSend.Priority := TIdMessagePriority(2);
  IdMsgSend.Subject := FloatToStrF(LastSize / 1000000000, ffNumber, 4, 2) + 'GB - DB BIG SIZE!';
  IdMsgSend.Body.Text := 'SQLs:';
  for i := 0 to ds.RecordCountFromSrv - 1 do
  begin
    IdMsgSend.Body.Add('USER: ' + ds.Fields[0].AsString);
    IdMsgSend.Body.Add('Statement: ' + ds.Fields[1].AsString);
    IdMsgSend.Body.Add('Attachment: ' + ds.Fields[2].AsString);
    IdMsgSend.Body.Add('Transaction: ' + ds.Fields[3].AsString);
    IdMsgSend.Body.Add('Started: ' + ds.Fields[4].AsString);
    IdMsgSend.Body.Add('SQL: ' + ds.Fields[5].AsString);
    IdMsgSend.Body.Add('Non-indexed R: ' + ds.Fields[6].AsString);
    IdMsgSend.Body.Add('Indexed R: ' + ds.Fields[7].AsString);
    IdMsgSend.Body.Add('Records Ins: ' + ds.Fields[8].AsString);
    IdMsgSend.Body.Add('Records Upd: ' + ds.Fields[9].AsString);
    IdMsgSend.Body.Add('Records Del: ' + ds.Fields[10].AsString);
    IdMsgSend.Body.Add('Records B/O: ' + ds.Fields[11].AsString);
    IdMsgSend.Body.Add('Records Pur: ' + ds.Fields[12].AsString);
    IdMsgSend.Body.Add('Records Exp: ' + ds.Fields[13].AsString);
    IdMsgSend.Body.Add('Page R: ' + ds.Fields[14].AsString);
    IdMsgSend.Body.Add('Page W: ' + ds.Fields[15].AsString);
    IdMsgSend.Body.Add('Page F: ' + ds.Fields[16].AsString);
    IdMsgSend.Body.Add('Page M: ' + ds.Fields[17].AsString);
    IdMsgSend.Body.Add('-------------------');
    IdMsgSend.Body.Add('-------------------');
    IdMsgSend.Body.Add('-------------------');

    ds.Next;
  end;
  IdMsgSend.ContentType := 'text/plain';
  SMTP.Host := 'smtp.mail.ua';
  SMTP.Port := 25;

  SMTP.Connect;
  try
    SMTP.Send(IdMsgSend);
    SMTP.Disconnect;
  except
    on e : exception do
    begin
      Application.MessageBox(PChar('Неможливо надіслати лист: ' + e.Message), PChar(Application.Title), MB_OK or MB_ICONWARNING);
      SMTP.Disconnect;
    end;
  end;
end;

procedure TfMain.SendMail(AIsTest: Boolean);
begin
  try
    DBArch.Connected := False;
    DBArch.DBName := edServerNameA.Text + ':' + edDBPathA.Text;
    DBArch.ConnectParams.UserName := edLoginA.Text;
    DBArch.ConnectParams.Password := edPasswordA.Text;
    DBArch.Connected := True;

    ds.Open;
    if CheckSize(AIsTest) then
      Send;
    ds.Close;

    DBArch.Connected := False;
  except
    on e : exception do
    begin
      Application.MessageBox(PChar('Неможливо з`єднатись з базою: '+e.Message),
                             PChar(Application.Title),
                             MB_OK or MB_ICONWARNING);
       DBArch.Connected := False;
      if edDBPathA.CanFocus then
        edDBPathA.SetFocus;
    end;
  end;
end;

procedure TfMain.Button2Click(Sender: TObject);
begin
  Timer1.Enabled := False;
  LastSize := 0;
  Timer1.Enabled := True;
end;

function TfMain.CheckSize(AIsTest: Boolean): Boolean;
var
  SearchRec: TSearchRec;
begin
  if FindFirst(ExpandFileName(DBArch.DBFileName), faAnyFile, SearchRec) = 0 then
  begin
    Result := SearchRec.Size - LastSize > 100000000;
    LastSize := SearchRec.Size;
  end
  else
    Result := False;
  Result := Result or AIsTest;
  FindClose(SearchRec);
end;

procedure TfMain.Timer1Timer(Sender: TObject);
begin
  Timer1.Enabled := False;
  SendMail(False);
  Timer1.Enabled := True;
end;

procedure TfMain.Button1Click(Sender: TObject);
begin
  SendMail(True);
end;

end.



DFM
+

object fMain: TfMain
  Left = 0
  Top = 0
  Caption = 'fMain'
  ClientHeight = 176
  ClientWidth = 341
  Color = clBtnFace
  Font.Charset = DEFAULT_CHARSET
  Font.Color = clWindowText
  Font.Height = -11
  Font.Name = 'Tahoma'
  Font.Style = []
  OldCreateOrder = False
  PixelsPerInch = 96
  TextHeight = 13
  object cxGroupBox1: TcxGroupBox
    Left = 20
    Top = 12
    Caption = #1041#1044
    TabOrder = 0
    Transparent = True
    Height = 121
    Width = 313
    object lblLogin: TcxLabel
      Left = 14
      Top = 17
      Caption = #1051#1086#1075#1110#1085
      FocusControl = edLoginA
    end
    object edLoginA: TcxTextEdit
      Left = 60
      Top = 16
      Properties.CharCase = ecUpperCase
      TabOrder = 1
      Text = 'SYSDBA'
      Width = 241
    end
    object lblPassword: TcxLabel
      Left = 14
      Top = 40
      Caption = #1055#1072#1088#1086#1083#1100
      FocusControl = edPasswordA
    end
    object edPasswordA: TcxTextEdit
      Left = 60
      Top = 39
      Properties.EchoMode = eemPassword
      Properties.PasswordChar = '*'
      TabOrder = 3
      Text = 'masterkey'
      Width = 241
    end
    object lbServer: TcxLabel
      Left = 14
      Top = 63
      Caption = #1057#1077#1088#1074#1077#1088
      FocusControl = edServerNameA
    end
    object edServerNameA: TcxMRUEdit
      Left = 60
      Top = 62
      Properties.ShowEllipsis = False
      TabOrder = 5
      Text = 'localhost'
      Width = 241
    end
    object lbDataBase: TcxLabel
      Left = 14
      Top = 86
      Caption = #1041#1044
      FocusControl = edDBPathA
    end
    object edDBPathA: TcxMRUEdit
      Left = 60
      Top = 85
      Properties.ShowEllipsis = False
      TabOrder = 7
      Text = 'c:\db.fdb'
      Width = 241
    end
  end
  object Button1: TButton
    Left = 258
    Top = 143
    Width = 75
    Height = 25
    Caption = 'TEST'
    TabOrder = 1
    OnClick = Button1Click
  end
  object Button2: TButton
    Left = 20
    Top = 143
    Width = 75
    Height = 25
    Caption = 'Start'
    TabOrder = 2
    OnClick = Button2Click
  end
  object Timer1: TTimer
    Enabled = False
    Interval = 30000
    OnTimer = Timer1Timer
    Left = 18
    Top = 20
  end
  object DBArch: TpFIBDatabase
    DefaultTransaction = pFIBTransaction1
    SQLDialect = 3
    Timeout = 0
    WaitForRestoreConnect = 0
    Left = 24
    Top = 136
  end
  object pFIBTransaction1: TpFIBTransaction
    DefaultDatabase = DBArch
    TimeoutAction = TARollback
    Left = 98
    Top = 138
  end
  object ds: TpFIBDataSet
    SelectSQL.Strings = (
      
        'select A.MON$USER, ST.MON$STATEMENT_ID, ST.MON$ATTACHMENT_ID, ST' +
        '.MON$TRANSACTION_ID, ST.MON$TIMESTAMP, ST.MON$SQL_TEXT,'
      
        '       R.MON$RECORD_SEQ_READS, R.MON$RECORD_IDX_READS, R.MON$REC' +
        'ORD_INSERTS, R.MON$RECORD_UPDATES, R.MON$RECORD_DELETES,'
      
        '       R.MON$RECORD_BACKOUTS, R.MON$RECORD_PURGES, R.MON$RECORD_' +
        'EXPUNGES, IO.MON$PAGE_READS, IO.MON$PAGE_WRITES,'
      '       IO.MON$PAGE_FETCHES, IO.MON$PAGE_MARKS'
      '  from MON$STATEMENTS ST'
      
        '  left join MON$RECORD_STATS R on (ST.MON$STAT_ID = R.MON$STAT_I' +
        'D)'
      '  left join MON$IO_STATS IO on (ST.MON$STAT_ID = IO.MON$STAT_ID)'
      
        '  left join MON$ATTACHMENTS A on A.MON$ATTACHMENT_ID = ST.MON$AT' +
        'TACHMENT_ID'
      '  where ST.MON$STATE = 1'
      '  order by ST.MON$TIMESTAMP  ')
    Transaction = pFIBTransaction1
    Database = DBArch
    Left = 178
    Top = 140
  end
  object SMTP: TIdSMTP
    Host = 'smtp.mail.ua'
    SASLMechanisms = <>
    Left = 220
    Top = 19
  end
  object IdMsgSend: TIdMessage
    AttachmentEncoding = 'UUE'
    BccList = <>
    CharSet = 'windows-1251'
    CCList = <>
    ContentType = 'text/plain'
    Encoding = meDefault
    FromList = <
      item
      end>
    Recipients = <>
    ReplyTo = <>
    ConvertPreamble = True
    Left = 248
    Top = 32
  end
end



Значит нашел, что во время роста БД всюду один запрос с большим количеством Page Read/Write/fetch/mark.
Там вызывалась процедура в которой выходной параметр был "SOME_PAR blob sub_type 1 segment size 80"
В теле процедуры в него пихалось около 100-200 символов на suspend. Но в одном суспенде туда пихалось 170550 символов.
+

for select...
begin
  SOME_PAR = '';
  for select...
  begin
    SOME_PAR = SOME_PAR || 'some data1';
    SOME_PAR = SOME_PAR || 'some data1';
    SOME_PAR = SOME_PAR || 'some data1';
    ...
    и так 15 раз...
  end
  suspend;
end


При этом база почему-то росла на 1.5Гб.
Т.к. процедура в одной транзакции вызывалась неоднократно, то база росла большими порциями.
Если транзакцию завершить и выполнить процедуру опять, то база не растет, видимо заполняется уже существующее мусорное пространство.

Конкретно в моем случае есть возможность эту процедуру переписать по другому.
Так что всем спасибо, для меня проблема решена. :)
15 окт 13, 13:09    [14972442]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
DarkMaster
Member

Откуда: Donetsk,Ukraine
Сообщений: 6370
Drag,

А что мешает размер тоже из базы тянуть? У тебя в MON$DATABASE есть MON$PAGES и MON$PAGE_SIZE. Я к тому, что твой FindFirst() не отработает при использовании альясов как минимум. Да и если версия Дельфей старая, то для больших файлов в SearchReс.Size есть возможность получить бред.
15 окт 13, 13:43    [14972787]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
PEAKTOP
Member

Откуда: агломерация Славянск-Краматорск-Дружковка
Сообщений: 1383
Drag
Если кому пригодится, то вот код
PAS


Здесь Delphi никто не знает... (с) =)
15 окт 13, 13:58    [14972925]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

Откуда:
Сообщений: 77
DarkMaster,

Про пейджесы как-то не думал. Спасибо за подсказку.
А у FIB компонента есть хак "DB.DBFileName" который дает полный путь к базе даже если "DB.DBName" - алиас.

А про размер файла... А вы и имена файлам даете исключительно на английском и не более 8ми символов? :)
Те давние времена уже прошли.
15 окт 13, 14:15    [14973069]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
DarkMaster
Member

Откуда: Donetsk,Ukraine
Сообщений: 6370
Drag,

Причем тут имена файлов? Я вот возьму твой любезно предоставленный исходник и скормлю его 6-й дельфе. У которой Size в TSearchRec - integer. Угадай, что будет у меня в Size, если я натравлю твой утиль на БД с размером в 10-20-100 Гб...
15 окт 13, 14:26    [14973182]     Ответить | Цитировать Сообщить модератору
 Re: Быстрый рост объема базы Interbase/Firebird  [new]
Drag
Member

Откуда:
Сообщений: 77
DarkMaster
Drag,

Причем тут имена файлов? Я вот возьму твой любезно предоставленный исходник и скормлю его 6-й дельфе. У которой Size в TSearchRec - integer. Угадай, что будет у меня в Size, если я натравлю твой утиль на БД с размером в 10-20-100 Гб...


Да пожалуйста, можно еще в 3ю делфи попробовать, а вдруг откомпилится ;)

На самом деле смысл был в том, что не нужно коннектится к БД до тех пор пока не нужно получить выборки.
Можно использовать и GetFileSizeEx конечно, но в принципе не отрицаю, что ваш способ тоже вариант.
15 окт 13, 15:30    [14973749]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3 4 5 6 7 8 9 10      [все]
Все форумы / Firebird, InterBase Ответить