epic fail.part 2

Совсем недавно, около 10 дней назад, по сообщению Interfax, конденсатом залило сервера, на которых хранились заявки граждан на получение загранпаспортов.  Ничего страшного, бывает. Жара. Смешно  другое, что в результате, система простояла не менее 5 дней. Итак, у вас есть система, заказчиками которой являются все жители страны старше 16 лет, при этом каждый заказчик платит вам 2500р ($83)  за паспорт...но у Вас все-таки не хватает денег на резервную систему и даже  нормальный кондиционер. При общей стоимости системы не менее 200 млн рублей.   Раз система простояла 5 дней, то вряд ли они ее восстаналивали из backup -это заняло бы гораздо меньше времени. Скорее всего (это мое предположение), собирали заново, недостающее пересканировали..

Ok, можно украсть и разворовать все что угодно, но сделать резервную  систему изо всякого хлама стоит совсем недорого. Сейчас многотерабайтный NAS стоит несколько тысяч рублей.  Навтыкать дисков в Linux машинку и  поднять Openfiler - делов на пару часов. Складывать там резервные копии - простейший скрипт. Но, см. например сюда:  "70 баз работают 8 лет в режиме noarchivelog, при сбое носителей простой базы может дойти до 3-х дней , естественно с потерей данных за последний день, мало того даже холодные бэкапы не делаюся, делается полный экспорт базы, из которого база (90 Гб) восстанавливается 30 часов. Это всех устраивает!". Без комментариев. Дело не миллионах рублей и дачах, построенных на эти деньги. Дело все-таки в отношении к своей работе...

PS Ну  а пока вспомните, когда последний раз вы пробовали восстановиться, из того, что вы считаете своим backup :))  Так, на всякий случай, чтобы про вас не написали в газете.....

Читать дальше...

MAA, 11g, lost write

На своей последней презентации по HA я  сморозил глупость про lost write в Oracle Database. Прошу прощения. На самом деле, lost write - это когда подсистема ввода вывода сообщила, что блок записан, но на самом деле этого не произошло, и у нас по прежнему на диске старый блок. Если у Вас single database, то тут поделать ничего нельзя. Вы будете получать неконсистентные данные, пока не догадаетесь,  что тут дело нечисто и не восстановитесь из backup.

Но если вы работаете с 11g и у вас есть возможность установить параметр   DB_LOST_WRITE_PROTECT, и тогда, при чтении блоков с диска, то в redo будет писаться доп. информации о текущем SCN каждого блока. Standby (если он у Вас есть), способен в момент применения redo, проверять, совпадает ли у него версия SCN блока на Standby с пришедшей вместе с redo. Если они расходятся, значит мы имеем дело с lost writes и можем запросить блок из источника, у которого SCN больше.

Конечно же механизм lost writes не имеет общего с механизмами проверки контрольной суммы блока (db_block_checksum)  и логической проверки блока (db_block_cheking), работающими еще с версии 8i. Рекомендую Metalink Note 32969.1 как самый короткий источник, объясняющий разницу в механизмах. В 11g  R1 также появился параметр db_ultra_safe, который сразу выставляет все три параметра.  Ссылка на документацию. RTFM нам всем поможет.

PS
Рекомендую также пройти  MAA Architecture Assessment.  И помните, что в  каждой шутке есть только доля шутки..
На фотографии - катамаран 2-ка с двумя достаточно взрослыми  мужчинами чуть было не сыграл в lost write в пороге водопадный на реке Китой, Саяны.

Читать дальше...

RAC и Active Data Guard

Все время RAC сравнивали с Data Guard. Оба решения используются в том числе и для защиты от сбоя одного компьютера. Иногда пользователи считают, что могут и подождать активации Standby, не стоит платить денег за лицензии RAC. Даже аргумент, что после активации Standby требуется разогрев кеша БД, иногда не принимается в расчет. Пожалуй, основным аргументом в пользу RAC всегда было то, что машина, стоящая под Standby, не несет полезной нагрузки - т.е. простаивала.

И тут появляется опция Enterprise Edition Active Data Guard (ADG). Пожалуйста, открывайте на чтение Standby, в этот же момент продолжают накатываться изменения с primary. На семинаре DBOD я показывал, что в режиме Maximum Availbility задержка буквально несколько секунд. И теперь Вы можете запускать свои отчеты на Active Data Guard, Ваша Standby машина не простаивает !

Давайте рассмотрим в этой связи два вопроса - что нам делать с приложением, и сколько стоят лицензии Oracle в этих двух вариантах.

Про приложение

И для RAC и для ADG приложение должно быть разбито на сервисы. Вы конечно знаете, что сервисы, с одной стороны представляют собой логическую абстракцию общей нагрузки, с другой стороны сервисы заводятся в БД и OCR.

В конфигурации RAC сервисы используются для балансировки нагрузки, в ADG - с тем, чтобы поднять в триггере on startup database в зависимости от роли (primary, standby) либо RW сервисы, либо RO.

Про стоимость

RAC традиционно стоит 50% от стоимости Enterprise Edition. ADG значительно скромнее ~ 12%

Вместо заключения

