Работая с базой данных Oracle в режиме действующего Standby сервера, вы можете столкнуться с появлением ошибок ORA-600 [3020] и ORA-752. Что это такое и как с этим бороться? Об этом и поговорим в данной статье.
Что такое ПОТЕРЯННАЯ ЗАПИСЬ (LOST WRITE) в Oracle?
Потеря записи происходит, когда подсистема ввода-вывода подтверждает завершение блочной записи, даже если записи не выполнялись изначально. Другая ситуация - когда прежняя копия блока перезаписывает текущее его содержимое.
Признаки возникновения ошибки
Ошибка ORA-600 [3020] stuck recovery error могла произойти в Standby базе данных по нескольким причинам, включая ORA-752 на основном сервере.
ВАЖНОЕ ЗАМЕЧАНИЕ! НЕ восстанавливайте Standby сервер из резервной копии, взятой с основного сервера, так как это также приведет к повреждению Standby !
Возможные решения
Во-первых, немедленно откройте обращение в службу поддержки Oracle!
- Ошибка
ORA-752однозначно определяет потерю записи на Основном сервере. Рассмотрите возможность немедленного переключения на Standby, если целостность данных критична и возможны некоторые потери данных. - Просмотрите файл журнала предупреждений (alert log) для получения дополнительной информации (сделайте резервную копию файла журнала предупреждений на удаленное место).
- Просмотрите файлы трассировки, созданные с помощью представления:
SQL> select originating_timestamp, detailed_location,message_level, message_text, problem_key
from V$diag_alert_ext
where message_level=1 and message_text like’%ORA-00600%’
order by originating_timestamp desc;- Проверьте журналы ОС:
cd /var/log
ls -l message*- Сделайте несколько дампов для службы поддержки Oracle, чтобы помочь им разобраться в ситуации:
Дамп контрольных файлов (controlfiles):
SQL> alter session set events ‘immediate trace name controlf level xx’;Дамп заголовков файлов данных:
SQL> alter session set events ‘immediate trace name file_hdrs level 10’;Дамп заголовков журнала повторов:
SQL> alter session set events ‘immediate trace name redohdr level 10’;- В сообщении журнала предупреждений будет указан номер файла данных вместе с соответствующим номером блока (замените значения & file_number, & block_number на свои значения в запросе):
SQL> spool /exp/oraxx1/corrupted_file_info.txt
SQL> Select * from DBA_EXTENTS where FILE_ID=&file_number and &block_number BETWEEN BLOCK_ID and BLOCK_ID+BLOCKS-1;
SQL> spool off;
SQL> spool /exp/oraxx1/object_number.txt
SQL> Select * from DBA_OBJECTS where DATA_OBJECT_ID = &object_number;
SQL> spool off;- Если возможно, удалите и воссоздайте затронутые ошибкой объекты в Основной базе данных (проведите хороший анализ):
После воссоздания объектов используйте следующую процедуру, чтобы пропустить поврежденный блок в STANDBY базу:
Временно отключите защиту от потери записи в STANDBY:
SQL> ALTER SYSTEM SET DB_LOST_WRITE_PROTECT = NONE;Позвольте восстановлению продолжаться, несмотря на повреждение блоков, запустив команду RECOVER с предложением ALLOW n CORRUPTION, где n - количество допустимых поврежденных блоков:
SQL> alter database recover automatic standby database
allow 1 corruption;Как только журнал предупреждений покажет, что блоки помечены как поврежденные, перезапустите управляемое восстановление:
SQL> alter database recover cancel;
SQL> alter database recover managed standby database using current logfile disconnect;- Если затронутые объекты не могут быть воссозданы, активируйте резервную (стэндбай) базу данных. При активации STANDBY базы данных вы столкнетесь с потерей некоторых данных, но целостность данных будет обеспечена.
Выполните следующий оператор SQL в резервной базе данных, чтобы преобразовать ее в основную:
SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;Затем немедленно создайте резервную копию базы данных.
Обнаружение и защита от утерянных записей (LOST WRITES)
Установите параметр инициализации DB_LOST_WRITE_PROTECT в значение TYPICAL в первичной и стэндбай базах данных, если ваша база данных 18c, вы можете использовать новую функцию «shadow tablespace».
*** Настройка shadow tablespace:
убедитесь, что для параметра совместимости установлен в значение 18.0:
SQL> show parameter compatible
NAME TYPE VALUE
———————————— ———– ——————————
compatible string 18.0.0
SQL> create bigfile tablespace SHADOW datafile ‘/orad04/oradbp02/shadow.dbf’ size 120M AUTOEXTEND ON lost write protection;
SQL> select tablespace_name
from dba_tablespaces where CONTENTS=’LOST
WRITE PROTECTION’;
SQL> select tablespace_name, status,bigfile, contents, logging, allocation_type, encrypted, lost_write_protect, chunk_tablespace
from dba_tablespaces
where tablespace_name=’SHADOW’;
....
// для активации LOST WRITE PROTECTION:
SQL> alter database enable lost write protection;
// для отключения LOST WRITE PROTECTION:
SQL> ALTER DATABASE DISABLE LOST WRITE PROTECTION;
SQL> select * from new_lost_write_datafiles$;ПРИМЕЧАНИЕ: вы также можете включить теневую защиту от потери записи для табличного пространства или на уровне файла данных.
