powered by simpleCommunicator - 2.0.52     © 2025 Programmizd 02
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
59 сообщений из 59, показаны все 3 страниц
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310719
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Добрый день,

Переключение в режим автоматического архивирования на другое хранилище или TSM (за пределы локального ZFS DataSet) не подходит, потому что пользуемся снэпшотами на хранилище в режиме DB2 write suspend.

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

Поэтому хотелось бы самостоятельно копировать архивные логи в другое хранилище.

Например, с помощью rsync или существуют другие способы?

Как отделить мух от котлет архивные логи от активных, лучше бы они были в разных каталогах.
Наверно надо поменять значение LOGARCHMETH1 на DISK типа LOG/ARCHIVE, но указать не другое хранилище, а всего лишь другой каталог того же самого DataSet ZFS, которое снэпшотится? Тогда при откате на снэпшот активные логи будут соответствовать архивным на том же датасете.

А при очередном запуске rsync из крона (или в цикле) логи из каталога LOG/ARCHIVE будут копироваться rsync-ом на другое хранилище (бэкап сервер), туда же, где лежат бэкапы.

А потом уже с бэкап сервера полные бэкапы, дельты и логи будут неспешно уходить на TSM в режиме "WINDOWS DOMAIN" если не ошибаюсь, т.е. обычным копированием файлов.

Так получится?
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310721
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
снэпшоты делаются так:

suspend_db()
{
Name=$1;

echo "===== Suspending database $Name";
db2 terminate;
db2 archive log for db $Name;
db2 connect to $Name;
db2 set write suspend for database;

}

resume_db()
{
Name=$1;

echo "===== Resuming database $Name";

db2 terminate;
db2 connect to $Name;
db2 set write resume for database;

}

suspend_db DBName;
timeout 30s ssh z1 "/utils/create_snapshot.sh data/database safe_suspended_db2_$1; sync";
resume_db DBName;
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310722
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
забыл написать,

между suspend и zfs snapshot делается:

free && sync && echo 3 > /proc/sys/vm/drop_caches && sync && free;

для файловой системы на хосте DB2
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310738
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
хотел бы отметить причину использования ZFS снэпшотов

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

т.е. например, если база 100GB восстанавливается из бэкапа с соседнего ZFS сервера за 1-2 часа, с TSM более чем за 5 часов

то откат на снэпшот ZFS происходит за несколько секунд, и потом еще надо подождать минут 10 выполнения следующих команд:

ssh $ClientHost "bash -lc 'db2 restart database "$Name" write resume'";
ssh $ClientHost "db2 terminate; #db2 activate database $Name";
ssh $ClientHost "bash -lc 'db2 set write resume for database'";
ssh $ClientHost "db2 connect to $Name; db2 terminate";


прошу не разводить холивар на тему "снэпшоты - это не бэкапы"

1) во первых потому-что причина отката - бывает возврат на предыдущую точку до какого-либо действия типа установки новой версии или запуска скрипта

2) во вторых потому что обычный бэкап делается да (ессно на другое хранилище), и архивирование логов тоже планируется по схеме, описанной выше

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


так вот, например, если через год объем базы вырастет в 10 раз до 1 ТБ, то если мы хотим сделать точку сохранения перед установкой новой версии и потом захотим вернуться на нее, то в случае использования:

1) ZFS снэпшота нам придется ждать те же самые 10 минут выполнения crash recovery, что и для базы в 10 раз меньшего объема

2) DB2 бэкапа придется восстанавливать в течение многих часов и потом еще докатывать логи. очень весело ...

Или я чего-то не понимаю?

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

В общем правильно ли я описал, как можно совместить снэпшотирование с архивированием логов? - это самый главный вопрос ветки.
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310743
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dbtwoshnick,

Добрый день.

Вы как-то странно пытаетесь восстанавливать копии.
Почему вы не пользуетесь db2inidb?
http://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.admin.cmd.doc/doc/r0004473.html

Если вы хотите вернуться на копию базы, то вам после восстановления датасета достаточно сделать
db2inidb mydb as snapshot

О каком несоответствии между активными и архивными логами вы говорите? Вы ведь полностью возвращаетесь к состоянию файловой системы, которая была при качалке копии.
Или вы логи держите на другом датасета, который не копируется?
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310744
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Mark Barinstein,

качалке == начале
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310747
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dbtwoshnick,

Отделять архивные и активные логи надо, если будет желание восстанавливаться с последующим накатом по логам.
Тогда после восстановления вы стираете активные логи (но только с теми именами, которые есть в архивном пути к моменту восстановления) и делаете доступными архивные логи, накопившиеся после операции снепшота. Т.е. вы можете поставить logarchmeth1 в disk или tsm. Главное, чтобы эти логи потом были доступными для rollforward.

archive log перед write suspend делать не надо - при write suspend это делается автоматически.
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310752
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Mark BarinsteinО каком несоответствии между активными и архивными логами вы говорите? Вы ведь полностью возвращаетесь к состоянию файловой системы, которая была при качалке копии.
Или вы логи держите на другом датасета, который не копируется?

Насколько я понимаю, для возможности восстановления базы из бэкапа с rollforward
бэкапы (offline или онлайн, полные и инкрементальные) и архивные логи нужно хранить на хранилище, отличном от хранилища, на котором расположены базы данных DB2

Тогда в случае невосстановимого сбоя основного хранилища можно было бы заменить железо основного хранилища и восстановить на него базу из бэкапа (с другого бэкап хранилища) с rollforward, например, до point in time в логах, находящихся на другом хранилище вместе с бэкапами

Начитавшись про эти замечательные возможности DB2 около года назад, я сделал NFS mount /mnt/prom-logs

установил параметр MIRRORLOGPATH:
баз db2 update db config using MIRRORLOGPATH /mnt/prom-logs/$DBName;

в результате при первом коннекте DB2 много отправляла по сетке на NFS маунт и вроде бы было все хорошо,

НО, решив проверить возможность отката на снэпшот, я запустил обычные для этого операции, которые раньше всегда работали без сбоев, при первом коннекте к DB2 или restart db не помню точно, получил очень долгое ожидание порядка часа и потом ошибку не помню с каким номером, даже сначала напугался, что моя схема снэпшотов работает неправильно ...

