Начало » Использование СУБД » Firebird, HQbird, InterBase » FB 3.0.7 повреждение БД
| FB 3.0.7 повреждение БД [сообщение #3326] |
Tue, 10 October 2023 18:01  |
IP
Сообщений: 25
Зарегистрирован: January 2023
|
Junior Member |
|
|
Приветствую, коллеги!
Разбирал тут неприятный инцидент с повреждением БД.
Один из наших программистов ковырял метаданные, в частности создал табличку SKLAD_MAG_PAL_MEST,
потом происходит "нечто", в логах сервера нашел один сегфолт относящийся к файрберду примерно на указанный день,
чистоту в "железных" логах на предмет рэйда или ЕСС памяти.
В результате получили несогласованность в базе, есть запись в rdb$relations, но нет в RDB$RELATION_FIELDS
запрос
select RDB$RELATION_NAME from rdb$relations where RDB$RELATION_NAME = 'SKLAD_MAG_PAL_MEST'
отдает пустоту
запрос
select RDB$RELATION_NAME from rdb$relations where RDB$RELATION_NAME || '' = 'SKLAD_MAG_PAL_MEST' || ''
отдает 1 запись
Из видимых повреждений явно битый индекс как минимум на одной из системных табличек.
GBAK добросовестно создает gbk, а вот рестор уже обламывается.
Причем судя по вербозе создания gbk оно еще двадцать с лишим тысяч записей загоняет по этой табличке, т.е. gbak данных в проблемной табличке каким-то хитрым способом таки наковырял.
хотя "select * from SKLAD_MAG_PAL_MEST" шлет лесом.
gfix меня ни чем не порадовал и не уведомил. не умею пользоваться? может есть "хитрый" набор ключей?
Собственно пролечил сие безобразие велев gbak-у пропустить проблемную табличку "-SKIP_D SKLAD_MAG_PAL_MEST", потом врукопашную выкинул из gbk два упоминания таблички в секции метаданных, после чего оно разресторилось и проблема ушла.
Вопрос: Как избежать? скорее риторический. Да, я знаю, ковырять метаданные под нагрузкой в три сотни коннектов так себе занятие.
А вот вопрос:
Есть ли менее зубодробильный метод лечения, кроме как руками ковырять файл gbk в 185 гиг?
волне себе интересен.
Оригинальный gdb есть, но он гад 372 гиг и содержит кучу коммерческой инфы, разбором полетов я занялся когда прошло уже несколько дней после инцидента, никаких следов процессов файрберда не осталось.
Участники "врут как очевидцы", как мне кажется запустили апдейт метаданных в nowait транзакции, оно "зависло", взяли и грохнули процесс классика и тут "Остапа понесло".
Если есть версии как оно еще могло так покорежиться, было бы тоже интересно.
Могу ли я чем-то помочь разработчикам?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: FB 3.0.7 повреждение БД [сообщение #3348 является ответом на сообщение #3333] |
Wed, 11 October 2023 18:51  |
IP
Сообщений: 25
Зарегистрирован: January 2023
|
Junior Member |
|
|
>ALTER INDEX <name> ACTIVE
У меня засело, что в тройке все доступы к системным таблицам подрезаны на корню, в принципе можно попробовать на копии.
Я попробую поиграться с активацией индексов, о результатах отпишусь.
>Процессор или диск загружен ? Сколько ждали ?
>Коммит метаданных может занять существенное время.
Оно просто завершает работу. Если база в неповрежденном состоянии пролетает это место без запинки.
>Если осталась "поломанная" БД, то можно для проверки сделать бекап только метаданных (-b -m) и попробовать его отресторить.
База осталась. С бэкапа только метаданных я и начинал(-b -g -m -v), пока методом "научного тыка" не отрезал "ненужные" упоминания о таблице рестор не шел.
Наличие данных в gbk файле не меняло точку останова рестора.
Судя по вербозе и ковырянии редактором в самом файле бэкапа в бэкап попало упоминание о таблице, но не попало упоминания ни об одном поле таблицы, "заголовок есть - полей нет".
Не должен бы gbak на этапе бэкапа ругнуться хотя бы варнингом на подобное безобразие?
СтОит идти с подобным фичреквестом в треккер?
Сильно помог бы ключик типа SKIP_META аналог SKIP_D, только чтоб он еще и создание указанных таблиц пропускал, а не только заполнение данными.
|
|
|
|
| Re: FB 3.0.7 повреждение БД [сообщение #3383 является ответом на сообщение #3333] |
Thu, 12 October 2023 19:08 |
IP
Сообщений: 25
Зарегистрирован: January 2023
|
Junior Member |
|
|
hvlad писал(а) Tue, 10 October 2023 19:19IPНа rdb$relations ? Индекс починили ?
"отрезанием головы" т.е. циклом Б/Р.
Есть какой-то путь починить системный индекс по-другому? ALTER INDEX <name> ACTIVE
Видимо неспроста у меня осталось в голове, что системные таблички подрезаны для ковыряния.
Облом:
типичная системная табличка
CREATE TABLE RDB$RELATIONS (
RDB$VIEW_BLR BLOB SUB_TYPE 2 SEGMENT SIZE 80,
RDB$VIEW_SOURCE BLOB SUB_TYPE 1 SEGMENT SIZE 80 CHARACTER SET UNICODE_FSS,
RDB$DESCRIPTION BLOB SUB_TYPE 1 SEGMENT SIZE 80 CHARACTER SET UNICODE_FSS,
RDB$RELATION_ID SMALLINT,
RDB$SYSTEM_FLAG SMALLINT,
RDB$DBKEY_LENGTH SMALLINT,
RDB$FORMAT SMALLINT,
RDB$FIELD_ID SMALLINT,
RDB$RELATION_NAME CHAR(31) CHARACTER SET UNICODE_FSS,
RDB$SECURITY_CLASS CHAR(31) CHARACTER SET UNICODE_FSS,
RDB$EXTERNAL_FILE VARCHAR(255) CHARACTER SET NONE,
RDB$RUNTIME BLOB SUB_TYPE 5 SEGMENT SIZE 80,
RDB$EXTERNAL_DESCRIPTION BLOB SUB_TYPE 8 SEGMENT SIZE 80,
RDB$OWNER_NAME CHAR(31) CHARACTER SET UNICODE_FSS,
RDB$DEFAULT_CLASS CHAR(31) CHARACTER SET UNICODE_FSS,
RDB$FLAGS SMALLINT,
RDB$RELATION_TYPE SMALLINT
);
/*********************************************************** *******************/
/*** Unique constraints ***/
/*********************************************************** *******************/
ALTER TABLE RDB$RELATIONS ADD CONSTRAINT RDB$INDEX_0 UNIQUE (RDB$RELATION_NAME);
/*********************************************************** *******************/
/*** Indices ***/
/*********************************************************** *******************/
CREATE INDEX RDB$INDEX_1 ON RDB$RELATIONS (RDB$RELATION_ID);
даю команду под SYSDBA
alter index rdb$index_0 active
или
alter index rdb$index_0 inactive
получаю ответ
This operation is not defined for system tables.
unsuccessful metadata update.
ALTER INDEX RDB$INDEX_0 failed.
no permission for ALTER access to TABLE RDB$RELATIONS.
------------------------------------------------------
SQLCODE: -607
SQLSTATE: 28000
GDSCODE: 335544351
|
|
|
|
|
|
|
|
| Re: FB 3.0.7 повреждение БД [сообщение #3387 является ответом на сообщение #3386] |
Fri, 13 October 2023 11:42 |
hvlad
Сообщений: 364
Зарегистрирован: August 2022
|
Senior Member |
|
|
IP писал(а) Fri, 13 October 2023 11:29Ладно, хрен с ней, с судьбой.
Влад, как думаешь удастся выжать из ситуации что-то полезное?
Вот есть база после контузии, явно есть повреждения.
В транспортный формат загоняется без ошибок, рестор гарантированно обламывается.
Не должен бы gbak на этапе -b как-то ругнуться?
Не должен бы gfix как-то отдетектить проблему и сказать "индекс такой-то кирдык" или еще что-то там кирдык?
готов потестировать или тикет оформить, если есть смысл.
gbak не может и не должен делать какие-то продвинутые проверки, это работа gfix.
Если там действительно битый системный индекс, то gfix должен был сказать об этом.
Как ты запускал gfix ?
Я понимаю, что проверить БД под 400ГБ не очень весёлое занятие, но проверить отдельно только системную таблицу
не получится. Онлайн валидация умеет отдельные таблицы, но не системные.
|
|
|
|
|
|
| Re: FB 3.0.7 повреждение БД [сообщение #3392 является ответом на сообщение #3391] |
Fri, 13 October 2023 13:12 |
hvlad
Сообщений: 364
Зарегистрирован: August 2022
|
Senior Member |
|
|
IPНа днях погоняю gfix в неторопливой обстановке, о результатах отпишусь. Допускаю, мог быть косяк в моих прошлых изысканиях. 
На всякий - gfix -v -full
IP>gbak не может и не должен делать какие-то продвинутые проверки, это работа gfix.
gbak -b пишет данные о заголовке таблицы, потом он обязан записать данные как минимум об одной колонке таблицы, если ни одной колонки не обнаружилось, то чем не повод что-то написать в stderr?
А ты уверен, что там именно таблица без полей ?
Я не вижу в твоих запросах поиск полей.
Ну а список таблиц gbak читает натуралом, насколько я помню, так что битый индекс ему в этом не помеха.
|
|
|
|
| Re: FB 3.0.7 повреждение БД [сообщение #3421 является ответом на сообщение #3386] |
Mon, 16 October 2023 15:40 |
kdv
Сообщений: 98
Зарегистрирован: June 2022
|
Member |
|
|
IP писал(а) Fri, 13 October 2023 11:29
Не должен бы gbak на этапе -b как-то ругнуться?
Не должен бы gfix как-то отдетектить проблему и сказать "индекс такой-то кирдык" или еще что-то там кирдык?
готов потестировать или тикет оформить, если есть смысл.
гбак только читает данные, он ничего не проверяет. Раз данные читаются, значит всё ок. Не читаются - сообщает о проблеме.
gfix пишет подробности в firebird.log. см. туда.
p.s. "молния" может ударить в любую часть базы. Поэтому повредиться может что угодно - сист. таблицы, данные, индексы, и т.д.
Поэтому надо регулярно делать бэкапы, и nbackup тоже, а еще лучше - онлайн асинхронная репликация.
Чинить базы такого размера смысла мало - дорого и долго.
|
|
|
|
|
|
|
|
| Re: FB 3.0.7 повреждение БД [сообщение #3425 является ответом на сообщение #3421] |
Tue, 17 October 2023 16:15 |
IP
Сообщений: 25
Зарегистрирован: January 2023
|
Junior Member |
|
|
kdv писал(а) Mon, 16 October 2023 15:40IP писал(а) Fri, 13 October 2023 11:29
Не должен бы gbak на этапе -b как-то ругнуться?
Не должен бы gfix как-то отдетектить проблему и сказать "индекс такой-то кирдык" или еще что-то там кирдык?
готов потестировать или тикет оформить, если есть смысл.
гбак только читает данные, он ничего не проверяет. Раз данные читаются, значит всё ок. Не читаются - сообщает о проблеме.
gfix пишет подробности в firebird.log. см. туда.
гбак читает заголовок таблицы, ОК. пишет об этом в вербоза файл. Дальше обязан идти список полей, а его нет. Ну хоть бы варнинг какой...
Логи еще раз прогоню и проверю.
kdv писал(а) Mon, 16 October 2023 15:40p.s. "молния" может ударить в любую часть базы. Поэтому повредиться может что угодно - сист. таблицы, данные, индексы, и т.д.
Поэтому надо регулярно делать бэкапы, и nbackup тоже, а еще лучше - онлайн асинхронная репликация.
Чинить базы такого размера смысла мало - дорого и долго.
Никто и не говорит, что молнию надо отменить указом верховного генералиссимуса.
Да, был настроен револьверный бэкап через скрипты gbak + ротация.
Да, был лог репликатора и его можно было накатить.
Но к тому моменту как я вышел из отпуска ситуация уже была запущена, логи просто так не накатывались, т.к. насочиняли еще метаданных, и накат занимал дохрена времени.
Да первое, что сделал, это заскриптовал nbakup и запихнул в крон. Да только база после нбэкапа ровно та же постраничная копия исходной поврежденной, а нбэкапной копии "до того" не было.
Пока еще "чешем репу" на предмет регламента в подобном случае. в принципе есть пара железяк, на которые гоним реплики,
но они для формирования длинных отчетов и всякой аналитической фигни, базы там немного отличаются, и как выяснилось, просто так их местами не поменять.
В угоду скорости часть данных не нужных для аналитики не попадает в репликацию.
Пока мысли в сторону: выровнять базы, до состояния пригодного для переключения, подрихтовать блок подключения у клиента, чтоб он не "сошел с ума", от потери "главного сервера", а аккуратно подключился к резервной ноде и т.д. и т.п.
Надо изначально делать фаиловер, но как всегда, срочно всякие кнопочки-отчеты-сверки, а серьезных отказов несколько лет на было, вот и расслабились.
Пока пролечили базу, выписали парочку более скоростных u2 ssd-шек, подрезали от ставших ненужными данных, чтоб время на регламент требовалось меньше. Поставили в план "думы о кластере".
|
|
|
|
|
|
|
|
| Re: FB 3.0.7 повреждение БД [сообщение #3428 является ответом на сообщение #3427] |
Wed, 18 October 2023 13:19 |
IP
Сообщений: 25
Зарегистрирован: January 2023
|
Junior Member |
|
|
SD писал(а) Wed, 18 October 2023 01:19Хммм... "Мы не можем ждать сутки пока пройдёт нормальное восстановление, поэтому неделю будем маяться проктостоматологией." Греф одобряет. Нормальное восстановление уже не шло задуманным путем, слишком поздно кинулись. Над тем чтобы "кинуться вовремя" сейчас и думаем.
Вариантов было несколько:
1. Брать валидный бэкап и на него накатить лог репликатора, оказалось, что в логе не все и лог уже гигантского размера, да еще и не накатывается штатно. Как всегда, к моменту тушения пожара штатный огнетушитель оказался неработоспособен, выше Диме я это расписал.
2. Взять валидную базу болванку и на нее накатить данные тем же экспертом/скриптом/переливкой через клиента. ОЧЕНЬ долго, точно не сутки, после суток молотильни база хорошо, если на четверть сформировалась. Да, экспертовкая переливалка тупо сыпалась с "аут оф мемери" и кирдык минут через 15 после начала работы.
3. Лечить то, что есть.
По факту уже сходили путем номер 3, он оказался быстрее чем 2. А мысли о том, чтобы работал номер 1. Для этого надо и программные средства и организационные. Надо как-то пораньше диагностировать проблему, надо уметь штатно переключиться на резерв и не про%#%ть последние актуальные данные.
Вот ради диагностики и пристаю к Владу.
А если бы еще чем-то штатным пролечить... но это уж совсем мечты. 
|
|
|
|
|
|
| Re: FB 3.0.7 повреждение БД [сообщение #3474 является ответом на сообщение #3429] |
Sun, 22 October 2023 13:20 |
IP
Сообщений: 25
Зарегистрирован: January 2023
|
Junior Member |
|
|
Старый Плюшев писал(а) Wed, 18 October 2023 16:35IP писал(а) Wed, 18 October 2023 13:19
2. Взять валидную базу болванку и на нее накатить данные тем же экспертом/скриптом/переливкой через клиента. ОЧЕНЬ долго, точно не сутки, после суток молотильни база хорошо, если на четверть сформировалась.
Индексы на приёмнике отключали? Если лить с неактивными, а потом активизировать, получается гораздо быстрее.
Нет. Если бы приперло, то да, попробовали бы и так и эдак. Вообще основной мыслью было набросать свой заливальщик в дюжину-другую тредов, чтоб лили в параллель. Пока забросил это дело.
|
|
|
|
| Re: FB 3.0.7 повреждение БД [сообщение #3475 является ответом на сообщение #3392] |
Sun, 22 October 2023 13:36 |
IP
Сообщений: 25
Зарегистрирован: January 2023
|
Junior Member |
|
|
hvlad писал(а) Fri, 13 October 2023 13:12IPНа днях погоняю gfix в неторопливой обстановке, о результатах отпишусь. Допускаю, мог быть косяк в моих прошлых изысканиях.
На всякий - gfix -v -full
IP>gbak не может и не должен делать какие-то продвинутые проверки, это работа gfix.
gbak -b пишет данные о заголовке таблицы, потом он обязан записать данные как минимум об одной колонке таблицы, если ни одной колонки не обнаружилось, то чем не повод что-то написать в stderr?
А ты уверен, что там именно таблица без полей ?
Я не вижу в твоих запросах поиск полей.
Ну а список таблиц gbak читает натуралом, насколько я помню, так что битый индекс ему в этом не помеха.
Таки да, правда Ваша, с -full рапортует об ошибках
/opt/firebird/bin/gfix /ibdata/Orskl.gdb -v -full
Summary of validation errors
Number of index page errors : 2
Number of pointer page warnings : 1
в логе дословно следующее:
Rodion<>Sun Oct 22 09:44:53 2023
<------>Database: /ibdata/Orskl.gdb
<------>Validation started
Rodion<>Sun Oct 22 09:45:00 2023
<------>Database: /ibdata/Orskl.gdb
<------>Warning: Pointer page 16 {sequence 0} bits {0x04 swept} are not consistent with data page 651 {sequence 19} state {0x00 } in table RDB$RELATIONS (6)
Rodion<>Sun Oct 22 09:45:00 2023
<------>Database: /ibdata/Orskl.gdb
<------>Error: Index 1 is corrupt {missing entries for record 18357} in table RDB$RELATIONS (6)
Rodion<>Sun Oct 22 09:45:00 2023
<------>Database: /ibdata/Orskl.gdb
<------>Error: Index 2 is corrupt {missing entries for record 18357} in table RDB$RELATIONS (6)
Rodion<>Sun Oct 22 10:10:10 2023
<------>Database: /ibdata/Orskl.gdb
<------>Validation finished: 2 errors, 1 warnings, 1 fixed
Потом пробовал применить -mend
[root@Rodion bin]# /opt/firebird/bin/gfix /ibdata/Orskl.gdb -mend
Summary of validation errors
Number of index page errors : 2
его часть лога:
Rodion<>Sun Oct 22 10:47:37 2023
<------>Database: /ibdata/Orskl.gdb
<------>Validation started
Rodion<>Sun Oct 22 10:47:39 2023
<------>Database: /ibdata/Orskl.gdb
<------>Error: Index 1 is corrupt {missing entries for record 18357} in table RDB$RELATIONS (6)
Rodion<>Sun Oct 22 10:47:39 2023
<------>Database: /ibdata/Orskl.gdb
<------>Error: Index 2 is corrupt {missing entries for record 18357} in table RDB$RELATIONS (6)
Rodion<>Sun Oct 22 11:06:25 2023
<------>Database: /ibdata/Orskl.gdb
<------>Validation finished: 2 errors, 0 warnings, 0 fixed
Вот только гбак от этого лучше работать ни разу не стал, вербоза ниже, поскипал неинтересное, делал только -m метаданные:
gbak:readied database /ibdata/Orskl.gdb for backup
gbak:creating file /ibdata/Orskl-10.gbk
gbak:starting transaction
gbak:database /ibdata/Orskl.gdb has a page size of 16384 bytes.
gbak:writing domains
--skip--
gbak: writing table SPAG_CENNIK
gbak: writing column MAG_ID
gbak: writing column SPAG
gbak: writing column TIMEP
gbak: writing column KODM
gbak: writing column LOGIN
gbak: writing table SKLAD_MAG_PAL_MEST
gbak: writing table OBRT_SPAG_HOZ
gbak: writing column SPAG
gbak: writing column TIMEP
gbak: writing column PR_NDS
gbak: writing column LOGIN
--skip--
gbak:writing referential constraints
gbak:writing check constraints
gbak:writing SQL roles
gbak:writing names mapping
gbak:closing file, committing, and finishing. 54753280 bytes written
В конце бодренькая концовка.
В самом gbk суть тоже, только менее читаемое. Таблица есть, полей нет.
gfix говорит только про побитый индекс, про контуженную табличку ни полслова.
|
|
|
|
| Re: FB 3.0.7 повреждение БД [сообщение #3476 является ответом на сообщение #3475] |
Sun, 22 October 2023 14:29 |
hvlad
Сообщений: 364
Зарегистрирован: August 2022
|
Senior Member |
|
|
IPТаки да, правда Ваша, с -full рапортует об ошибках
Показать скрытый текст
/opt/firebird/bin/gfix /ibdata/Orskl.gdb -v -full
Summary of validation errors
Number of index page errors : 2
Number of pointer page warnings : 1
в логе дословно следующее:
Rodion<>Sun Oct 22 09:44:53 2023
<------>Database: /ibdata/Orskl.gdb
<------>Validation started
Rodion<>Sun Oct 22 09:45:00 2023
<------>Database: /ibdata/Orskl.gdb
<------>Warning: Pointer page 16 {sequence 0} bits {0x04 swept} are not consistent with data page 651 {sequence 19} state {0x00 } in table RDB$RELATIONS (6)
Rodion<>Sun Oct 22 09:45:00 2023
<------>Database: /ibdata/Orskl.gdb
<------>Error: Index 1 is corrupt {missing entries for record 18357} in table RDB$RELATIONS (6)
Rodion<>Sun Oct 22 09:45:00 2023
<------>Database: /ibdata/Orskl.gdb
<------>Error: Index 2 is corrupt {missing entries for record 18357} in table RDB$RELATIONS (6)
Rodion<>Sun Oct 22 10:10:10 2023
<------>Database: /ibdata/Orskl.gdb
<------>Validation finished: 2 errors, 1 warnings, 1 fixed
Потом пробовал применить -mend
[root@Rodion bin]# /opt/firebird/bin/gfix /ibdata/Orskl.gdb -mend
Summary of validation errors
Number of index page errors : 2
его часть лога:
Rodion<>Sun Oct 22 10:47:37 2023
<------>Database: /ibdata/Orskl.gdb
<------>Validation started
Rodion<>Sun Oct 22 10:47:39 2023
<------>Database: /ibdata/Orskl.gdb
<------>Error: Index 1 is corrupt {missing entries for record 18357} in table RDB$RELATIONS (6)
Rodion<>Sun Oct 22 10:47:39 2023
<------>Database: /ibdata/Orskl.gdb
<------>Error: Index 2 is corrupt {missing entries for record 18357} in table RDB$RELATIONS (6)
Rodion<>Sun Oct 22 11:06:25 2023
<------>Database: /ibdata/Orskl.gdb
<------>Validation finished: 2 errors, 0 warnings, 0 fixed
Вот только гбак от этого лучше работать ни разу не стал
...
gfix говорит только про побитый индекс, про контуженную табличку ни полслова.
Итого - битые индексы на RDB$RELATIONS, т.е. при чтении этой таблицы с использованием битого индекса некоторые
записи будут пропущены.
Это объясняет "таблицу без полей" и без данных - запись о самой таблице есть т.к. RDB$RELATIONS читалась натуралом,
а вот более сложные запросы её уже не видят.
Далее, missing entries gfix не чинит, и честно об этом сообщает (0 fixed), поэтому ожидать от него чудес не стоило.
Почему это произошло: не могу сказать с уверенностью, возможно кто-то пытался таблицу дропнуть и обломался - откат DDL
внутри у движка не на 100% надёжен, там могут быть проблемы. Если кто-то воспроизведёт - сможем починить.
Что можно сделать с нашей стороны: придумать лазейку для безопасной перестройки индексов системных таблиц,
научить gfix (валидацию) восстанавливать missing entries, добавить в gbak проверку наличия полей в таблице.
PS 3.0.7 давно пора обновить
|
|
|
|
| Re: FB 3.0.7 повреждение БД [сообщение #3478 является ответом на сообщение #3476] |
Mon, 23 October 2023 11:08 |
IP
Сообщений: 25
Зарегистрирован: January 2023
|
Junior Member |
|
|
hvlad писал(а) Sun, 22 October 2023 14:29Почему это произошло: не могу сказать с уверенностью, возможно кто-то пытался таблицу дропнуть и обломался - откат DDL
внутри у движка не на 100% надёжен, там могут быть проблемы. Если кто-то воспроизведёт - сможем починить.
Что можно сделать с нашей стороны: придумать лазейку для безопасной перестройки индексов системных таблиц,
научить gfix (валидацию) восстанавливать missing entries, добавить в gbak проверку наличия полей в таблице.
PS 3.0.7 давно пора обновить
Я тоже склоняюсь к тому, что пытались дропнуть ПК или ФК. Разные коннекты закешировали метаданые на разных этапах, потом автор попытался откатить часть своего творения и привет. Как гарантированно воспроизвести пока не знаю.
Может в каком-нибудь определенном режиме шатдауна разрешить слегка "потрогать за интересные места" системные таблички? Как вариант...
Уже есть оказавшийся полезным ключик -SKIP_D для gbak, может его аналог, выше я рассуждал про это.
Про обновление знаю, но в районе 3.0.9-3.0.10 и 4.0.0 напоролся на регресс, на одном из запросов оптимизатор стал "сходить с ума", как назло им "пропитан весь клиент", конструируемый динамически запрос поиска товарной позиции по куче параметров.
Надо протестировать 3.0.11 и 4.0.2 и либо перейти, либо писать тесткейз трекеру.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Переход к форуму:
Текущее время: Wed Dec 18 20:08:17 GMT+3 2024
Общее время, затраченное на создание страницы: 0.01946 секунд
|
SQLRU.net
Поиск
Помощь
Участники
Регистрация
Вход
Начало