Несомненно, ADG позволяет Вам масштабировать Ваше приложение. Но, только в том случае, если Ваша нагрузка RO составляет значимую часть от вашей общей нагрузки. Если нагрузка RO увеличится...Вы конечно можете поставить еще один Standby, но тут придется заплатить и за лицензии EE и за лицензии ADG. А если увеличится нагрузка RW ? Упс. Не очень гибко получается. К тому же, Вы же помните, что ADG это опция только EE. А что, если Ваш заказчик захочет приобрести Standart Edition (SE) ? На SE нет Data Guard. Т.е. Вы можете создать standby но логи Вам придется передавать вручную. И тут, (surprise, surprise !) хочется вспомнить, что RAC для Standart Edition - бесплатен. По моим представлениям, из-за этого, стоит сейчас весь код сразу разрабатывать с учетом особенностей RAC.

Тогда путь развития ИС заказчиков видится мне так:

• Поставлем Standart Edition. Хочется надежности - пожалуйста RAC. Пока лицензируется только SE.
• Не помещаемся в ограничения SE - Пожалуйста EE. Хочется надежности - лицензируем Standby
• Не хватает производительности - покупаем Active Data Guard.
• Опять не хватает - покупаем RAC.

Каждая инвестиция приносит значительное увеличение производительности. Но только ссли в системе сразу были заложены сервисы.

Более того, чтобы "научить" приложения отрабатывать потерю узла в RAC или primary в конфигурации с data guard нужно сделать одно и тоже. И тоже самое, для HA кластера. Напишу отдельно, как именно научить приложение отрабатывать потери текущего экземпляра.

Читать дальше...

Active Data Guard and TEMP tablespace

Вадим Гусев (Vadim.Gousev) задался целью выяснить, где происходят сортировки, когда мы переводим наш 11g Active Standby в состояние Read Only.

Как Вы конечно знаете, переведя БД в состояние Read Only мы можем запускать на ней отчеты, при этом продолжается применение redo. Таким образом наши отчеты видят актуальные данные (в зависимости от настроек с запозданием от нескольких секунд до 1 red log).

Во первых Вадим обнаружил, что TEMP datafile находится в состоянии READ WRITE

 SQL> select name, enabled from  v$tempfile
NAME                                    ENABLED
----------------------------------       ----------
/u01/app/oracle/oradata/stby/temp01.dbf  READ  WRITE

Далее, запустив достаточно большой запрос под пользователем sys, требующий сортировки он увидел, что

SQL> SELECT  s.username, u.tablespace, u.contents, u.extents, u.blocks
FROM v$session s,  v$sort_usage u
WHERE s.saddr=u.session_addr;
USERNAME           TABLESPACE              CONTENTS     EXTENTS     BLOCKS
------------------- -----------------------  -------     ---------  ----------
SYS                 TEMP                    TEMPORARARY     6        768

И наконец, включив трассировку он уидел событие ожидания direct path wite temp

grep -i direct  /u01/app/oracle/diag/rdbms/stby/stby/trace/stby_ora_5896_10046.trc
WAIT #1:  nam='direct path write temp' ela= 49 file number=201 first dba=434953 block  cnt=15 obj#=18 tim=1229005511408393
WAIT #1: nam='direct path write temp'  ela= 4 file number=201 first dba=434968 block cnt=15 obj#=18  tim=1229005511425026
WAIT #1: nam='direct path write temp' ela= 6 file  number=201 first dba=434998 block cnt=15 obj#=18 tim=1229005511437579
WAIT  #1: nam='direct path write temp' ela= 3 file number=201 first dba=435013 block  cnt=15 obj#=18 tim=1229005511452812

Сомнений, нет TEMP используется на WRITE, когда наша Standby открыта на Read Only.

Если Вы экспериментировали с active duplicate for Standby, Вы конечно обратили внимание, что TEMP не передается, а создается на стороне Standby. И наконец, если Вам для отчетов нужны временные таблицы, Вам придется создать dblink на как какую-то другую БД, например на собсвенную primary. Создать конечно же еще на primary, чтобы он переехал на Standby.

UPDATE 1.

По мотивам комментариев
Limitations of a Read-only Database
"When executing on a read-only database, you must commit or roll back any in-progress transaction that involves one database link before you use another database link. This is true even if you execute a generic SELECT statement on the first database link and the transaction is currently read-only."

Давайте создадим global temporary table на primary

SQL> conn scott/tiger@orcl
Connected.
SQL> create global temporary table  test_gtt(id number(4) primary key) on commit preserve rows; 
Table created.

Выполним аналитический запрос на standby и сохраним его на primary в GTT.

SQL> conn scott/tiger@stby
Connected.
SQL>  insert into test_gtt@db_orcl select empno  from emp;
 
 14 rows created.
SQL> commit;
 Commit complete.

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

SQL> select * from  test_gtt@db_orcl;
         ID
----------
      7369
      7499
      7521
      7566
      7654
      7698
      7782
      7788
      7839
      7844
      7876 
      7900
      7902
      7934

14 rows selected.  
SQL>

Читать дальше...

Redo Transport Compression for Data Guard ASYNC