но потом откатился на чуть более ранний снэпшот, который сделал перед изменениями MIRRORLOGPATH
и restart db прошел как обычно без каких либо ошибок за 10 минут

Отсюда я сделал вывод, что если MIRRORLOGPATH указывает на каталог за пределами ZFS снэпшота, на которые происходит откат файловой системы, то при рестарте базы данных, когда она пытается сделать crash recovery, то видит, что каталог MIRRORLOGPATH содержит какие-то непонятные логи из будущего, которое никогда не наступит после отката на снэпшот, долго думает, очень много шлет по NFS не помню в каких направлениях и в результате вываливается с ошибкой.

Поэтому на данный момент считаю (предположение, подтвержденное моим опытом), что архивные логи можно выводить за пределы снэпшотируемого каталога DB2 только обычным копированием из каталога (с архивными логами) внутри снэпшота.

НО восстанавливаться таким способом из бэкапа еще не пробовал, предстоит проверить.

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

Хотя может быть, DB2 не понравилось несоответствие зеркала логов основному каталогу логов внутри снэпшота, который был LOGRETAIN.

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

За пределы снэпшота (к бэкапам и логам на другом хранилище) в моей предложенной схмеме работы может обратиться только db2 restore, мне кажется так безопаснее и беспроблемнее.
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310753
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Mark Barinsteinarchive log перед write suspend делать не надо - при write suspend это делается автоматически.

у меня db2 "archive log" теперь вынесены до suspend, чтобы надолго не саспендить, потому что саспендится несколько баз

db2 archive log for db DB3
db2 archive log for db DB2
db2 archive log for db DB1

suspend_db DB1
suspend_db DB2
suspend_db DB3

snapshot

resume_db DB3
resume_db DB2
resume_db DB1

мне кажется, так будет меньше простоя
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310754
db2top
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dbtwoshnickНачитавшись про эти замечательные возможности DB2 около года назад, я сделал NFS mount /mnt/prom-logs

установил параметр MIRRORLOGPATH:
баз db2 update db config using MIRRORLOGPATH /mnt/prom-logs/$DBName;


MIRRORLOGPATH это зеркало для АКТИВНЫХ логов
Чтобы откладывать АРХИВНЫЕ логи на NFS-шару нужно использовать LOGARCHMETH1/2
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310755
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Mark BarinsteinОтделять архивные и активные логи надо, если будет желание восстанавливаться с последующим накатом по логам.

Ну как бы желания особого нет конечно заниматься восстановлением db2 restore :) но если придется (не дай Бог конечно), надо, чтобы такая возможность была, включая докат по архивным логам.

Mark BarinsteinТогда после восстановления

В смысле после отката на снэпшот или после восстановления из бэкапа т.е. после db2 restore ?


Mark Barinsteinвы стираете активные логи (но только с теми именами, которые есть в архивном пути к моменту восстановления) и делаете доступными архивные логи, накопившиеся после операции снепшота. Т.е. вы можете поставить logarchmeth1 в disk или tsm. Главное, чтобы эти логи потом были доступными для rollforward.

Не пойму, вы говорите о восстановлении которое состоит и из отката на снэпшот и одновременно о докате логов

Разве логи можно докатывать в любой момент отличный от "после db2 restore"?

Т.е. ну откатился я на снэпшот, зачем мне удалять активные логи? я ведь все равно не смогу сделать rollforward? максумум, что в данном случае возможно по логам - это crash recovery после команду restart db with write resume, или я ошибаюсь?
и как раз тут важно сохранить старые активные логи из снэпшота и чтобы DB2 не лез за архивными логами куда-то за пределы снэпшота или я не прав?
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310756
db2top
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dbtwoshnickправильно ли я понимаю, что длительность восстановления базы из бэкапа прямо пропорциональна ее размеру при прочих равных условиях?

т.е. например, если база 100GB восстанавливается из бэкапа с соседнего ZFS сервера за 1-2 часа, с TSM более чем за 5 часов


Скорость бекапа/рестора зависит от многих вещей : скорости чтения/записи на источнике/приемнике, скорости среды передачи данных, параллелизма, количества и размера буферов, размера util_heap_size, распредения данных по табличным пространствам, компрессии т .д

100GB за 5 часов это очень плохо.
Из собственного недавнего: тестовая база в 1.3 TB ресторилась за 6 часов с TSM'а (некомпрессный бекап с LTO-6 ленты) и 4 часа с компрессного бекапа на NFS-шаре сервера с резервной площадки. В обоих случая по обе стороны гигабитные линки.
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310757
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
db2topMIRRORLOGPATH это зеркало для АКТИВНЫХ логов
Чтобы откладывать АРХИВНЫЕ логи на NFS-шару нужно использовать LOGARCHMETH1/2

Точно ведь, большое спасибо! не ожидал .... хотя в доке это описано

А зачем оно надо?
Часто активные логи лежат в файловой системе отличной от той, в которой база?
Дублирование ведь обычно делается в дисковых массивах, ZFS vdevs и т.п.

Тогда почему бы уж не дублировать и каталог с базой тоже ? :)
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310758
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dbtwoshnick,

Вы неправильно используете операции со снепшотами.
Про mirrorlogpath вам уже сказали. Для инициализации копии надо пользоваться db2inidb в нужном режиме, как написано по ссылке, которую я привел.
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310759
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
db2top100GB за 5 часов это очень плохо.
Из собственного недавнего: тестовая база в 1.3 TB ресторилась за 6 часов с TSM'а (некомпрессный бекап с LTO-6 ленты) и 4 часа с компрессного бекапа на NFS-шаре сервера с резервной площадки. В обоих случая по обе стороны гигабитные линки.

TSM где то в другой стойке до которой путь через свич в другой серверной ...

На локальный NFS сервер с гигабитным линком OFFLINE бэкап проходит за 1 час, ONLINE за полтора без нагрузки пользователй, с пользователями наверно подольше

НО! ...зачем тратить все эти часы на восстановление?! если:

1) основное хранилище со снэпшотами живо (т.е. бэкап с другого хранилища в этот момент времени НЕ нужен)
2) ZFS снэпшот позволяет проделать откат за 10 минут (включая db2 restart)

время некуда потратить чтоли?
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310762
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Mark Barinsteindbtwoshnick,

