Как пересоздать online redo log files Oracle

Не так давно в моём рассказе про опыт миграции одной SAP системы я упоминал о ситуации, когда онлайн журнальные файлы (redo log files) Oracle оказались узким местом при импорте данных. Решением стало пересоздание данных файлов намного большего размера. Давайте поговорим об этом более детально.

Про журнальные файлы Oracle я рассказывал в этом посте. Существует два вида данных журналов - онлайн и оффлайн. Вторые являются копией первых при активации режима работы базы данных - ARCHIVELOG MODE. Именно про этот режим в большей степени был мой прошлый пост. Сегодняшний же рассказ про первый вид - online redo log files.

Посмотреть список онлайн журналов, их размер и расположение можно тремя способами:

1. Запустить в транзакции DB13 задание Check Database и просмотреть журнал выполнения (рис. 1).
     
2. В утилите BR*Tools перейти по меню "2 - Space management -> 7 - Additional space functions -> 3 - Show redolog files -> cont, cont, cont" (рис. 2).
     
3. В утилите SQLPlus выполнить 2 SQL-запроса:
   col MEMBER format a38; 
   SELECT v$logfile.group#, v$logfile.member, v$log.bytes/1024/1024 as FS_SIZE,  v$log.status
   FROM v$logfile
   LEFT JOIN v$log ON v$logfile.group#=v$log.group#
   ORDER  BY v$logfile.group#, v$logfile.member; 
   
   
   Первый запрос изменяет формат экрана для удобного просмотра результатов работы второго. А второй собирает информацию из двух системных представлений (Oracle Views) V$LOGFILE и V$LOG. Результатом будет список онлайн журналов с размером и статусом (рис. 3).

Рис. 1. Просмотр информации об онлайн журналах в DB13.

Рис. 2. Просмотр информации об онлайн журналах в BR*Tools.

Рис. 3. Просмотр информации об онлайн журналах в SQLPlus

Как видно из снимков экранов в данном случае в системе 4 группы онлайн журнальных файлов, в каждой группе по 2 копии файлов, а размер каждого файла 200 Мб. Данные журналы используются по кругу, предыдущая информация каждый раз перезаписывается. В текущий момент времени запись может производиться только в одну группу. На снимках экранов это четвёртая группа файлов, она имеет статус CURRENT. Те журнальные файлы, записи в которых уже были внесены в дата-файлы, имеют статус INACTIVE. То есть система помечает, что их можно перезаписать. И существует еще статус ACTIVE, когда указатель переключился на следующий журнал, но перезаписывать журнал ещё нельзя. Так как СУБД ещё не зафиксировала данные изменения в дата-файлах.

Задача пересоздания онлайн журналов может возникнуть по разным причинам. Например, для решения проблемы с производительностью, когда в системном журнале Oracle наблюдаются ошибки вида 'Chekpoint not complete' (SAP note 79341 - Checkpoint not complete) и рекомендуется увеличить размер журнальных файлов. Или как в моей истории при импорте большого объёма данных в систему. Иногда бывает необходимо перенести файлы журналов в другое место, изменить состав групп или решить другие  подобные административные задачи. 

Пересоздать отдельную группу онлайн журнальных файлов можно на живую, при работающей системе. Единственное условие - группа не должна использоваться, то есть должна находиться в статусе INACTIVE. Для выполнения операции придётся использовать SQLPlus. В BR*Tools такой функциональности не предусмотрено. Ну и, как вы поймёте из описания процедуры, необходимо выбрать период с минимальной нагрузкой на систему. Нам необходимо чтобы во время проведения операции переключение между группами журналов происходило как можно реже. 

Итак, перейдём к процедуре и инструментарию (набору SQL-запросов и команд). Для примера увеличим размер online redo log files до 250 Мб.

1. В терминале операционной системы переключаемся в пользователя <ora>sid. Входим в SQLPlus и открываем подключение к базе данных командами:
   sqlplus /nolog 
   connect /as sysdba 
     