Как Вы знаете, в 11g осуществляется компрессия redo при передаче на standby, но только во время преодоления отставания (gap resolution). Понятно, что хочется компрессировать redo при передаче и в нормальном режиме, чтобы не допустить этого самого отставания (gap)

Появилась замечательная Note:729551.1: Redo Transport Compression in a Data Guard Environment.


Для того, чтобы включить компрессию нужно установить атрибут в log_archive_dest_x

LOG_ARCHIVE_DEST_2='SERVICE=stdb ASYNC COMPRESSION=ENABLE DB_UNIQUE_NAME=stdb'

и установить параметр:
_REDO_TRANSPORT_COMPRESS_ALL=TRUE


Если используется Data Guard Broker то можно указать такой синтаксис
DGMGRL> EDIT DATABASE 'boston' SET PROPERTY 'RedoCompression' = ENABLE;

(параметр _REDO_TRANSPORT_COMPRESS_ALL должен быть установлен)


Хочу обратить Ваше внимание, что согласно ноте, это работает только для асинхронного режима
(asynchronous redo transport mode)

Также в ноте, есть любопытное замечание - что указание атрибута MAX_CONNECTIONS не дает преимуществ после включения компрессии при передачи redo.


Конечно, включение режима компрессии может повлиять на производительность вашего приложения. Весьма интересный отчет, в котором были попытки измерить потери производительности, а также приводятся не менее интересные цифры по загрузке сети.

Читать дальше...

duplicate <..> for standby from active database

Я был совершенно уверен, что копирования БД через сеть идет в один поток. И был совершенно не прав. Так бывает, что запоминаешь информацию, и забываешь откуда ее услышал :(

Наш эксперт HA Вадим Гусев (Vadim.Gousev) убедительно показал мне, что это не так.
Действительно, после команды

rman target / auxiliary sys/oracle@stdb.ru.oracle.com

появляется одно соединение, а после выполнения

configure device type disk parallelism 2;
run {
duplicate target database for standby from active database;
}

их открывается 2. За сетевыми соединениями я следил с помощью команды

lsof -i | grep oracle | grep stdb

На standby появляются 2 сессии ожидающие передачи по сети.

select MACHINE, sid, serial#, WAIT_CLASS, WAIT_TIME from v$session;

dbsrv 139 4 Network 0
dbsrv 140 3 Network 0


Вот и строй после этого людям стенды. А они тебя еще и научат за это :))))))))))))))))))

Читать дальше...

Oracle tech Day Minsk (cluster reconfiguration)

Во время Oracle Tech Day в Минске я выступал с презентацией "Архитектура максимальной доступности" и показывал мультфильм, демонстрирующий балансировку нагрузки и поведение кластера во время неожиданной перегрузки одного из узлов (прочитать про все мультфильмы).

Во время демонстрации фильма, кто-то из зала, воспользовавшись темнотой :), задал коварный вопрос - "а почему падает в 0 кол-во транзакций ? " и я пытался объяснить этот факт не вдаваясь в архитектуру, что оказалось очень не просто. Сейчас я восполню этот пробел, насколько я смогу. Во первых детально различные сбои в кластере и необходимые настройки, чтобы уменьшить продолжительность сбоев собраны в замечательной whitepaper (внимание, она про 10g у меня в мультфильмах 11g)
Для удобства я привожу картинку оттуда: действительно на какое-то время транзакции в системе останавливаются. Но, это время ~ 2 сек.

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


1) Clusterware обнаруживает, что узел перестает голосовать в voting диске и (скорее всего) хочет выбросить этот узел из кластера, но сети тоже нет. Скорее это происходит быстро, несколько секунд.

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

3)Далее необходимо выполнить переконфигурацию ASM. Опрации ввода-вывода замедляются.

4)Далее идет переконфигурация экземпляров для переделки "прав собственности" владельцев объектов в глобальном кеше.

Я думаю на этапе 3-4 транзакции в кластере прекращаются полностью.

5) Далее выполняется оставшиеся узлы кластера выполняют instance recovery

6) Число транзакций в системе нарастает, но если транзакциии встречается блок, который необходимо восстановить - он восстанавливается, только потом транзакция продолжается.

7) Все блоки восстановлены - достигнут максимальный уровень производительности.

Для увлекающихся могу порекомендовать еще вот эту ссылку:
Oracle RAC: Cluster reconfiguration steps
К сожалению сама книга в бумажном варианте мне сейчас недоступна, как только я ее получу возможно что-то и изменю в тексте выше.


Давайте обсудим результат: ~2 сек простоя системы. Как видно из рисунка слева - это четыре 9 ! Давайте решим что у нас 4 узла, что каждый из них раз в год перегрузиться неожиданно - все равно укладываемся.

Попробуйте найти у вендоров оборудование, которое сертифицировано по такому же классу (9999) - есть, на надо еще поискать и посмотреть на его стоимость.

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

Итого, при соответсвующем оборудовании мы может строить на Oracle RAC системы с уровнем доступности четыре 9999. Сравните это с HA решением (cold failover) - там с трудом можно попасть в две 9.

Читать дальше...