OlegA67,
По ауторизации.
На виндах не то после развлечений с группами, не то после каких-то изменений environment'а (env variables, regional settings аккаунта, из-под которого DB2 бежит - влияло на поведение некоторых наших UDF) оказалось полезным машину перегрузить.
Но вообще, выглядит так, как буд-то учётка, под которой DB2 бежит, действительно просто к домену обратиться не может.
По переносу. Писал уже, мы в такой ситуации посчитали правильным
пересоздать базу .
Готовились с пол-года, сначала обкатав это дело на сильно редуцированных региональных базах, оттестировав тем самым чать приложений. Потом перевели на 9.7 девелоперские и тестовые среды, приложений охватили уже больше. Были какие-то проблемы, но по мелочам (поменялась интеграция с MQ, что-то из UDF пересобрать на 64bit понадобилось).
Когда перенос основной базы планировали, смотрели, когда меньше всего загрузка по изменениям, дабы обеспечить минимальный downtime (меньше донакатывать).
Изменённые с заданного момента таблицы переносили полностью export/load. Load пускали как NONRECOVERABLE с CHECK PENDING CASCADE IMMEDIATE, потом по SELECT tabschema, tabname from SYSCAT.TABLES WHERE status = 'C' пускали в несколько проходов "set integrity for ... immediate checked", пока не останется таблиц в check pending (теоретически есть ситуации, когда это работать не будет (в случае циклических зависимостей)).
В принципе, на заданный набор таблиц (список получили на этапах подготовки), обновляемых в определённое время (утро воскресенья), можно было настроить репликации (таблиц таких получалось не более 40), но посчитали, что их перенос в разумное время вписывается.
Полностью процедура выглядела так:
1. Фриз на изменение структуры объектов (контролировали по идентичности ежедневных снимков db2look).
2. Подготовка структуры новой базы.
3. Запуск следилки изменения данных (пара процедур - смотрим rows_written со снапшотов по таблицам и сравниваем с сохранённым в момент старта).
4. Старт очередного online backup-а.
5. Восстановление полученного бэкапа на отдельном сервере, експорт всех таблиц базы.
6. Импорт всех таблиц базы в подготовленную 9.7. (на самом деле импорт также включён в процедуру подготовки структуры перед созданием индексов, сбором статистики и созданием процедур, т.е. все планы готовятся сразу по актуальной статистике).
7. В несколько итераций перетаскиваем изменяемые таблицы уже из рабочей базы вновую (каждый раз уменьшая размер дельты) вплоть до часа X.
8. В час X закрываем доступ к "старой" базе (для страховки переименовываем), переносим "остатки".
9. Запускаем ту же следилку за изменениями на новой базе (
!!! ), обеспечивая возможность обратного переезда.
10. Открываем доступ к новой базе на 9.7.
По факту переезд прошёл очень гладко. Хотя весь зоопарк приложений всё-таки не оттестировали, и был ряд проблем, чуть не заставивших возвращаться обратно (коннективити из СOM+ или DCOM объектов, связанное, скорее, со сменой виндов, и магическим образом решившееся перерегистрацией объектов через какие-то из контейнеров в component services).
Вся процедура после предварительных репетиций заняла неделю (для базы с выходом из-под db2look в 12Mb). Наибольшие сложности определялись глюками db2look (типа микширования параметров процедур с одинаковыми именами из разных схем при генерации GRANT'ов).
Не думаю, что всегда правильно городить такой огород, но в нашем случае было, пожалуй, оправдано.