Вы неправильно используете операции со снепшотами.
Про mirrorlogpath вам уже сказали. Для инициализации копии надо пользоваться db2inidb в нужном режиме, как написано по ссылке, которую я привел.

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

просто мне так удобнее, как я использую

DB2 оказывается в состоянии как будто выключили сервер, но при этом заране сбросили все буфера и заморозили все IOP операции
т.е. режим безопасный

мне ненужна копия базы из снэпшота, мне просто нужен 100% работающий crash recovery без затрат моего времени на дополнительные манипуляции с командами db2 в области снятия снэпшотов для копий базы, перекаталогизации и т.п.
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310764
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
авторНе пойму, вы говорите о восстановлении которое состоит и из отката на снэпшот и одновременно о докате логов

Разве логи можно докатывать в любой момент отличный от "после db2 restore"?

Т.е. ну откатился я на снэпшот, зачем мне удалять активные логи? я ведь все равно не смогу сделать rollforward? максумум, что в данном случае возможно по логам - это crash recovery после команду restart db with write resume, или я ошибаюсь?
и как раз тут важно сохранить старые активные логи из снэпшота и чтобы DB2 не лез за архивными логами куда-то за пределы снэпшота или я не прав?Вы ошибаетесь.
Мы не говорим здесь про db2 restore. Речь про откат на снепшот.
Вся эта тема с write suspend / db2inidb для того и затеяна, чтобы позволять такие вещи. Никаких restart database делать не надо.

Почему надо стирать старые архивные логи при db2inidb отличном от snapshot.
Логи с этими именами, скорее всего, уже сархивированы после write resume. И они содержат транзакции, по которым должен пойти rollforward. Именно они должны быть доступными rollforward, а не эти старые активные, до которых rollforward доберётся в первую очередь.
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310765
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
забыл упомянуть, что снэпшотится весь каталог /home, включая /home/db2inst со всеми настройками DB2

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

т.е. DB2 (СУБД) никогда даже и не узнает, что был снэпшот
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310766
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
вернее, что был откат на снэпшот
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310769
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
и снэпшот затевался именно как контрольная точка перед запуском скриптов,
т.е. активных транзакций в этот момент времени скорее всего не будет,
можно предварительно делать db2 force application all

это для для защиты от сбоем комплекса, а для защиты от багов разработчика или собственных ошибок при запуске скриптов
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310770
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dbtwoshnickэто НЕ для защиты от сбоев комплекса, а для защиты от багов разработчика или собственных ошибок при запуске скриптов
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310771
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
можно было бы даже и db2stop делать до снэпшота,
но тогда сбрасываюся буфера - а это опять потеря времени на их повторный прогрев
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310780
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dbtwoshnickMark Barinsteindbtwoshnick,

Вы неправильно используете операции со снепшотами.
Про mirrorlogpath вам уже сказали. Для инициализации копии надо пользоваться db2inidb в нужном режиме, как написано по ссылке, которую я привел.

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

просто мне так удобнее, как я использую

DB2 оказывается в состоянии как будто выключили сервер, но при этом заране сбросили все буфера и заморозили все IOP операции
т.е. режим безопасный

мне ненужна копия базы из снэпшота, мне просто нужен 100% работающий crash recovery без затрат моего времени на дополнительные манипуляции с командами db2 в области снятия снэпшотов для копий базы, перекаталогизации и т.п.В чем разница между выходом из квартиры через дверь, как положено, или через окно? В принципе, результат одинаковый - вы оказываетесь на улице.
Если вам удобнее выходить через окно - выходите. Только не спрашивайте потом, почему я падаю иногда, пачкаюсь, и как этот процесс выхода через окно оптимизировать.

Получение 100% работающего crash recovery - это самоцель?
Если цель - получить 100% работающую базу, то пользуйтесь db2inidb mydb as snapshot. Всего одна команда. Команда должна завершиться быстрее, т.к. в отичие от crash recovery, она просто откатывает все незавершенные транзакции. Ничего перекаталогизировать не надо, т.к. база уже каталогизирована на этой системе.
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310785
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Mark Barinsteindbtwoshnick,
Вы как-то странно пытаетесь восстанавливать копии.
Почему вы не пользуетесь db2inidb?


мне не нужен клон или standby, на который бы я накатывал логи, и вообще мне не надо накатывать логи после отката на снэпшот, потому что подразумевается, что нужных транзакций, которые бы я хотел накатить после отката на ZFS снэпшот нет,
потому что перед запуском скрипта разработчиков, я бы остановил приложение, сделал application force all

судя по описанию:
http://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.admin.cmd.doc/doc/r0004473.html
предположительно мне подошел бы режим MIRROR
т.е. db2inidb DBName AS MIRROR

но я не пойму, зачем мне это? что мне это даст по сравнению c restart db
restart db with write resume делаю лишь потому, что просто соnnect однажды не сработал и мне пришлось гуглить эту волшебную комбинацию :) restart db with write resume, чтобы потом начал работать connect

Mark Barinsteindbtwoshnick,
Если вы хотите вернуться на копию базы, то вам после восстановления датасета достаточно сделать
db2inidb mydb as snapshot


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

в доке написано, что db2inidb mydb as snapshot создает клон базы, что это такое клон ? где про это можно прочитать подробнее?

дока Attempting to connect to a split mirror database before initializing it erases the log files needed during roll forward recovery.

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

может быть есть книжки, где это все подробнее описано?
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310792
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Mark BarinsteinЕсли цель - получить 100% работающую базу

Именно так, причем чем быстрее, тем лучше

Mark Barinstein, то пользуйтесь db2inidb mydb as snapshot. Всего одна команда.

Интересно конечно сравнили :) ярко. Уже понял, что принято через db2inidb mydb as snapshot, но в связи с относительной редкостью использования этого режима деталей гуглится про него немного для более лучшего понимания, а про restart db написано намного больше.

Хотелось бы узнать отличия между:

db2inidb mydb as snapshot
и
db restart write resume (- это crash recovery?)

Именно в терминах DB2 без бытовых аналогий, чтобы лучше понять, что там происходит в недрах DB2 в этих режимах


Mark BarinsteinКоманда должна завершиться быстрее, т.к. в отичие от crash recovery, она просто откатывает все незавершенные транзакции.

Вот это уже очень интересно. Пожалуйста, объясните:

1) что делает crash recovery (restart db) кроме того, что делает db2inidb?
2) что делает db2inidb, чего не делает restart db?

