Ошибки ORA-600, ORA-752: гайд по поиску и устранению потерянных записей

Ошибки ORA-600, ORA-752 в Оракл
Андрей Васенин

Андрей Васенин

Автор статьи. Сфера интересов: ИТ-специалист (программирование, администрирование, DBA). Кандидат экономических наук. Подробнее .

Работая с базой данных 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$;

ПРИМЕЧАНИЕ: вы также можете включить теневую защиту от потери записи для табличного пространства или на  уровне файла данных.

 

 

Вас заинтересует / Intresting for you:

Oracle и непроцедурный доступ ...
Oracle и непроцедурный доступ ... 7486 просмотров Antoni Tue, 21 Nov 2017, 13:32:50
Язык SQL в Oracle
Язык SQL в Oracle 3375 просмотров Ирина Светлова Tue, 21 Nov 2017, 13:26:01
Listener Oracle
Listener Oracle 15591 просмотров Stas Belkov Tue, 21 Nov 2017, 13:18:05
NULL в ORACLE и как с ним можн...
NULL в ORACLE и как с ним можн... 6191 просмотров Андрей Васенин Wed, 01 Jul 2020, 08:11:51
Войдите чтобы комментировать