Разработване на стратегия за аварийно възстановяване на база от данни управлявана от Oracle Database 10g Server
Изтегляне 0.55 Mb.
|
SQL> startup; --- след като съм изтрил файл с данни ще опитам да стартирам базата ORACLE instance started. Total System Global Area 612368384 bytes Fixed Size 1292036 bytes Variable Size 230689020 bytes Database Buffers 373293056 bytes Redo Buffers 7094272 bytes Database mounted. ORA-01157: cannot identify/lock data file 6 - see DBWR trace file ORA-01110: data file 6: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\MYDB\FCC_DATA_SMALL_01.DBF'
Сега ако погледнем alert лог-а на базата данни и съответният „trace“ файл генериран за грешката, ще видим че даденият файл липсва. Windows thread id: 6000, image: ORACLE.EXE (DBW0) *** SERVICE NAME:() 2008-08-08 16:21:38.365 *** SESSION ID:(167.1) 2008-08-08 16:21:38.365 ORA-01157: Message 1157 not found; No message file for product=RDBMS, facility=ORA; arguments: [6] ORA-01110: Message 1110 not found; No message file for product=RDBMS, facility=ORA; arguments: [6] [D:\ORACLE\PRODUCT\10.2.0\ORADATA\MYDB\FCC_DATA_SMALL_01.DBF] ORA-27041: Message 27041 not found; No message file for product=RDBMS, facility=ORA OSD-04002: unable to open file O/S-Error: (OS 2) The system cannot find the file specified. Съобщението за грешка ни казва, че файл № 6 не може да бъде намерен. Освен това както виждаме базата данни не е стартирана а е само в монтиран режим. Така , контролният файл, който е също така и „склад” на RMAN, може да бъде достъпен от инстанцията и от RMAN. Сега ще възстановим липсващият файл използвайки RMAN.
Recovery Manager: Release 10.2.0.3.0 - Production on ╧Є └ту. 8 16:49:00 2008 Copyright (c) 1982, 2005, Oracle. All rights reserved. connected to target database: MYDB (DBID=2560810083, not open) RMAN> restore datafile 6; Starting restore at 2008-08-08 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=156 devtype=DISK allocated channel: ORA_DISK_2 channel ORA_DISK_2: sid=155 devtype=DISK channel ORA_DISK_1: starting datafile backupset restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set restoring datafile 00006 to D:\ORACLE\PRODUCT\10.2.0\ORADATA\MYDB\FCC_DATA_SMALL_01.DBF channel ORA_DISK_1: reading from backup piece D:\TEMP\DATA_L0_AHJNHHNM_1_1 channel ORA_DISK_1: restored backup piece 1 piece handle=D:\TEMP\DATA_L0_AHJNHHNM_1_1 tag=LEVEL0 channel ORA_DISK_1: restore complete, elapsed time: 00:02:06 Finished restore at 2008-08-08
Starting recover at 2008-08-08 using channel ORA_DISK_1 using channel ORA_DISK_2 starting media recovery media recovery complete, elapsed time: 00:00:03 Finished recover at 2008-08-08
database opened RMAN> И така, базата е възстановена и отворена за работа. Ако базата е била отворена до момент на откриване на развален (corrupted) файл с данни, то файла може да се поправи с няколко стъпки без да се спира базата. Единствената допълнителна стъпка , която трябва да се направи е да се постави съответното таблично пространство (в което е файла с данни) в offline режим преди да се започне поправката му. C:\> rman target / Recovery Manager: Release 10.2.0.3.0 - Production on ╧Є ╤хя. 19 17:39:42 2008 Copyright (c) 1982, 2005, Oracle. All rights reserved. connected to target database: MYDB (DBID=2560810083) RMAN> sql 'alter tablespace USERS offline immediate'; using target database control file instead of recovery catalog sql statement: alter tablespace USERS offline immediate RMAN> recover tablespace USERS; Starting recover at 2008-09-19 allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=133 devtype=DISK allocated channel: ORA_DISK_2 channel ORA_DISK_2: sid=131 devtype=DISK starting media recovery media recovery complete, elapsed time: 00:00:03 Finished recover at 2008-09-19 RMAN> sql 'alter tablespace USERS online'; sql statement: alter tablespace USERS online RMAN> Случай Б. Възстановяване във случай на „block corruption” С помощта на RMAN може да се извърши и възстановяване на повредени блокове с данни. Това е един екзотичен сценарий, но може в дадени моменти да бъде много полезен при определени обстоятелства. В даденият пример, потребител получава съобщение за проблем в даден блок от данни, когото се опитва да изпълни заявка върху дадена таблица. SQL> connect testuser/testpassword Connected. SQL> select count(*) from test_table; select count(*) from test_table * ERROR at line 1: ORA-01578: ORACLE data block corrupted (file # 4, block # 2015) ORA-01110: data file 4: 'D:\ORACLE_DATA\DATAFILES\MYDB\USERS01.DBF' След като знаем името на файла и номера на блока, чрез RMAN може за извършим възстановяване на ниво блокове. Това най-добре може да се види със следният пример: C:\>rman target / Recovery Manager: Release 10.2.0.3.0 - Production on ╫Є ═юхь. 13 14:30:47 2008 Copyright (c) 1982, 2005, Oracle. All rights reserved. connected to target database: MYDB (DBID=2560810083) RMAN> blockrecover datafile 4 block 2015; Starting blockrecover at 26/JAN/05 using target database controlfile instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=19 devtype=DISK allocated channel: ORA_DISK_2 channel ORA_DISK_2: sid=20 devtype=DISK channel ORA_DISK_1: restoring block(s) channel ORA_DISK_1: specifying block(s) to restore from backup set restoring blocks of datafile 00004 channel ORA_DISK_1: restored block(s) from backup piece 1 piece handle=E:\BACKUP\0QGB0UEC_1_1.BAK tag=TAG20050124T152708 params=NULL channel ORA_DISK_1: block restore complete starting media recovery media recovery complete Finished blockrecover at 26/JAN/08 RMAN> Сега потребителя може да изпълни заявка върху дадената таблица. SQL> select count(*) from test_table; COUNT(*)
217001 SQL> Както се вижда от примера могат да се направят следните изводи: Възстановяване на ниво блокове може да се осъществи единствено с помощта на RMAN. Базата данни може да бъде отворена докато се извършва възстановяване на блок. Поради тази причина е добра идея всеки RMAN бекъп да бъде верифициран, защото в случай, че в базата данни има повреден блок с данни RMAN-а ще приключи с грешка указваща конкретният файл и конкретният блок, където е възникнал проблема.
Случай А. Ако съществува копие на online възстановяващ лог Ако online възстановяващ лог липсва, той може да бъде възстановен от копие на online възстановяващ лог. Това е единственият вариант да се осъществи възстановяване без загуби. C:\Documents and Settings\veselin.mihaylov>sqlplus / as sysdba SQL*Plus: Release 10.2.0.3.0 - Production on ╧Є ═юхь. 7 17:20:30 2008 Copyright (c) 1982, 2006, Oracle. All Rights Reserved. Connected to an idle instance. SQL> startup ORACLE instance started. Total System Global Area 289406976 bytes Fixed Size 1290184 bytes Variable Size 176160824 bytes Database Buffers 104857600 bytes Redo Buffers 7098368 bytes Database mounted. ORA-00313: open failed for members of log group 1 of thread 1 ORA-00312: online log 1 thread 1: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\MYDB\REDO01.LOG'
За да разрешим този проблем просто копираме едно от копията на online възстановяващите логове и съответно го преименуваме със съответното име. След това с командата "alter database open" можем да отворим базата. Случай Б. Ако е повредена или изгубена една възстановяваща група(redo log group) В този случай, едно непълно възстановяване на базата е най-доброто , което може да се направи. Ще се изгубят всички транзакции от липсващата лог група и всички по-следващи логове. Ще направим същият пример, както в предишният случай с тази разлика, че нямаме копие на „redo log group”, и така ще трябва да се направи непълно възстановяване на базата . C:\> sqlplus / as sysdba SQL*Plus: Release 10.2.0.3.0 - Production on ╫Є ═юхь. 13 14:04:50 2008 Copyright (c) 1982, 2006, Oracle. All Rights Reserved. Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production With the Partitioning, OLAP and Data Mining options SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. SQL> startup ORACLE instance started. Total System Global Area 612368384 bytes Fixed Size 1292036 bytes Variable Size 234883324 bytes Database Buffers 369098752 bytes Redo Buffers 7094272 bytes Database mounted. ORA-00313: open failed for members of log group 3 of thread 1 ORA-00312: online log 3 thread 1:'D:\ORACLE\PRODUCT\10.2.0\ORADATA\MYDB\REDO03.LOG' ORA-00312: online log 3 thread 1:'D:\ORACLE\PRODUCT\10.2.0\ORALOG\MYDB\REDO03B.LOG'
Първата стъпка е да установим до къде можем да възстановим базата данни. За да направим това ще извършим заявка към изгледа v$log за да установим системният номер на промяната (SCN) до който можем да извършим възстановяване. SQL> select first_change# from v$log where group#=3 ; FIRST_CHANGE# --------------- 2782547242062 Стойността FIRST_CHANGE# е първият номер на промяната съхранен в липсващият лог, което означава че последният SCN в предишният лог е FIRST_CHANGE# -1 или 2782547242061. Това е най-големият SCN до който можем да възстановим базата. C:\Documents and Settings\veselin.mihaylov>rman target / Recovery Manager: Release 10.2.0.3.0 - Production on ╫Є ═юхь. 13 14:30:47 2008 Copyright (c) 1982, 2005, Oracle. All rights reserved. connected to target database: MYDB (DBID=2560810083, not open)
Starting restore at 2008-11-13 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=153 devtype=DISK allocated channel: ORA_DISK_2 channel ORA_DISK_2: sid=152 devtype=DISK channel ORA_DISK_1: starting datafile backupset restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set restoring datafile 00001 to D:\ORACLE\PRODUCT\10.2.0\ORADATA\MYDB\SYSTEM01.DBF ................................................. channel ORA_DISK_1: restore complete, elapsed time: 00:09:56 Finished restore at 2008-11-13
Starting recover at 2008-11-13 using channel ORA_DISK_1 using channel ORA_DISK_2 starting media recovery archive log thread 1 sequence 1 is already on disk as file D:\ORACLE\PRODUCT\10.2.0\DB_1\RDBMS\ARC00001_0670198896.001 archive log thread 1 sequence 2 is already on disk as file D:\ORACLE\PRODUCT\10.2.0\DB_1\RDBMS\ARC00002_0670198896.001 archive log thread 1 sequence 3 is already on disk as file D:\ORACLE\PRODUCT\10.2.0\ORADATA\MYDB\ARCHIVE\MYDB_001_0670198896_00003.ARC ........................... archive log filename=D:\ORACLE\PRODUCT\10.2.0\ORADATA\MYDB\ARCHIVE\MYDB_001_0670198896_00023.ARC thread=1 sequence=23 archive log filename=D:\ORACLE\PRODUCT\10.2.0\ORADATA\MYDB\ARCHIVE\MYDB_001_0670198896_00024.ARC thread=1 sequence=24 media recovery complete, elapsed time: 00:03:30 Finished recover at 2008-11-13
database opened Важно е да се отбележат следните неща: 1. Цялата база данни трябва да бъде възстановена до SCN , който беше определен по-горе. 2. Всички промени след установеният по-горе SCN са изгубени. Този метод на възстановяване трябва да се използва само, когато сте сигурни, че не може да се направи нищо по-добро. За това добра практика е да се създават копия на възстановяващите логове на отделни дискови дялове. 3. Базата данни трябва да бъде отворена с RESETLOGS, тъй като търсеният лог не е бил приложен. Това ще възстанови последователността на логовете да стартира от нула. Първата стъпка след като базата е отворена е да се направи бекъп. Опцията RESETLOGS се използва при всяко непълно възстановяване. 3.3 Възстановяване на повреден или липсващ контролен файл Случай А. Ако е повреден един от контролните файлове Когато се стартира базата, Oracle трябва да прочете контролният файл за да установи къде се намират дата файловете и „online“ възстановяващите логове. Oracle очаква да намери контролните файлове на мястото указано от параметъра CONTROL_FILE в инициализационният параметричен файл. Инстанцията ще върне грешка при монтирането на базата , ако който и да е от контролните файлове липсва или е повреден. За тестовата ситуация ще спрем базата и ще изтрием един от контролните файлове. SQL> startup ORACLE instance started. Total System Global Area 612368384 bytes Fixed Size 1292036 bytes Variable Size 243271932 bytes Database Buffers 360710144 bytes Redo Buffers 7094272 bytes ORA-00205: error in identifying control file, check alert log for more info SQL> Ако погледнем в алерт лога ..... ALTER DATABASE MOUNT Fri Nov 14 10:49:43 2008 ORA-00202: Message 202 not found; No message file for product=RDBMS, facility=ORA; arguments: [D:\ORACLE\PRODUCT\10.2.0\ORADATA\MYDB\CONTROL01.CTL] ORA-27041: Message 27041 not found; No message file for product=RDBMS, facility=ORA OSD-04002: unable to open file O/S-Error: (OS 2) The system cannot find the file specified. ... откриваме, че един от контролните файлове липсва. В този случай решението е просто. Копираме един от останалите контролни файлове на съответното място като не забравяме да го преименуваме и базата вече може да бъде отворена за работа.
ORA-01507: database not mounted ORACLE instance shut down.
ORACLE instance started. Total System Global Area 612368384 bytes Fixed Size 1292036 bytes Variable Size 247466236 bytes Database Buffers 356515840 bytes Redo Buffers 7094272 bytes Database mounted. Database opened.
По интересен е случая когато липсват всичките контролни фйлове. Случай Б. Ако липсват всичките контролни фйлове. В този случай , решението е да се възстановят от RMAN бекъп, освен това трябва да се възстановят и всички файлове с данни и накрая да се приложат всички налични архивни лог-ове. Така базата ще се възстанови до момента, в който контролните файлове са се повредили или изчезнали по някакъв начин. C:\ > rman target / Recovery Manager: Release 10.2.0.3.0 - Production on ╧Є ═юхь. 14 14:10:30 2008 Copyright (c) 1982, 2005, Oracle. All rights reserved. connected to target database (not started) RMAN> startup nomount; Oracle instance started Total System Global Area 612368384 bytes Fixed Size 1292036 bytes Variable Size 281020668 bytes Database Buffers 322961408 bytes Redo Buffers 7094272 bytes
Starting restore at 2008-11-14 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=157 devtype=DISK channel ORA_DISK_1: restoring control file channel ORA_DISK_1: restore complete, elapsed time: 00:00:03 output filename=D:\ORACLE\PRODUCT\10.2.0\ORADATA\MYDB\CONTROL01.CTL output filename=D:\ORACLE\PRODUCT\10.2.0\ORADATA\MYDB\CONTROL02.CTL output filename=D:\ORACLE\PRODUCT\10.2.0\ORADATA\MYDB\CONTROL03.CTL Finished restore at 2008-11-14
database mounted released channel: ORA_DISK_1
Starting restore at 2008-11-14 allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=156 devtype=DISK allocated channel: ORA_DISK_2 channel ORA_DISK_2: sid=155 devtype=DISK channel ORA_DISK_1: starting datafile backupset restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set restoring datafile 00001 to D:\ORACLE\PRODUCT\10.2.0\ORADATA\MYDB\SYSTEM01.DBF restoring datafile 00002 to D:\ORACLE\PRODUCT\10.2.0\ORADATA\MYDB\UNDOTBS01.DBF ……………………………………………………………………………………………………………………………………………. channel ORA_DISK_1: reading from backup piece D:\TEMP\DTF_LEVEL_0_ARJO19Q6_1_1 channel ORA_DISK_1: restored backup piece 1 piece handle=D:\TEMP\DTF_LEVEL_0_ARJO19Q6_1_1 tag=LEVEL0 channel ORA_DISK_1: restore complete, elapsed time: 00:05:06 Finished restore at 2008-11-14
………. output filename=D:\ORACLE\PROD Finished restore at 2008-11-14 RMAN> alter database open resetlogs; Database altered До сега покрихме нужните тестове, но остана един от най-важните, а именно възстановяване на цялата база от данни. Ако разполагаме с резервна база, то варианта в този случай да се активира резервната база от данни е най-удачен. Това ще спести време за възстановяване, тъй като времето за активиране е в рамките на само няколко минути, докато възстановяването от RMAN бекъп ще отнеме часове (в зависимост от размера на базата данни). Всъщност един добър критерии за това дали направеният RMAN бекъп може да ни спаси в кризисна ситуация е създаването на резервна база данни с помощта на направеният RMAN бекъп. 4. Конфигуриране на “standby database” Създаването на „standby” база данни е абсолютно идентично с процедурата за възстановяване на контролните файлове описна по-горе. Разликата е само в това, че вместо да възстановим контролният файл направен с помощта на RMAN бекъпа – ще възстановим на новият сървър „standby” контролният сървър от същият RMAN бекъп. Преди да се създаде „standby” базата им някой изисквания, които трабва да се изпълнят.
Ако тези изисквания са изпълнени може да пръдължим към създаване на „standby” сървър. Процедурата е следната:
4.1 Възстановяване от RMAN бекъп. Както вече споменах по-горе процедурата по-възстановяване е идентична с тази при възстановяване на базата данни при загуба на контролните файлове. Разликата е, че ще възстановим създадения именно за такъв случай „standby” контролен файл. D:\temp>rman target / Recovery Manager: Release 10.2.0.3.0 - Production on ╧э ─хъ. 8 22:19:39 2008 Copyright (c) 1982, 2005, Oracle. All rights reserved. connected to target database (not started) RMAN> startup nomount; Oracle instance started Total System Global Area 612368384 bytes Fixed Size 1292036 bytes Variable Size 192940284 bytes Database Buffers 411041792 bytes Redo Buffers 7094272 bytes
using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=157 devtype=DISK channel ORA_DISK_1: restoring control file channel ORA_DISK_1: restore complete, elapsed time: 00:00:06 output filename=D:\ORACLE\PRODUCT\10.2.0\ORADATA\PRIMA\CONTROL01.CTL output filename=D:\ORACLE\PRODUCT\10.2.0\ORADATA\PRIMA\CONTROL02.CTL output filename=D:\ORACLE\PRODUCT\10.2.0\ORADATA\PRIMA\CONTROL03.CTL Finished restore at 2008-12-08 RMAN> mount database; database mounted released channel: ORA_DISK_1 RMAN> restore database; Starting restore at 2008-12-08 allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=153 devtype=DISK allocated channel: ORA_DISK_2 channel ORA_DISK_2: sid=152 devtype=DISK
channel ORA_DISK_2: specifying datafile(s) to restore from backup set .............................................................. channel ORA_DISK_2: restore complete, elapsed time: 00:00:46 Finished restore at 2008-12-08
using channel ORA_DISK_1 using channel ORA_DISK_2
channel ORA_DISK_1: restoring archive log archive log thread=1 sequence=7 channel ORA_DISK_1: reading from backup piece D:\TEMP\DATA_L0_08K1MIAG_1_1 channel ORA_DISK_1: restored backup piece 1 piece handle=D:\TEMP\DATA_L0_08K1MIAG_1_1 tag=LEVEL0 channel ORA_DISK_1: restore complete, elapsed time: 00:00:02 archive log filename=D:\ORACLE\PRODUCT\10.2.0\ORADATA\PRIMA\ARCHIVE\ARC00010_0672793666.001 thread=1 sequence=11 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 12/08/2008 22:25:39 RMAN-11003: failure during parse/execution of SQL statement: alter database recover logfile 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\PRIMA\ARCHIVE\ARC00010_0672793666.001' ORA-00310: archived log contains sequence 10; sequence 11 required ORA-00334: archived log: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\PRIMA\ARCHIVE\ARC00010_0672793666.001'
Последното съобщение за грешка не бива да ни плаши, тъй като това е стандартна за RMAN грешка, когато не е намерен следващият архивен лог. Така вече имаме резервна база данни. Може да проверим ролята на базата данни, като изпълним следната заявка.
DATABASE_ROLE ---------------- PHYSICAL STANDBY По този начин освен, че успяхме да създадем резервна база данни, имахме и възможността да проверим, дали така направеният RMAN бекъп ще ни бъде в помощ в случай че трябва да се възстанови цялата база данни. От тук нататък, за конфигурирането на резервната база данни в Data Guard, Oracle е предоставила много добра документация[8], където могат да се погледнат изискванията, и да се направят нужните промени. По-важното е, че в случай на непреодолима ситуация възникнала на продукционната среда, само за няколко минути може да се активира резервната база данни и да се възстанови нормалният ритъм на работа на потребителите. Заключение Настоящата дипломна работа е насочена към съставяне, разработване и тестване на стратегия за архивиране и възстановяване на база данни под управлението на Oracle Database 10g Server, имаща за цел да осигури резервиране на данните при минимално време за възстановяване на нормалния ритъм на работа. Анализирани са функционирането на СУБД Oracle от гледна точка на създаването на архиви. Проучени са и са анализирани средствата за архивиране и възстановяване на СУБД Oracle. Разработена е стратегия за архивиране и възстановяване на данни при възникване на аварийна ситуация в СУБД Oracle DB 10g Server. Стратегията е тествана и внедрена в условията на реална експлоатация на СУБД Oracle DB 10g Server. В настоящата дипломна работа не беше възможно да се покрият всички проблеми, които биха могли да възникнат в реални ситуации, но тя е един добър старт при разработване на стратегии за архивиране и възстановяване, както и за проучване, и тестване на ситуации, които са критични за работата на базата данни, преди да се внедри всяка една стратегия в реална среда. Използвана литература 1. http://youngcow.net/doc/oracle10g/server.102/b14196/instance.htm 2. “Основи на Oracle, Oracle Database 10g” автори: Рик Грийнвалд, Робърт Стаковяк и Джонатан Стърн издателство 3. Oracle9i Recovery Manager User'sGuide Release2 (9.2) Part Number A96566-01 4. http://www.oracle.com/technology/deploy/availability/htdocs/BR_Overview.htm 5. http://www.orafaq.com/wiki/Import_Export_FAQ 6. http://download.oracle.com/docs/cd/B19306_01/backup.102/b14191/rcmconc1005.htm 7. http://www.oracle.com/technology/deploy/availability/htdocs/DataGuardOverview.html 8. Oracle® Data Guard Concepts and Administration 10g Release 2 (10.2) Изтегляне 0.55 Mb. Сподели с приятели:
|