Страшновато использовать команды без понимания, restart db хоть и медленнее, но пока что для меня она понятнее.
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310793
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Надо было выбрать ник dbtwoshnick-nooby :)

Чем больше читаешь про DB2, тем больше понимаешь, как мало знаешь про DB2.
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310797
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dbtwoshnick,

Клон == снэпшот == копия.
Вам нужен снэпшот.

db2inidb ничего сама не клонирует / копирует / создает.
Она инициализирует то, что находится на диске, в одном из 3-х нужных режимов. Выделенное слово - ключевое.

Т.е. вот вам надо вернуться к копии. Вы делаете db2stop, вернули состояние файловых систем DB2 в то состояние, в котором они были в момент write resume, db2start.
Дальше у вас есть выбор в зависимости от того, что вы хотите делать дальше.

- Если вам нужна копия (клон) базы, т.е. вы не хотите дальше накатываться по логам, то вы инициализируете базу as snapshot.
В этом случае оно откатывает все незавершенные транзакции в базе, если они там вообще были на момент write suspend, и открывает базу для работы. Вы получаете копию базы. Если вы находитесь в режиме архивирования логов, то начинается новая логовая последовательность.
- Если вы решили накатываться по логам, которые появились после write resume, то вы инициализируете базу as mirror. Дальше вы накатываете базу по этим логам так же, как вы бы делали после db2 restore из онлайн архива. Эти появившиеся логи, естественно, должны быть доступны rollforward.
- Если вы решили сделать standby базу (например, для HADR), то вы инициализируете ее в режиме as standby. Дальше вы вы обращаетесь с этой базой так же, как вы бы делали после db2 restore на standby для настройки DB2 HADR.

Всё это описано в документации по ссылке выше.
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310807
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Mark Barinstein- Если вам нужна копия (клон) базы, т.е. вы не хотите дальше накатываться по логам, то вы инициализируете базу as snapshot.
В этом случае оно откатывает все незавершенные транзакции в базе, если они там вообще были на момент write suspend, и открывает базу для работы. Вы получаете копию базы. Если вы находитесь в режиме архивирования логов, то начинается новая логовая последовательность.
- Если вы решили накатываться по логам, которые появились после write resume, то вы инициализируете базу as mirror. Дальше вы накатываете базу по этим логам так же, как вы бы делали после db2 restore из онлайн архива. Эти появившиеся логи, естественно, должны быть доступны rollforward.
- Если вы решили сделать standby базу (например, для HADR), то вы инициализируете ее в режиме as standby. Дальше вы вы обращаетесь с этой базой так же, как вы бы делали после db2 restore на standby для настройки DB2 HADR.


на первый взгляд из трех вариантов этого описания действительно as snapshot выглядит наиболее подходящим

но смущает слово "копия", по идее копия (по сравнению с оригиналом) может получить какие-то новые идентификаторы чего-либо, на то она и копия, а не оригинал

поэтому с моей точки зрения (пока), было бы логичнее (в моем понимании), но не удобнее и не быстрее
использовать mirror, но с модификатором without rolling forward, если бы так было можно
как мне кажется, это было бы больше похоже на
db2stop; zfs snapshot; db2start,
а потом db2stop; zfs rollback; db2start

т.е. при этом не создавалось бы никаких копий, а оставался бы только оригинал, как он был в момент снэпшота
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310808
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dbtwoshnickХотелось бы узнать отличия между:

db2inidb mydb as snapshot
и
db restart write resume (- это crash recovery?)

Именно в терминах DB2 без бытовых аналогий, чтобы лучше понять, что там происходит в недрах DB2 в этих режимах db2 restart db применяется, как написано в документации, когда обслуживание базы завершилось неожиданно. Но это не ваш случай - write suspend - вполне себе ожидаемая операция. То, что оно в вашем случае работает - удачное недокументированное стечение обстоятельств, которое может работать до поры до времени. Если вы встретитесь в дальнейшем с проблемами - первое, что вам скажут - не делайте так больше.
dbtwoshnickВот это уже очень интересно. Пожалуйста, объясните:

1) что делает crash recovery (restart db) кроме того, что делает db2inidb?
2) что делает db2inidb, чего не делает restart db?

Страшновато использовать команды без понимания, restart db хоть и медленнее, но пока что для меня она понятнее. crash recovery состоит из 2-х последовательных фаз: forward и backward recovery.
Forward - в файлы с данными записываются подтвержденные изменения, найденные в логах, которые не успели из буферов сброситься на диск.
Backward - откатываются изменения, сделанные незавершенными транзакциями.

Про db2inidb в доке сказано, что она только откатывает незавершенные транзакции (т.е. выполняет только backward фазу, как можно понять), но, честно говоря, мне кажется, что forward фаза всё равно нужна и в этом случае. Поэтому, скорее всего, обе они в этом смысле должны делать то же самое.
Разница может быть в том, что db2inidb делает какие-то нужные внутренние операции при инициализации (флаги в котрольных файлах), которые crash recovery не делает и наоборот.

Для ускорения forward фазы можете перед write resume пользоваться командой flush bufferpools all - это сброс "грязных" страниц из памяти на диск. Forward фазе после этого надо будет мешьше работы делать.
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310810
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Mark BarinsteinРазница может быть в том, что db2inidb делает какие-то нужные внутренние операции при инициализации (флаги в котрольных файлах), которые crash recovery не делает и наоборот.


вот это меня больше всего и смущает, пометит базу какой-нибудь копией вместо оригинала, а потом какие-нибудь операции не пойдут, например с CDC агентом и придется все перенастривать или вообще из бэкапа базу восстанавливать ...
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310815
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Mark Barinsteindb2 restart db применяется, как написано в документации, когда обслуживание базы завершилось неожиданно. Но это не ваш случай - write suspend - вполне себе ожидаемая операция.

Это был бы не мой случай, если бы я следовал логике inidb.
http://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.admin.cmd.doc/doc/r0001974.html

докаWRITE RESUME
Allows you to force a database restart on databases that failed while I/O writes were suspended. Before performing crash recovery, this option will resume I/O writes by removing the SUSPEND_WRITE state from every table space in the database.

