как да проверите дали базата данни е последователна след непълно възстановяване

Можете да възстановите база данни от архива и да приложите много архиви, за да я направите последователна. Сега искате да се уверите, че отворените регистрационни файлове за нулиране вървят добре.
Ето как да проверите дали базата данни е последователна след непълно възстановяване

Изявлението по-долу задава формата на датата на разширен формуляр, тъй като бихме изисквали това много пъти в нашия анализ

SQL> промяна на набора от сесии nls_date_format='DD-MON-YYYY HH24:MI:SS';

Проверка 1:

Цел:Проверете дали файловете с данни са възстановени до предвидения момент от време (PIT) и че са последователни (FUZZY=NO)
Запитване за текущото състояние и PIT (P-oint I-n T-ime, до който са били файловете с данни възстановено) на файлове с данни чрез четене на заглавки на файлове с данни директно от физическите файлове с данни:

SQL> изберете fuzzy, status, error, recover, checkpoint_change#, checkpoint_time, count(*) от v$datafile_header група по fuzzy, status, error, recover, checkpoint_change#, checkpoint_time;

Уверете се, че checkpoint_time / checkpoint_change# е в съответствие с планираното от вас ДО ВРЕМЕ/SCN. Ако не, възстановете базата данни допълнително, ако имате още налични архивирани регистрационни файлове.
Ако FUZZY=ДА за някои файлове с данни, това означава, че е необходимо повече възстановяване. Ако няма налични повече архивирани регистрационни файлове, идентифицирайте такива файлове с данни и определете дали можем да ги изведем офлайн, защото ще загубим данните в тези файлове с данни. Ако файловете с данни принадлежат на SYSTEM или UNDO таблично пространство, ние можем/не трябва да превеждаме такъв файл с данни офлайн без подходящ анализ. Моля, консултирайте се с поддръжката на Oracle за по-нататъшни действия.

SQL> изберете file#, substr(name, 1, 50), substr(tablespace_name, 1, 15), undo_opt_current_change# от v$datafile_header, където fuzzy='YES';

Понякога, ако името на табличното пространство не показва, че е UNDO пространство за таблици, ако видим стойност, различна от нула в колона UNDO_OPT_CURRENT_CHANGE#, това показва, че файлът с данни съдържа сегменти за отмяна.

За да пренесете файл с данни офлайн:

SQL> променя офлайн файла с данни на базата данни;

Проверка 1 може да се счита за изпълнена, когато:
+ Потвърдено, че всички файлове с данни са възстановени до предвидения момент във времето.
+ Fuzzy=NO за СИСТЕМА, ОТМЕНИ и всички предвидени файлове с данни. За файлове с данни с Fuzzy=YES, или ги възстановете допълнително, или ги пренесете ОФЛАЙН, ако няма налични други архивирани регистрационни файлове.

Проверка 2:

Цел:Проверете дали файловете със status=RECOVER не са OFFLINE неволно

SQL> изберете състояние, активирано, count(*) от v$datafile група по състояние, активирано;STATUS  АКТИВИРАН      COUNT(*)------- ---------- --- -------СИСТЕМАТА  ИЗКЛЮЧЕНА             1ОНЛАЙН  ПРОЧЕТЕТЕ ПИШЕ           1114 ВЪЗСТАНОВЯВАНЕ ИЗКЛЮЧЕНО            2

Ако файловете са в състояние ВЪЗСТАНОВЯВАНЕ, проверете дали са ОФЛАЙН :

SQL> изберете файл#, substr(име, 1, 50), състояние, грешка, възстановяване от v$datafile_header;

Ако искате данните за тези файлове да са достъпни, тогава ги донесете ОНЛАЙН :

SQL> промяна на файла с данни ОНЛАЙН;

Ако файлът остане офлайн по време на OPEN RESETLOGS, файлът с данни не може да бъде върнат онлайн отново в същата ОТВОРЕНА база данни.
Проверка 2 може да се счита за изпълнена, когато:
a) Всички планирани файлове с данни са не е ОФЛАЙН

Проверка 3:

Цел:Допълнителна размита проверка (Абсолютна размита проверка)

Понякога е възможно да видите Fuzzy=NO и същата checkpoint_change# за всички предвидени файлове с данни; все пак някои от файловете с данни може да са размити и OPEN RESETLOGS ще върне грешка, напр.

SQL> изберете fuzzy, status, error, recover, checkpoint_change#, checkpoint_time, count(*) от v$datafile_header група по fuzzy, status, error, recover, checkpoint_change#, checkpoint_time;FUZ STATUS ERROR REC CHECKPOINT CHECKPOINT CHECKPOINT CH (*)--- ------- --------------- --- ------------------ - ------------------- ----------НЕ ОНЛАЙН 5375858580 31 октомври 2011 г. 23:10:14 ORA EN 7SQL> ПРОМЕНИ БАЗА ДАННИ 7SQL> ПРОМЕНИ БАЗА ДАННИ; -01194:файл 14 се нуждае от повече възстановяване, за да бъде последователен ORA-01110:файл с данни 3:'/u01/app/oracle/oradata/TEST/undotbs02.dbf' Следователно трябва да извършим допълнителна размита проверка, известна като Абсолютна размита проверка:

SQL> изберете hxfil file#, substr(hxfnm, 1, 50) име, fhscn checkpoint_change#, fhafs Absolute_Fuzzy_SCN, max(fhafs) над () Min_PIT_SCN от x$kcvfh, където fhafs!=0;

