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

Откуда:
Сообщений: 160
Надо было выбрать ник dbtwoshnick-nooby :)

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

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

Всё это описано в документации по ссылке выше.
17 сен 16, 13:29    [19676723]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

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

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

Откуда: Москва
Сообщений: 4876
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 фазе после этого надо будет мешьше работы делать.
17 сен 16, 13:48    [19676757]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Mark Barinstein
Разница может быть в том, что db2inidb делает какие-то нужные внутренние операции при инициализации (флаги в котрольных файлах), которые crash recovery не делает и наоборот.


вот это меня больше всего и смущает, пометит базу какой-нибудь копией вместо оригинала, а потом какие-нибудь операции не пойдут, например с CDC агентом и придется все перенастривать или вообще из бэкапа базу восстанавливать ...
17 сен 16, 13:57    [19676771]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Mark Barinstein
db2 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 описана неожиданная ситуация, которую я эксплуатирию в своем решении.
17 сен 16, 14:15    [19676806]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4876
dbtwoshnick
Mark Barinstein
Разница может быть в том, что db2inidb делает какие-то нужные внутренние операции при инициализации (флаги в котрольных файлах), которые crash recovery не делает и наоборот.


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

Ничем таким база не метится специально.
CDC агент не должен испугаться.
17 сен 16, 14:19    [19676814]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
Mark Barinstein
Member

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

restart db write resume вы используете только в том случае, когда вы сделали write suspend, и после этого база упала по какой-то причине, не долждавшись онончания копирования и write resume.
В остальных случаях эту команду использовать не надо, и то, что вы используете эту команду после восстановления нормально завершившегося снэпшота - тоже неправильно.
17 сен 16, 14:27    [19676825]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Mark Barinstein
dbtwoshnick,
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 догадается был ли откат на снэпшот или включение после сбоя? Кааак?!
17 сен 16, 14:52    [19676876]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
Mark Barinstein
Member

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

Мы можем долго еще дискутировать на эту тему.
db2 - довольно сложный продукт, и никто не будет вам писать объяснений, почему определенный процесс надо делать именно так, как описано, а не по-другому, даже если очень хочется, и вроде бы работает.
Почему для останова db2 по-хорошему надо пользоваться db2stop force, а не, скажем, kill -9. Ведь восстановится, crash recovery есть.
Моя позиция по любому процессу такая - если есть штатная процедура, надо ее использовать, а не искать себе приключений.
17 сен 16, 15:15    [19676905]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Mark Barinstein
Для ускорения forward фазы можете перед write resume пользоваться командой flush bufferpools all - это сброс "грязных" страниц из памяти на диск.


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


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

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

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


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

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

За ваши исчерпывающие ответы и советы ОГРОМНОЕ СПАСИБО! Ни раз уже выручали, просто я больше читаю, чем пишу в форум.
17 сен 16, 15:30    [19676941]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

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

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

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

Чтоб посмотреть, какой это оказывает эффект, запустите до и после:
db2pd -db mydb -dirtypages summary | awk -v RS='\n\n' '{if ($0 ~ /pages %/) print $0;}'
17 сен 16, 15:47    [19676961]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
db2top
Guest
dbtwoshnick
А зачем оно надо?

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

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

Шит, как говорится, хаппенс. Падают (крайне редко конечно) даже отказоустойчивые CХД. Так что некоторые параноики бывает диски с разных стороджей LVM-ом зеркалируют.
17 сен 16, 16:24    [19677024]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
db2top
Шит, как говорится, хаппенс. Падают (крайне редко конечно) даже отказоустойчивые CХД. Так что некоторые параноики бывает диски с разных стороджей LVM-ом зеркалируют.


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

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

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

наверно, это отдельное направление по обеспечению повышенной отказоустойчивости (выше средней)
за каждый 1% повышения отказоустойчивости, наверно, цена решения увеличивается на много процентов?
17 сен 16, 17:42    [19677173]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
db2top
В критичных и нагруженных продакшенах обычно всегда. Причем на отдельных raid-группах.


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

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


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

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

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

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

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

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

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

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

Чтоб посмотреть, какой это оказывает эффект, запустите до и после:
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.
18 сен 16, 11:12    [19678903]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4876
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 не будет больше, чем запомненный на первом шаге. Или до тех пор, пока не истечёт некоторый допустимый промежуток времени.
Это легко реализуется в командном файле.
18 сен 16, 15:12    [19679348]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Я имел ввиду, нет ли готового ключа, отслеживать конечно можно и самостоятельно, но проще, наверно, поставить паузу несколько секунд после сброса буферов.

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

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

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

Интересно, усилится ли конкуренция после выхода MSSQL под Linux и увидем ли мы переход части платного функционала в бесплатный Express C?
18 сен 16, 15:52    [19679399]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

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


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

Откуда:
Сообщений: 160
Гуглю про файлы базы 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" ?
22 сен 16, 13:46    [19696460]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
очень хотелось бы вынести активные логи на Intel Pro DC 3700 nvram

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

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