2. Для начала необходимо просмотреть информацию о текущем состоянии онлайн журнальных файлов, выполнив 2 SQL-запроса из списка выше (пункт 3) (рис. 4).
   
   

   

   Рис. 4. Процесс пересоздания онлайн журнальных файлов - 1.

     
3. После этого выбираем первую неактивную группу онлайн журнальных файлов для удаления. В данном случае это группа 1 (G11). Удаление группы производится SQL-запросом вида:
   ALTER DATABASE DROP LOGFILE GROUP 1; 
   
   
   После выполнения в списке журнальных файлов данной группы быть не должно (рис. 5).
   
   

   

   Рис. 5. Процесс пересоздания онлайн журнальных файлов - 2.

     
4. Открыть еще один терминал операционной системы и в нём удалить файлы только что удалённой группы онлайн журналов. Для этого использовать команды вида:
   rm /oracle/EI8/origlogA/log_g11m1.dbf 
   rm /oracle/EI8/mirrlogA/log_g11m2.dbf 
   
   
   Для удаления файлов необходимо иметь достаточные полномочия: суперпользователя root, пользователя <ora>sid (Oracle до версии 11g) либо пользователя oracle (при использовании базы данных Oracle 12c и выше) (рис. 6).
     

   

   Рис. 6. Процесс пересоздания онлайн журнальных файлов - 3.

     
5. Вернуться в терминал с SQLPlus и создать удалённую группу онлайн журнальных файлов Oracle заново SQL-запросом вида:
   ALTER DATABASE ADD LOGFILE GROUP 1 
   ('/oracle/EI8/origlogA/log_g11m1.dbf', 
   '/oracle/EI8/mirrlogA/log_g11m2.dbf') 
   SIZE 250M; 
   
   
   После этого данная группа должна появиться в списке. Статус UNUSED означает что база данных эти журналы еще ни разу не использовала (рис. 7).
      

   

   Рис. 7. Процесс пересоздания онлайн журнальных файлов - 4.

   
   Если необходимо создать группу онлайн журнальных файлов с одним файлом, без зеркалирования, то в SQL-запросе в скобках указываем только один файл.
     
6. Повторить шаги, описанные в пунктах 3-5, для следующих групп онлайн журнальных файлов имеющих статус INACTIVE.
      
7. Для того, чтобы выполнить операцию удаления и создания для группы, файлы которой находятся в статусе ACTIVE или CURRENT, можно выбрать 2 способа. В первом случае просто подождать. Рано или поздно система заполнит текущий журнальный файл и переключится на следующий.
   Во втором же случае можно выполнить следующие SQL-запросы:
   

   ALTER SYSTEM SWITCH LOGFILE; 

   ALTER SYSTEM CHECKPOINT; 
   
   Первый запрос принудительно переключает текущий журнал Oracle на следующий, а второй инициирует принудительное выполнение контрольной точки базы данных (Checkpoint). В этом случае все записи из журнала фиксируются в дата-файлах и журнал освобождается (рис. 8).
     
   

   

   Рис. 8. Пример переключения текущего журнального файла.

        
8. В итоге после пересоздания всех групп журнальных файлов у вас должна получиться требуемая вам картина (рис. 9).  

Рис. 9. Онлайн журнальные файлы после пересоздания.

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

На данную тему существует SAP note 309526 - Enlarging redo log files.
Как факультатив ещё можно прочитать SAP note 1627481 - Preemptive redolog switches in Oracle 11.2 and higher.

Автор: Шиболов Вячеслав Анатольевич

Default Temporary Tablespace PSAPTEMP

Начиная с версии SAP_BASIS 6.40 и базы данных Oracle 9i, рекомендуется в качестве табличного пространства по-умолчанию (Default Temporary Tablespace) использовать специальное табличное пространство PSAPTEMP. В предыдущих версиях SAP/Oracle использовалось табличное пространство SYSTEM.

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