Но если представить, что неожиданно скрипт разработчика отработал неправильно и мне неожиданно захотелось остаться в сотоянии снэпшота после write suspend, а для этого не стал запускать скрипт разработчика (как будто заранее предчувствовал проблему), а вместо этого просто выдернул вилку сервера из розетки сразу же после write suspend, ну еще zfs снэпшот сделал к которому откатился на всякий случай после повторного включения :) так можно представить?


дока The WRITE RESUME option can also be used in the case where the connection used to suspend I/O writes is currently hung and all subsequent connection attempts are also hanging. When used in this circumstance, RESTART DATABASE will resume I/O writes to the database without performing crash recovery.

А как DB2 определит был "IO connection hung" или во время write suspend я выдернул вилку сервера из розетки или восстановился из снэпшота и потом запустил DB2?

докаRESTART DATABASE with the WRITE RESUME option will only perform crash recovery when you use it after a database crash. The WRITE RESUME parameter can only be applied to the primary database.

мне и надо primary

Mark Barinstein То, что оно в вашем случае работает - удачное недокументированное стечение обстоятельств, которое может работать до поры до времени.
Не представляю как может быть иначе, если я не планировал изначально вообще использовать write suspend, а просто хотел воспользоваться функционалом crash recovery, но при этом создать максимально благоприятные условия для recovery. т.е. сбросить все данные из различных write cash (DB2, ext3->iSCSI, ZFS zvol) на диск и только потом снэпшотнуть (выдернуть вилку из розетки), а потом воспользоваться описанием restart db write resume про неожиданные ситуации, которую по сути я сам вызвал. Про write suspend уже потом узнал случайно, очень пригодилось тем, что именно в доке по команде restart db write resume описана неожиданная ситуация, которую я эксплуатирию в своем решении.
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310817
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dbtwoshnickMark BarinsteinРазница может быть в том, что db2inidb делает какие-то нужные внутренние операции при инициализации (флаги в котрольных файлах), которые crash recovery не делает и наоборот.


вот это меня больше всего и смущает, пометит базу какой-нибудь копией вместо оригинала, а потом какие-нибудь операции не пойдут, например с CDC агентом и придется все перенастривать или вообще из бэкапа базу восстанавливать ...Нет никакой разницы между:
db2inidb mydb as snapshot
и
db2inidb mydb as mirror
db2 rollforward db mydb stop

Ничем таким база не метится специально.
CDC агент не должен испугаться.
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310818
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dbtwoshnick,

restart db write resume вы используете только в том случае, когда вы сделали write suspend, и после этого база упала по какой-то причине, не долждавшись онончания копирования и write resume.
В остальных случаях эту команду использовать не надо, и то, что вы используете эту команду после восстановления нормально завершившегося снэпшота - тоже неправильно.
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310825
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Mark Barinsteindbtwoshnick,
restart db write resume вы используете только в том случае, когда вы сделали write suspend, и после этого база упала по какой-то причине, не долждавшись онончания копирования и write resume.

А разве состояние в снэпшоте, перед которым были сброшены на диск все write cache какие только можно представить, может быть менее приемлемым для recovery, чем если бы база действительно упала?

Mark BarinsteinВ остальных случаях эту команду использовать не надо

Вот я пытаюсь понять почему не надо, какие могут быть побочные эффекты?

Mark Barinsteinи то, что вы используете эту команду после восстановления нормально завершившегося снэпшота - тоже неправильно.

Хуже то ведь не будет, разве запрещено запускать restart database (без write resume) на исправных базах в обычном не suspend состоянии?
write resume лишь гарантированно выводит базу из этого состояния
и заметьте, что снэпшот охватывает полностью весь /home/db2inst без бинарников /opt конечно же

Т.е. у DB2 нет шансов определить, что это было, падение или восстановление из снэпшота, не так ли?

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

Вот представьте, что мы вообще забыли про write suspend и просто думаем, как бы нам снять снэпшот из которого база гарантированно прийдет в норму, откат транзакций разрешен.

Ведь если crash recovery рассчитан даже на сложные условия IO, когда может отвалиться хранилище и часть данных вообще останется в RAM и потеряется там.

А у меня сброс всех write cache на диск - т.е. тепличные условия для recovery.

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

Вот представьте, мы не делаем никакого снэпшота, делаем только write suspend и потом write resume, это ведь разрешено

Теперь представьте мы добавили между suspend и resume snapshot.

Откатились, как DB2 догадается был ли откат на снэпшот или включение после сбоя? Кааак?!
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310826
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dbtwoshnick,

Мы можем долго еще дискутировать на эту тему.
db2 - довольно сложный продукт, и никто не будет вам писать объяснений, почему определенный процесс надо делать именно так, как описано, а не по-другому, даже если очень хочется, и вроде бы работает.
Почему для останова db2 по-хорошему надо пользоваться db2stop force, а не, скажем, kill -9. Ведь восстановится, crash recovery есть.
Моя позиция по любому процессу такая - если есть штатная процедура, надо ее использовать, а не искать себе приключений.
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310831
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Mark BarinsteinДля ускорения forward фазы можете перед write resume пользоваться командой flush bufferpools all - это сброс "грязных" страниц из памяти на диск.

эта команда поддерживается в v9.7?
почему-то выдает SQL0104N :(


в v10 работает
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310834
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Mark Barinsteindbtwoshnick,

Мы можем долго еще дискутировать на эту тему.
db2 - довольно сложный продукт, и никто не будет вам писать объяснений, почему определенный процесс надо делать именно так, как описано, а не по-другому, даже если очень хочется, и вроде бы работает.
Почему для останова db2 по-хорошему надо пользоваться db2stop force, а не, скажем, kill -9. Ведь восстановится, crash recovery есть.
Моя позиция по любому процессу такая - если есть штатная процедура, надо ее использовать, а не искать себе приключений.

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

Если бы можно было еще подробнее ознакомиться с более детальным описанием inidb as snapshot, возможно я бы начал ее использовать, а пока restart db мне кажется безопаснее применительно конкретно к моему случаю.

За ваши исчерпывающие ответы и советы ОГРОМНОЕ СПАСИБО! Ни раз уже выручали, просто я больше читаю, чем пишу в форум.
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310836
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
db2 connect to DBName

потом

[db2inst@XXX ~]$ db2 "FLUSH BUFFERPOOLS ALL"

в результате:

DB21034E The command was processed as an SQL statement because it was not a
valid Command Line Processor command. During SQL processing it returned:
SQL0104N An unexpected token "END-OF-STATEMENT" was found following "FLUSH
BUFFERPOOLS". Expected tokens may include: "JOIN <joined_table>".
SQLSTATE=42601
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310837
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dbtwoshnick,

Замена FLUSH BUFFERPOOLS ALL для некоторых версий до 10.1:
Код: plaintext
db2pdcfg -flushbp

Чтоб посмотреть, какой это оказывает эффект, запустите до и после:
Код: plaintext
db2pd -db  mydb  -dirtypages summary | awk -v RS='\n\n' '{if ($0 ~ /pages %/) print $0;}'
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310845
db2top
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dbtwoshnickА зачем оно надо?

Для пущей отказоустойчивости
dbtwoshnickЧасто активные логи лежат в файловой системе отличной от той, в которой база?

В критичных и нагруженных продакшенах обычно всегда. Причем на отдельных raid-группах.
dbtwoshnick Дублирование ведь обычно делается в дисковых массивах, ZFS vdevs и т.п.
Тогда почему бы уж не дублировать и каталог с базой тоже ? :)

