Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / IBM DB2, WebSphere, IMS, U2, etc Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
 Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Добрый день,

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

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

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

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

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

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

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

Так получится?
17 сен 16, 04:39    [19676399]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
снэпшоты делаются так:

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;
17 сен 16, 04:45    [19676406]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
забыл написать,

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

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

для файловой системы на хосте DB2
17 сен 16, 04:47    [19676407]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
хотел бы отметить причину использования 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 бэкапа придется восстанавливать в течение многих часов и потом еще докатывать логи. очень весело ...

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

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

В общем правильно ли я описал, как можно совместить снэпшотирование с архивированием логов? - это самый главный вопрос ветки.
17 сен 16, 09:46    [19676473]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4868
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

О каком несоответствии между активными и архивными логами вы говорите? Вы ведь полностью возвращаетесь к состоянию файловой системы, которая была при качалке копии.
Или вы логи держите на другом датасета, который не копируется?
17 сен 16, 10:22    [19676499]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4868
Mark Barinstein,

качалке == начале
17 сен 16, 10:24    [19676501]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4868
dbtwoshnick,

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

archive log перед write suspend делать не надо - при write suspend это делается автоматически.
17 сен 16, 10:35    [19676514]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
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, мне кажется так безопаснее и беспроблемнее.
17 сен 16, 11:10    [19676557]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Mark Barinstein
archive 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

мне кажется, так будет меньше простоя
17 сен 16, 11:15    [19676561]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
db2top
Guest
dbtwoshnick
Начитавшись про эти замечательные возможности DB2 около года назад, я сделал NFS mount /mnt/prom-logs

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


MIRRORLOGPATH это зеркало для АКТИВНЫХ логов
Чтобы откладывать АРХИВНЫЕ логи на NFS-шару нужно использовать LOGARCHMETH1/2
17 сен 16, 11:23    [19676571]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
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 не лез за архивными логами куда-то за пределы снэпшота или я не прав?
17 сен 16, 11:26    [19676575]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
db2top
Guest
dbtwoshnick
правильно ли я понимаю, что длительность восстановления базы из бэкапа прямо пропорциональна ее размеру при прочих равных условиях?

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


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

100GB за 5 часов это очень плохо.
Из собственного недавнего: тестовая база в 1.3 TB ресторилась за 6 часов с TSM'а (некомпрессный бекап с LTO-6 ленты) и 4 часа с компрессного бекапа на NFS-шаре сервера с резервной площадки. В обоих случая по обе стороны гигабитные линки.
17 сен 16, 11:32    [19676578]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
db2top
MIRRORLOGPATH это зеркало для АКТИВНЫХ логов
Чтобы откладывать АРХИВНЫЕ логи на NFS-шару нужно использовать LOGARCHMETH1/2


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

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

Тогда почему бы уж не дублировать и каталог с базой тоже ? :)
17 сен 16, 11:32    [19676579]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4868
dbtwoshnick,

Вы неправильно используете операции со снепшотами.
Про mirrorlogpath вам уже сказали. Для инициализации копии надо пользоваться db2inidb в нужном режиме, как написано по ссылке, которую я привел.
17 сен 16, 11:33    [19676580]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
db2top
100GB за 5 часов это очень плохо.
Из собственного недавнего: тестовая база в 1.3 TB ресторилась за 6 часов с TSM'а (некомпрессный бекап с LTO-6 ленты) и 4 часа с компрессного бекапа на NFS-шаре сервера с резервной площадки. В обоих случая по обе стороны гигабитные линки.


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

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

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

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

время некуда потратить чтоли?
17 сен 16, 11:37    [19676581]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Mark Barinstein
dbtwoshnick,

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


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

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

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

мне ненужна копия базы из снэпшота, мне просто нужен 100% работающий crash recovery без затрат моего времени на дополнительные манипуляции с командами db2 в области снятия снэпшотов для копий базы, перекаталогизации и т.п.
17 сен 16, 11:42    [19676585]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4868
автор
Не пойму, вы говорите о восстановлении которое состоит и из отката на снэпшот и одновременно о докате логов

Разве логи можно докатывать в любой момент отличный от "после 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 доберётся в первую очередь.
17 сен 16, 11:46    [19676589]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
забыл упомянуть, что снэпшотится весь каталог /home, включая /home/db2inst со всеми настройками DB2

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

т.е. DB2 (СУБД) никогда даже и не узнает, что был снэпшот
17 сен 16, 11:48    [19676592]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
вернее, что был откат на снэпшот
17 сен 16, 11:48    [19676593]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

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

это для для защиты от сбоем комплекса, а для защиты от багов разработчика или собственных ошибок при запуске скриптов
17 сен 16, 11:53    [19676601]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
dbtwoshnick
это НЕ для защиты от сбоев комплекса, а для защиты от багов разработчика или собственных ошибок при запуске скриптов
17 сен 16, 11:53    [19676604]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
можно было бы даже и db2stop делать до снэпшота,
но тогда сбрасываюся буфера - а это опять потеря времени на их повторный прогрев
17 сен 16, 11:55    [19676609]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4868
dbtwoshnick
Mark Barinstein
dbtwoshnick,

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


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

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

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

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

Получение 100% работающего crash recovery - это самоцель?
Если цель - получить 100% работающую базу, то пользуйтесь db2inidb mydb as snapshot. Всего одна команда. Команда должна завершиться быстрее, т.к. в отичие от crash recovery, она просто откатывает все незавершенные транзакции. Ничего перекаталогизировать не надо, т.к. база уже каталогизирована на этой системе.
17 сен 16, 12:36    [19676661]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Mark Barinstein
dbtwoshnick,
Вы как-то странно пытаетесь восстанавливать копии.
Почему вы не пользуетесь 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 Barinstein
dbtwoshnick,
Если вы хотите вернуться на копию базы, то вам после восстановления датасета достаточно сделать
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 на точку позднее, чем был сделан снэпшот, т.е. активные логи из снэпшота, которые перейдут в архив меня полностью устроят

может быть есть книжки, где это все подробнее описано?
17 сен 16, 12:51    [19676673]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
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 хоть и медленнее, но пока что для меня она понятнее.
17 сен 16, 13:10    [19676699]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / IBM DB2, WebSphere, IMS, U2, etc Ответить