Утилита BRTools, начиная с версии 6.40, проверяет какое табличное пространство установлено в качестве Default Temporary Tablespace. Если это SYSTEM, то выдается сообщение об ошибке. Например, в отчете CheckDB в транзакции DB13 (рис. 1).

Рис. 1. Ошибка в отчете CheckDB.

На уровне SQLPlus проверить значение Default Temporary Tablespace можно следующим SQL-запросом (рис. 2 и 3).

Рис. 2.  Табличное пространство PSAPTEMP в качестве Default Temporary Tablespace.

Рис. 3. Табличное пространство SYSTEM в качестве Default Temporary Tablespace.

Если система выдает ошибку (рис. 1) и проверка на уровне SQLPlus показывает, что это так и есть (рис. 3), то необходимо переназначить значение Default Temporary Tablespace согласно рекомендациям SAP следующей SQL-командой (рис. 4).

Рис. 4. Изменение значения Default Temporary Tablespace на PSAPTEMP.

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

Рис. 5. Проверка, что для всех пользователей базы данных установлена PSAPTEMP.

Подробности в SAP note # 683075 - Oracle9i: Default Temporary Tablespace. Там же описано, как создать временное табличное пространство PSAPTEMP, если его нет.

Автор: Шиболов Вячеслав Анатольевич

Останов во время online ORACLE backup

Как вы знаете, мы можем делать резервную копию базы данных ORACLE с остановом работы пользователей (оффлайн резервная копия, холодный бэкап БД) и без останова (онлайн резервная копия, горячий бэкапа БД). Я про это упоминал в этом посте.

Напомню, что когда мы выполняем онлайн резервную копию, то процесс резервного копирования производит с табличными пространствами БД следующие операции:

1. Табличное пространство переводится в специальный режим BEGIN BACKUP.
2. Производится копирование дата-файлов табличного пространства.
3. Табличное пространство переводится в нормальный режим работы (END BACKUP).

Когда табличное пространство находится в режиме BEGIN BACKUP, ORACLE как бы "замораживает" его дата-файлы (не изменяет SCN и не записывает изменения), выполняя для пользовательских процессов только чтение из дата-файлов. Запись идет в буфер и журнальные файлы.

То есть, во время выполнения онлайн бэкапа дата-файлы базы данных имеют разные SCN - те которые в данный момент находятся в режиме BEGIN BACKUP, имеют более старый SCN, чем база данных (контрольные файлы и остальные дата-файлы).

И если в процессе бэкапа произойдет останов базы данных (в случае сбоя или вынужденной корректной остановки), то при попытке старта и открытия базы данных мы получим следующую ошибку:

ORA-1113 signalled during: alter database open

Эта ошибка означает, что часть дата-файлов находится в режиме BEGIN BACKUP, имеет более низкий номер SCN, чем вся БД и, в данном случае, без восстановления, база данных не может быть открыта. То есть база данных поднимается только до уровня MOUNT.

Решение в данной ситуации следующее:

1. Войти в SQLPLUS, поднять (если еще не поднята) базу до уровня MOUNT:
   > sqlplus /nolog 
   SQL> connect /as sysdba 
   SQL> startup mount 