Шит, как говорится, хаппенс. Падают (крайне редко конечно) даже отказоустойчивые CХД. Так что некоторые параноики бывает диски с разных стороджей LVM-ом зеркалируют.
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310849
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
db2topШит, как говорится, хаппенс. Падают (крайне редко конечно) даже отказоустойчивые CХД. Так что некоторые параноики бывает диски с разных стороджей LVM-ом зеркалируют.

а если LVM бахнется ? :)

не проще сделать тройные зеркала в аппаратном массиве RAID10 или zmirror3?
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310859
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
или у них даже отдельные линии связи да еще и с бондингом нескольких каналов до каждого хранилища в LVM?
но тогда отказоустойчивость железки, на которой крутится DB2 с LVM должна быть выше всех стораджей и линков до них
это из той области, когда можно и процы и оперативку на ходу менять?

наверно, это отдельное направление по обеспечению повышенной отказоустойчивости (выше средней)
за каждый 1% повышения отказоустойчивости, наверно, цена решения увеличивается на много процентов?
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310868
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
db2topВ критичных и нагруженных продакшенах обычно всегда. Причем на отдельных raid-группах.


Интересно, если отдельные части базы разбросаны по разным ZFS датасетам
то можно ли использовать для снэпшотов способ, похожий на мой (т.е. описанный выше), хотя бы с inidb в случае отката на снэпшотЫ?

Т.е. например, база на одном датасете, зеркало активных логов на другом, возможно еще какие-то файлы (а вот ктстати, например, logarchmeth1) на третьем датасете.


1) Уводим базу в suspend

2) Далее снэпшотим каждый из датасетов (которые могут быть даже в разных пулах на разных хранилищах) по отдельности для удобства с одинаковым именем снэпшота

3) И потом возвращаем базу обратно в состояние resume

Почему-то сразу не подумал о такой возможности, тогда ZFS снэпшоты подойдут даже при масштабировании?

Ведь в состоянии suspend нет никакой необходимости снэпшотить все датасеты абсолютно синхронно (да это и невозможно), главное успеть везде отснэпшотиться до resume, т.е. suspend-resume позволяет растянуть промежуток времени для "синхронизации" снэпшотов на разных хранилищах до любого приемлемого значения, наверно suspend для этого в первую очередь и присутствует в DB2?

В моем относительно простом случае можно было бы, наверно, даже снимать снэпшот прямо на ходу, на тестовой базе пробовал несколько раз такое, crash recovery отрабатывает без проблем, только дольше.
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310960
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Mark Barinsteindbtwoshnick,

Замена FLUSH BUFFERPOOLS ALL для некоторых версий до 10.1:
Код: plaintext
db2pdcfg -flushbp

Чтоб посмотреть, какой это оказывает эффект, запустите до и после:
Код: plaintext
db2pd -db  mydb  -dirtypages summary | awk -v RS='\n\n' '{if ($0 ~ /pages %/) print $0;}'


Марк,

можно ли это команду синхронизировать с шелом из которого она запускается?

пока получается асинхронно:

++ db2pdcfg -flushbp
State of the bufferpools:
Oldest LSN: 00000281FCE0902C
Newest LSN: 0000028275F9DCD4
Initiating background flush.
You can use "db2pdcfg -flushbp q" to monitor the progress of the flush operation.
When the oldest LSN reported by the q option is greater than the
newest LSN reported during the initial flush, then the flush has completed.
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39310994
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dbtwoshnickможно ли это команду синхронизировать с шелом из которого она запускается?

пока получается асинхронно:

++ db2pdcfg -flushbp
State of the bufferpools:
Oldest LSN: 00000281FCE0902C
Newest LSN: 0000028275F9DCD4
Initiating background flush.
You can use "db2pdcfg -flushbp q" to monitor the progress of the flush operation.
When the oldest LSN reported by the q option is greater than the
newest LSN reported during the initial flush, then the flush has completed.
Можно, конечно, тут в выводе команды даже написано как.
При первом вызове (без q) запоминаете newest lsn.
Последующие вызовы делаете с q в цикле с некоторой паузой после каждого до тех пор, пока при очередном вызове oldest lsn не будет больше, чем запомненный на первом шаге. Или до тех пор, пока не истечёт некоторый допустимый промежуток времени.
Это легко реализуется в командном файле.
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39311004
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Я имел ввиду, нет ли готового ключа, отслеживать конечно можно и самостоятельно, но проще, наверно, поставить паузу несколько секунд после сброса буферов.

Вообще после MSSQL 2005/2008 с моей точки зрения DB2 v8 напоминал некий конструктор (очень мощный), но который надо было тщательно настраивать вручную и обвешивать различными скриптами, т.е. велосипедить и читать много буков в доке :)

В современных версиях DB2 конечно многое улучшено, более удобно и упрощено для админа,
но лет 10 назад, как мне кажется MSSQL был явно удобнее, если админить DB2 без кучи готовых custom скриптов и опытным спеца-консультанта.

Хотя наверно у них была разная целевая аудитория, т.е. предполагаемая нагрузка на СУБД, требования по надежности и т.п.?