Забележка:Колона Min_PIT_SCN ще върне същата стойност дори за множество редове, тъй като сме приложили АНАЛИТИЧНА функция „MAX() OVER ()“ върху нея.

Горната заявка показва, че възстановяването трябва да се извърши най-малко ДО SCN 5311524, за да се направят файловете с данни последователни и готови за ОТВАРЯНЕ. Тъй като checkpoint_change# е по-малък от Min_PIT_SCN, файловете с данни ще поискат още възстановяване.

Проверка 3 може да се счита за изпълнена, когато,
a) Няма избрани редове от горната заявка (т.е. Min_PIT_SCN е 0 (нула) за всички файлове с данни)
b) Min_PIT_SCN се връща по-малко от Checkpoint_Change#

Проверка 4:Изисква се архивиране на регистрационни файлове

Потърсете контролния файл, за да намерите най-новия архивен журнал, необходим за възстановяване. Да кажем, че архивирането е завършено на 31 август 2011 г. 23:20:14:

SQL> ALTER SESSION SET NLS_DATE_FORMAT='DD-MON-RR HH24:MI:SS';
SQL> ИЗБЕРЕТЕ THREAD#, SEQUENCE#, FIRST_TIME, NEXT_TIME ОТ V$ARCHIVED_LOG
КЪДЕ '31 -11 август 23:20:14' МЕЖДУ ПЪРВО_ВРЕМЕ И СЛЕДВАЩО_ВРЕМЕ;

Ако горната заявка не върне редове, възможно е информацията да е остаряла извън контролния файл – изпълнете следната заявка срещу v$log_history.

SQL> ALTER SESSION SET NLS_DATE_FORMAT='DD-MON-RR HH24:MI:SS';
SQL> изберете a.THREAD#, a.SEQUENCE#, a.FIRST_TIME
от V$ LOG_HISTORY a
където FIRST_TIME =
( SELECT MAX(b.FIRST_TIME)
ОТ V$LOG_HISTORY b
WHERE b.FIRST_TIME 
Последователността#, върната от горната заявка, е текущата регистрационна последователност към момента, в който архивирането е приключило - да кажем 530 нишка 1.

За минимално използване на възстановяване:(Последователност № като върната +1 )

RMAN> RUN
{
ЗАДАДЕТЕ ДО ПОСЛЕДОВАТЕЛНОСТ 531 НИШКА 1;
ВЪЗСТАНОВЯВАНЕ НА БАЗА ДАННИ;
}

Ако това е реализация на RAC, използвайте този SQL вместо това, за да потърсите контролния файл:

SQL> ИЗБЕРЕТЕ THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# ОТ V$ARCHIVED_LOG КЪДЕТО '31-AUG-11 23:20:14' МЕЖДУ ПЪРВИ_ВРЕМЕ И СЛЕДВАЩО_ВРЕМЕ;

За минимално възстановяване използвайте последователността на журнала и нишката, които имат най-ниския NEXT_CHANGE#, върнат от горната заявка.

Проверка 4 може да се счита за ПРИХОДЕН, когато:

Всички архивни регистри от момента на архивирането до края на архивирането са достъпни за използване по време на възстановяване

Проверка 5 (След успешно ОТВАРЯНЕ НА RESETLOGS) :

Наблюдавайте alert.log за времето на дейностите OPEN RESETLOGS. Може да видите някои съобщения като по-долу по време на проверка на речника:

Създаване на ОФЛАЙН файл „MISSING00004“ в контролния файл

ако намерите файла, опитайте да ги преименувате. Ако не, можем да офлайн файла с данни или да пуснем свързаното пространство за таблици:

SQL> изберете файл №, състояние, активиран, substr(name, 1, 50) от v$datafile, където име като '%MISSING%';FILE#    СТАТУС  АКТИВИРАН    SUBSTR(NAME,1,50)---- ---- ------- ---------------- ------------------------------------- ---------------------       4 OFFLINE DISABLED   /<път>/MISSING000       7 OFFLINE DISABLED   /<път>/MISSING000SQL> променяне на файла с данни 4 онлайн;промяна на файла с данни на базата данни 4 онлайн*ГРЕШКА на ред 1:ORA-01157:не може да се идентифицира/заключи файл с данни 4 - виж DBWR файл за проследяване ORA-01111:името на файла с данни 4 е неизвестно - преименувай на правилния файл ORA-01110:файл с данни 4:'//dbs/MISSING00004'SQL> променете файла за преименуване на база данни 'MISSING00004' на '/<път>/users01.dbf';Променена база данни.SQL> променете файла за преименуване на база данни 'MISSING00007' на '/<пътя>/users'02;Променена база данни.SQL> изберете име_на_таблица, състояние от dba_tablespaces, където име_на_таблично_пространство е (изберете име_на_таблица_пространство от dba_data_files, където file_id в (4, 7));TABLESPACE_NAME                СТАТУС------------------ ---------- ---------ПОЛЗВАТЕЛИ                          OFFLINESQL> ПРОМЕНИ ПОТРЕБИТЕЛИТЕ НА ТАБЛИЧНОТО ПРОСТРАНСТВО ОНЛАЙН;Табличното пространство е променено.

Надяваме се, че това помага за това как да проверите дали базата данни е последователна след непълно възстановяване. Моля, предоставете обратната връзка

Също чете
как да намерите последователен номер на архивния дневник в oracle
команди за архивиране на RMAN
команди за архивиране на списък на RMAN
Как да възстановите база данни с помощта на RMAN