Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Восстановление БД из резервной копии приводит к проблемам с процедурами (IB XE7)
|
|||
|---|---|---|---|
|
#18+
Имеется БД, изначально созданная в IB XE3 Update 4, которая прекрасно неоднократно восстанавливалась из копий без каких-либо неожиданностей. После перехода на IB XE7 Update 1 перестали проходить некоторые тесты хранимых процедур, которые до этого, разумеется, не падали. Вся соль в том, что это происходит только на базе, восстановленной из резервной копии, другими словами есть два сценария: 1 - с падением тестов. Берётся БД с XE3-сервера, с помощью XE7 создаётся её копия. База тут же восстанавливается из только что созданной копии. Запускаются тесты - некоторые не проходят. 2 - без падения тестов. Берётся БД с XE3-сервера, в IBExpert создаётся SQL-скрипт на получение её полного дубликата (благо данных в ней мало). Скрипт отрабатывает на сервере XE7 - получаем новую БД. Запускаются тесты - все проходят. Выполняем создание резервной копии этой новой базы и тут же восстанавливаем из неё. Запускаются тесты - некоторые не проходят (ровно те же, что и в первом сценарии). Попытки перекомпиляции всех процедур (с отключением пользователей, чтобы кеш метаданных стал актуальным) и обновления индексов ничего не дают. Хотя, один раз удалось каким-то образом восстановить работу тестов, но последовательность действий забылась, т. к. перебиралось всё, что приходило в голову (например, никак не влияющие на логику процедуры правки - добавление лишнего пробела в комментарии, удаление тела и возврат кода обратно...). Буду рад любым советам по поиску причины такого поведения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2015, 00:13 |
|
||
|
Восстановление БД из резервной копии приводит к проблемам с процедурами (IB XE7)
|
|||
|---|---|---|---|
|
#18+
Калям, я думаю что скрипт сюда вряд ли будет уместным. можете к нам в саппорт, или прямо мне на email - что за тесты, что значит "не проходят". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2015, 02:57 |
|
||
|
Восстановление БД из резервной копии приводит к проблемам с процедурами (IB XE7)
|
|||
|---|---|---|---|
|
#18+
Выяснилось, что описанная проблема возникает только на последней версии ODS - 16; если в ibconfig уменьшить её до 15 (это версия сервера XE3), то всё работает как надо. Всё больше склоняюсь в сторону ошибки в самом Interbase, либо в gbak. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2015, 21:11 |
|
||
|
Восстановление БД из резервной копии приводит к проблемам с процедурами (IB XE7)
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2015, 21:22 |
|
||
|
Восстановление БД из резервной копии приводит к проблемам с процедурами (IB XE7)
|
|||
|---|---|---|---|
|
#18+
Удалось обнаружить причину ошибки - в блоке for в выборке использовалась та же таблица (TABLE_1), что и в блоке do, где она обновлялась: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Чтобы избежать побочных эффектов такого использования for-блока, приводивших к проблеме, я предварительно сохранил данные в буферную временную таблицу TMP_TABLE: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. В результате такой код корректно работает на обеих версиях ODS (15 и 16). Теперь у меня возникли сомнения, а является ли первоначальная проблема ошибкой IB - ведь если недопустимо применять одну и ту же таблицу в for, где её данные меняются (хотя в документации и на ibase.ru я подобных ограничений не нашёл), то вина только моя. Есть ещё момент. Удивительно, но именно в документации Firebird почему-то нашлась недокументированная возможность IB, которая в моём случае теоретически может помочь обойтись без временной таблицы - http://www.firebirdsql.org/refdocs/langrefupd21-psql-forselect.html#langrefupd21-psql-forselect-ascursor (раздел "AS CURSOR clause"). Но мне не удалось скомпилировать код примера, адаптированный к моему случаю, ошибка такая: Код: plaintext 1. 2. 3. Есть люди, которым что-то известно об этой возможности? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2015, 16:48 |
|
||
|
Восстановление БД из резервной копии приводит к проблемам с процедурами (IB XE7)
|
|||
|---|---|---|---|
|
#18+
Калям, есть несколько моментов 1. для того, чтобы получить корректные обновления в for этой же таблицы, нужно сделать курсор стабильным. А делается он только через plan sort. и есть другие варианты, которые описаны тут http://www.ibase.ru/devinfo/updsame.htm 2. функциональность as cursor, насколько я помню, в IB не была доделана и поэтому не документирована. В Langref Update по Firebird добавлено то, чего не было в InterBase 6.0. В документации по InterBase as cursor не фигурирует вообще, это значит что он не поддерживается. p.s. описанный вами баг (про ODS 16) так и не смог отрапортовать, не было времени, приношу извинения. Попытаюсь после майских. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2015, 16:57 |
|
||
|
Восстановление БД из резервной копии приводит к проблемам с процедурами (IB XE7)
|
|||
|---|---|---|---|
|
#18+
КалямТеперь у меня возникли сомнения, а является ли первоначальная проблема ошибкой IB - ведь если недопустимо применять одну и ту же таблицу в for, где её данные меняются (хотя в документации и на ibase.ru я подобных ограничений не нашёл), то вина только моя. Является. Вообще говоря любые модификации той же таблицы которая используется в курсоре является причиной так называемой ошибки нестабильного курсора. Когда данные изменённые в курсоре были видны в самом этом курсоре. Эта ошибка исправлена только в Firebird 3. Если в IB тупо запретили компилировать такие процедуры, то это весьма странное решение, точнее не решение, а просто уход от проблемы. КалямUnknown cursor. Dynamic SQL Error. SQL error code = -504. Cursor unknown. Приведи текст этой процедуры ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2015, 16:57 |
|
||
|
Восстановление БД из резервной копии приводит к проблемам с процедурами (IB XE7)
|
|||
|---|---|---|---|
|
#18+
Калямв документации Firebird почему-то нашлась недокументированная возможность IB, которая в моём случае теоретически может помочь обойтись без временной таблицы Не может. Если у тебя в SELECT план ORDER, а ты изменяешь поля так, что запись "перемещается" по индексу вперёд и таким способом встречается дважды, то тебе update по rdb$db_key (что и делается с помощью курсора) не поможет. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2015, 17:34 |
|
||
|
Восстановление БД из резервной копии приводит к проблемам с процедурами (IB XE7)
|
|||
|---|---|---|---|
|
#18+
Симонов ДенисПриведи текст этой процедуры Минимальный код для воспроизведения: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. Без соединения с T2 процедура скомпилируется. Но, как понятно из других ответов, мне это использовать смысла нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2015, 17:56 |
|
||
|
|

start [/forum/topic.php?fid=40&fpage=77&tid=1562871]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
60ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
| others: | 13ms |
| total: | 163ms |

| 0 / 0 |