Интересно, усилится ли конкуренция после выхода MSSQL под Linux и увидем ли мы переход части платного функционала в бесплатный Express C?
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39313396
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Mark Barinsteindbtwoshnickпропущено...


вот это меня больше всего и смущает, пометит базу какой-нибудь копией вместо оригинала, а потом какие-нибудь операции не пойдут, например с CDC агентом и придется все перенастривать или вообще из бэкапа базу восстанавливать ...Нет никакой разницы между:
db2inidb mydb as snapshot
и
db2inidb mydb as mirror
db2 rollforward db mydb stop

Ничем таким база не метится специально.
CDC агент не должен испугаться.


Команда write resume с моей точки зрения описана более полно в относительно древней версии v8x:
https://www.informit.com/articles/article.aspx?p=169530&seqNum=6 SNAPSHOT. The split mirror copy of the database will be initialized as a clone of the primary database. (It will be a working copy that has its own transaction log files. )


Как мне кажется, это то, чего я боялся. Меняется LOG sequence в режиме SNAPSHOT, чтобы отличать ее от оригинальной в режиме MIRROR? Может ли испугаться CDC? и не только?

Что удивительно, такая замечательная фича как write suspend существовала в DB2 более 10 лет назад!
К сожалению нищеброды типа меня воспользоваться ей не могли в силу ограниченного доступа к Solaris в те времена.
Я даже пропустил фазу появления ZFS в kFreeBSD :(
Начал пользоваться только в 2012 при появлении чего-то более менее стабильного для Linux ядра.
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39313399
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Гуглю про файлы базы DB2 в разных хранилищах, можно ли безопасно снэпшотить после write suspend?

https://www.ibm.com/support/knowledgecenter/SSGLW6_5.2.0/com.ibm.p8.common.admin.doc/backup_restore/backup_online_technologies.htm Storage vendors provide snapshot capabilities that span multiple data volumes and logical unit numbers (LUNs) by using consistency groups, also known as protection groups. With these capabilities, they can capture a snapshot very quickly (almost instantaneously) across multiple data volumes or LUNs. This is a key technology for enabling online backups because it preserves relationships and references between data sets. It is also important to create the snapshots rapidly in order to both minimize the impact on the system and its users and to ensure that the data is consistent across data sets.


т.е. надо какие-то "protection groups" ?
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39313435
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
очень хотелось бы вынести активные логи на Intel Pro DC 3700 nvram

мне кажется производительность должна вырасти и очень даже заметно, но все уперлось в снэпшоты
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39313462
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
https://www.ibm.com/support/knowledgecenter/SSGLW6_5.2.0/com.ibm.p8.common.admin.doc/backup_restore/backup_online_technologies.htm
Suspending database writes reduces the overall rate of change of the data and places the database in a relatively clean state, which improves the chances of capturing all the data sets in a consistent state, even if the snapshot operation is not perfectly aligned in time across all the data sets.


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

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

но наверно предполагается не всегда возможное получение консистентной СРАЗУ со снэпшота

но после crash recovery всегда?
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39313493
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39313612
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
И еще вопросы:

1) как лучше цеплять активные логи на другом хранилище? варианты:

A) ext3 -> iscsi->liotarget->zvol
B) nfs->ZFS

Наверно второй вариант лучше?
Меньше уровней абстракции, быстрее и надежнее?

2) Если бы не было фичи write suspend

То был бы шанс проснэпшотить хранилища неодновременно и потом успешно пройти crash recover?

Что лучше снэпшотить сначала данные или активные логи?
спрашиваю, потому что write suspend не всегда срабатывает,
например, при одновременном online бэкапе он не сработвает, но ессно просигнализирует о несработке, т.е. это можно отслеживать и помечать снэпшоты метками safe/unsafe

Но все же если про write suspend и снэпшоты забыть, то что для DB2 предпочтительнее выдергивать из розетки в первую очередь для успешного прохождения crash recovery? хранилище с базой или с активными логами? насколько длительным может быть промежуток времени между отключениями этих хранилищь? сколько секунд/минут/ГБ транзакций может пережить DB2 после crash recovery?
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39313777
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dbtwoshnickКоманда write resume с моей точки зрения описана более полно в относительно древней версии v8x:
https://www.informit.com/articles/article.aspx?p=169530&seqNum=6 SNAPSHOT. The split mirror copy of the database will be initialized as a clone of the primary database. (It will be a working copy that has its own transaction log files. )


Как мне кажется, это то, чего я боялся. Меняется LOG sequence в режиме SNAPSHOT, чтобы отличать ее от оригинальной в режиме MIRROR? Может ли испугаться CDC? и не только?
Код: plaintext
1.
2.
3.
   t  log(n), log(n+1), log(n+2)
---+--------------------------->
   |  log(n), log(n+1)          
   +------------------>         

Вот у вас жила себе база, в момент t вы сделали ее копию, у вас стали плодиться логи в верхней последовательности.
Потом вы решили вернуться на копию, восстановили базу на момент времени t, но по верхней последовательности логов накатываться не стали . Это ключевой момент. Не важно, как именно вы это сделали: с помощью crash recovery, db2inidb as snapshot, db2inidb as mirror/standby + db2 rollforward stop.
Базу после этого открыли, она начала генерировать логи с теми же самыми номерами, но в нижней последовательности. Эти логи уже друг с другом не совместимы, это две абсолютно 2 разные цепочки логов.
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39314800
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Мне все же кажется, что без write suspend надо сначала снэпшотить активые логи, а потом базу,
потому что тогда возможно часть инфы продублируется в базе и логах и потом при последующем crash recovery DB2 заметит это и примет какое-либо правильное решение по этому поводу, позволяющее успешно восстановить базу.

А что будет при откате, если сделать наоборот, сначала снэпшотить базу, а потом активные логи?

База окажется в состоянии до момента времени, отраженного в самом начале активного лога, т.е. часть инфы будет утеряна, и если DB2 хотя бы заметит это, то наверно в лучшем случае откажется стартовать базу?

Все же должны же быть какие то мысли у специалистов по этому поводу, в т.ч. на базе официальной доки?

Ведь не исключено без всяких снэпшотов падение нескольких хранилищ почти одновременно, но все же с рассинхронизацией по времени, и наверняка crash recovery рассчитан и на такой случай?