2. Определить какие дата-файлы находятся в режиме BEGIN BACKUP. Для этого получить из ORACLE view V$BACKUP команды возврата в нормальный режим, которые ORACLE не успел сделать из-за вынужденной остановки:
   SQL> select 'ALTER DATABASE DATAFILE '''||name||''' END BACKUP;' 
     2  from v$backup b, v$datafile f 
     3  where b.file#=f.file# 
     4  and b.status='ACTIVE'; 
3. Выполнить команды вида
   SQL> ALTER DATABASE DATAFILE '''||name||''' END BACKUP; 
   для всех дата-файлов, которые выдаст команда из пункта 2.
4. Открыть базу данных командой:
   SQL> ALTER DATABASE OPEN; 

 И не забудьте удалить файл блокировки процесса BRBACKUP.


Автор: Шиболов Вячеслав Анатольевич

Журнальные файлы Oracle и archivelog mode. Часть II.

В первой части поста я остановился на онлайн журнальных файлах. Продолжим.

Онлайн журнальные файлы используются по кругу (рис. 1).

Рис. 1. Запись в онлайн журнальные файлы ORACLE.

После того, как полностью заполнен онлайн журнал группы G11, начинается запись в журнал группы G12 и так далее, пока не дойдет до группы G14. После использования последней группы, процесс записи должен переключиться на первый журнал и начать запись в него. И тут есть 2 варианта. Дело в том, что экземпляр ORACLE может работать в двух режимах:

• ARCHIVELOG MODE,
• NOARCHIVELOG MODE,

Журнальные файлы Oracle и archivelog mode. Часть I.

В структуре базы данных ORACLE, которая представлена на рисунке 1, можно выделить 3 крупные части:

• процессы,
• области в оперативной памяти,
• файлы на жестком диске.

Рис.1 Структура СУБД ORACLE.

Выделяют 2 вида процессов. Первый - это фоновые процессы, которые запускаются всегда при запуске экземпляра (инстанции) и выполняют огромное количество операций по обслуживанию базы данных, очистки, журналированию, восстановлению и так далее. Второй тип - это, так называемые, "shadow processes", которые создаются в количестве равном количеству рабочих процессов SAP инстанций, работающих с этим экземпляром базы данных. Они-то и обрабатывают SQL запросы к базе данных со стороны SAP системы.
Также еще есть, отдельно стоящий, процесс сетевого слушателя (ORACLE Listener), который "слушает" определенный сетевой порт (в случае SAP системы, по умолчанию это 1527) и обеспечивает соединение к экземпляру базы данных извне.

Области в оперативной памяти являются буферами того или иного назначения и обеспечивают приемлемый уровень быстродействия при работе с базой данных.

Ну и наконец, файлы базы данных. Это прежде всего профиль - файл, который используется для инициализации экземпляра базы данных при запуске. Содержит набор параметров и указатели на важные директории базы данных. Хранится и имеет название:
/oracle/<SID>/<ora_version>/database/SPFILE<SID>.ORA.
Контрольный файл базы данных, который содержит структуру базы данных. Очень важен для целостности экземпляра, поэтому хранится в 3 экземплярах. Одну копию можно обнаружить тут - /oracle/<SID>/origlogA/cntrl/CNTRL<SID>.DBF.
Самый большой объем занимают файлы с данными, которые логично распределены между табличными пространствами экземпляра. По-умолчанию, расположены в директориях вида /oracle/<SID>/sapdataX.
Журнальные файлы ORACLE делятся на онлайн и оффлайн. Остановимся на них подробнее.

В журнальные файлы ORACLE записывает все операции, которые производятся с файлами данных. Таким образом, если произойдет сбой, то ORACLE при восстановлении экземпляра сможет повторить все операции с данными в той же последовательности, как это происходило во времени до сбоя. Данные файлы очень важны для работы базы данных, поэтому за ними нужен "глаз да глаз".

По-умолчанию, при создании экземпляра базы данных для SAP системы организуется 4 группы журнальных файлов размером по 50 Мб с дублированием (зеркалированием) каждого. Онлайн журнальные файлы распределены по 4 директориям:

/oracle/<SID>/origlogA/
             LOG_G11M1.DBF
             LOG_G13M1.DBF
/oracle/<SID>/origlogB/
             LOG_G12M1.DBF
             LOG_G14M1.DBF
/oracle/<SID>/mirrlogA/
             LOG_G11M2.DBF
             LOG_G13M2.DBF
/oracle/<SID>/mirrlogB/
             LOG_G12M2.DBF
             LOG_G14M2.DBF

Здесь видно 4 группы G11, G12, G13, G14 с двумя копиями M1 и M2 в каждой.
Данные директории рекомендуется распределять по разным файловым системам с RAID1 или RAID1+0  для приемлемого уровня отказоустойчивости и быстродействия.

Продолжение тут.

Автор: Шиболов Вячеслав Анатольевич

ORACLE. Перенос дата-файлов.

Если Ваша система работает, используя в качестве хранилища базу данных ORACLE, то у Вас может возникнуть потребность в переносе одного или нескольких дата-файлов из одной файловой системы в другую. Делается это следующим образом:

1. Создаем резервную копию базы данных. Например, средствами SAP (brbackup, DB13).
   
2. Останавливаем сервер приложений SAP, базу данных ORACLE.
3. Переносим дата-файлы на уровне ОС из исходной файловой системы в целевую. Если в качестве ОС у Вас Unix-подобная система, то будьте внимательны с правами/полномочиями на дата-файлы.
4. Запускаем sqlplus, подключаемся к СУБД и открываем базу данных ORACLE в mount-режиме:
   # sqlplus /nolog
   SQL> connect /as sysdba
   SQL> startup mount
5. Выполняем следующую команду в SQLPlus для каждого перенесенного дата-файла:
   SQL> ALTER DATABASE RENAME FILE 'полный исходный путь до дата-файла' TO 'полный целевой путь до дата-файла';
6. Закрываем базу данных и открываем в нормальном режиме:
   SQL> shutdown
   SQL> startup open
7. Запускаем сервер приложений SAP.

После этого, если все нормально запустилось, и в транзакции DB02 вы проверили, что база данных ссылается на дата-файлы, лежащие в новой файловой системе, то дата-файлы из исходной файловой системы на уровне ОС можно удалить. Постарайтесь в ближайшее время сделать полную резервную копию базы данных, особенно, если вы удалили старую файловую систему целиком.
Таким же образом, можно переименовать дата-файл, например, если при его создании, вы ошиблись в имени файла или имени директории.

Автор: Шиболов Вячеслав Анатольевич

Как попасть туда, куда не пускают

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

Для выхода из таких ситуаций SAP придумал пользователя 'SAP*' (sapstar). Итак, последовательность взлома системы:

1. Если у Вас есть доступ в один из мандантов, входите в него и через RZ11 проверяете значение параметра инстанции login/no_automatic_user_sapstar. Значение по умолчанию для версий системы до NetWeaver 7.0 - 0, а начиная с этой версии - 1. Для нашего плана необходимо выставить в 0. Поэтому, если Вы в системе, то через RZ10 в профиле инстанции выставляете этот параметр в 0. А если доступа в систему нет, то на уровне OS текстовым редактором в профиле инстанции меняем значение параметра. После этого перезагружаем SAP-инстанцию.
2. Если знаете пароль пользователя system для ORACLE, то входите в ORACLE удаленно. А если не знаете, то подключаетесь локально через SQLPlus (sqlplus /nolog; connect /as sysdba). Далее даём команду

   select * from <DBSchemaOwner>.USR02 where BNAME='SAP*';

   DBSchemaOwner-а можно посмотреть через меню "Система -> Статус". Для 4.6С это обычно SAPR3, начиная с 4.7 - SAP<SID>. В результатах работы запроса можно увидеть в каких мандантах системы есть пользователь SAP*.
   
3. Теперь SQL-запросом необходимо удалить пользователя из нужного манданта:

   delete * from <DBSchemaOwner>.USR02 where BNAME='SAP*' AND MANDT='<number>';

   Можно удалить пользователя SAP* из всех мандантов одним SQL-запросом, тогда просто не указываете MANDT в условии where.
4. Теперь в мандант системы можно войти виртуальным пользователем SAP* с паролем PASS. Из под этого пользователя можно создать своего и работать.
5. Для закрытия 'дыры' необходимо выставить параметр инстанции login/no_automatic_user_sapstar в 1, перезагрузить инстанцию и создать пользователя SAP* со своим паролем.
   

Автор: Шиболов Вячеслав Анатольевич