Понятно, что еще остается и опция восстановления из бэкапа с архивными логами в случае, если crash recovery не справится со сложившейся ситуацией в базе.
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39316506
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
может быть, кому-нибудь интересно, получился такой скрипт снэпшотинга:

Код: powershell
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.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
set -x;

SnapshotSuffix=$1;

suspend_db()
{
        Name=$1;
        Sleep=$2;

        echo "===== Suspending database $Name";
        db2 terminate;
        db2 connect to $Name;
        db2pdcfg -flushbp; sleep $Sleep"s";

#       db2 flush bufferpools all;

        db2 set write suspend for database;
        Result=$?;

        db2pdcfg -flushbp q;
#       db2 disconnect $Name;
        echo;

        return $Result;
}

resume_db()
{
        Name=$1;
                                                                                                                                                                                                                                            
        echo "===== Resuming database $Name";                                                                                                                                                                                               
                                                                                                                                                                                                                                            
        db2 terminate;                                                                                                                                                                                                                      
        db2 connect to $Name;                                                                                                                                                                                                               
                                                                                                                                                                                                                                            
        db2 set write resume for database;                                                                                                                                                                                                  
        Result=$?;                                                                                                                                                                                                                          
                                                                                                                                                                                                                                            
#       db2 disconnect $Name;                                                                                                                                                                                                               
        echo;                                                                                                                                                                                                                               
                                                                                                                                                                                                                                            
        return $Result;                                                                                                                                                                                                                     
}                                                                                                                                                                                                                                           
                                                                                                                                                                                                                                            
zfs_snapshot()                                                                                                                                                                                                                              
{                                                                                                                                                                                                                                           
        FullSnapName=$1;                                                                                                                                                                                                                    
                                                                                                                                                                                                                                            
        timeout 30s ssh z1 "/xxx/create_snapshot2.sh $FullSnapName";                                                                                                                                                             
        Result=$?;                                                                                                                                                                                                                          
                                                                                                                                                                                                                                            
        return $Result;
}


db2 archive log for db Base3;
db2 archive log for db Base2;
db2 archive log for db Base1;

if (suspend_db Base1 5) && (suspend_db Base2 1) && (suspend_db Base3 2); then
{
        SuspendResult="safe_suspended";
} 
else
{
        SuspendResult="___WARNING_UNSAFE___NOT_suspended___";
} fi;

/xxx/flush.sh;

SnapName=$(date +\%Y_\%m_\%d__\%H_\%M_\%S)_$SuspendResult"_$SnapshotSuffix";

zfs_snapshot "nvram/xxx-temp@$SnapName";
SnapshotResult1=$?;

zfs_snapshot "data/xxx-database2@$SnapName";
SnapshotResult2=$?;

SnapshotResult3=0;


resume_db Base3;
resume_db Base2;
resume_db Base1;

timeout 5m /utils/backup/xxx_log.sh;
timeout 30s ssh backup2 "/xxx/create_snapshot.sh data/backup/xxx-log $SnapName; sync";

echo `date` >> /download/snapshot_log.txt;

if [ $SnapshotResult1 == 0 ] && [ $SnapshotResult2 == 0 ] && [ $SnapshotResult3 == 0 ]; then
{
        if [ "$SuspendResult" == "safe_suspended" ]; then
        {
                echo "============ SUCCESSFUL SUSPEND & SNAPSHOT.";
                exit 0;
        }
        else
        {
                echo "============ ERROR: BAD SUSPEND! but a SNAPSHOT CREATED ...";
                exit 1;
        } fi;
}
else
{
        echo "============== ERROR: COULD NOT CREATE SNAPSHOTS! SUSPEND STATUS was: $SuspendResult";
        exit 2;
} fi;

exit 3; # shall not reach here!
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39329569
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Первый раз столкнулся с проблемой невозможности стартануть базу из снэпшота.

На тестовом сервере после репликации снэпшота с пром. сервера.

++ ssh host 'bash -lc '\''db2 restart database XXX write resume'\'''
SQL1042C An unexpected system error occurred. SQLSTATE=58004

В db2diag.log много ошибок.

Примерно аналогично с другого снэпшота, когда база была под нагрузкой, тоже не стартует.

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

Отсюда препдоложительный вывод: crash recovery не всегда справляется .

Можно ли это как то улучшить/побороть?
Попробовать db2inidb? разве это чем то поможет?


Хотелось бы сначала сделать write suspend, и только потом уже сбросить все dirty pages из буферов, такое невозможно?
И кстати, наверно это было бы очень долго, потому что db2stop force насколько я понимаю занимается тем же самым в плане сброса буферов и иногда приходится ждать остановки 5-10 минут, хотя по dstat и iostat видно, что во всю идет запись, обычно очень мелкими блоками.
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39329572
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
и как после этого разносить table spaces по разным хранилищам?

если нет возможности нормально сбросить все dirty pages


может быть, надо сначала сделать QUIESCE ? потом сброс буферов, и только потом снэпшот,

но ведь тогда все соединения будут потеряны?

докаForces all users off the specified instance and database and puts it into a quiesced mode.
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39329578
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
db2diag.log
2016-10-19-09.39.52.586598+300 E154489817E963 LEVEL: Critical
PID : 6518 TID : 139769036138240PROC : db2sysc
INSTANCE: db2inst NODE : 000 DB : XXX
APPHDL : 0-7 APPID: *LOCAL.db2inst.161019043405
AUTHID : ROOT
EDUID : 19 EDUNAME: db2agent (XXX)
FUNCTION: DB2 UDB, base sys utilities, sqeLocalDatabase::MarkDBBad, probe:10
MESSAGE : ADM14001C An unexpected and critical error has occurred:
"DBMarkedBad". The instance may have been shutdown as a result.
"Automatic" FODC (First Occurrence Data Capture) has been invoked and
diagnostic information has been recorded in directory
"/home/db2inst/sqllib/db2dump/FODC_DBMarkedBad_2016-10-19-09.39.52.46
6333_0000/". Please look in this directory for detailed evidence
about what happened and contact IBM support if necessary to diagnose
the problem.
...
Рейтинг: 0 / 0
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
    #39330049
dbtwoshnick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
когда все части базы находились в одном ZFS dataset такого никогда не было

вопрос, добиться корректного снэпшота?
...
Рейтинг: 0 / 0
59 сообщений из 59, показаны все 3 страниц
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]