Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Download
Standard view
Full view
of .
Look up keyword
Like this
0Activity
0 of .
Results for:
No results containing your search query
P. 1
Recovering After the NOLOGGING Clause is Specified

Recovering After the NOLOGGING Clause is Specified

Ratings: (0)|Views: 0|Likes:
Published by Pankaj Rawat

More info:

Published by: Pankaj Rawat on Jun 16, 2012
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOCX, PDF, TXT or read online from Scribd
See more
See less

06/16/2012

pdf

text

original

 
Recovering After the NOLOGGING Clause Is Specified
 
In some SQL statements, the user has the option of specifying the NOLOGGING clause, which indicatesthat the database operation is not logged in the online redo log file. This can result in log application ordata access errors at the standby site and manual recovery might be required to resume applying log files.
 
Note:
To avoid these problems, Oracle recommends that you always specify the FORCE LOGGING clausein the CREATE DATABASE or ALTER DATABASE statements.
 
 Workshop: Step for Physical Standby Database
 
Step 1
Create a Table in NOLOGGING mode on Primary Database
 
SQL> create table anup nologging as select * from emp;Table created.
 
Step 2
Switch log on Primary Database
 
Step 3
Cancel recovery in Standby Database.
 
SQL> alter database recover managed standby database cancel;
 
Step 4
Put Standby database in Read Mode.SQL> alter database open read only;
 
Step 5
Submit bellow select statement on Standby Database.
 
SQL> select * from scott.anup;
 
select * from scott.anup
 
*
 
ERROR at line 1:
 
ORA-01578: ORACLE data block corrupted (file # 4, block # 436)
 
ORA-01110: data file 4: '/DB/PROD/users01.dbf'
 
ORA-26040: Data block was loaded using the NOLOGGING option
 
To recover after the NOLOGGING clause is specified, you need to copy the datafile that contains themissing redo data from the primary site to the physical standby site.
 
 Action:
 
Step 1
Determine which datafiles should be copied.
 
1. Query the primary database:
 
SQL> SELECT NAME, UNRECOVERABLE_CHANGE# FROM V$DATAFILE;
 
NAME UNRECOVERABLE_CHANGE#
 
/DB/PROD/system01.dbf 0
 
/DB/PROD/undotbs01.dbf 0
 
/DB/PROD/sysaux01.dbf 0
 
/DB/PROD/users01.dbf 687862
 
/DB/PROD/example01.dbf 0
 
/DB/PROD/dims01.dbf 0
 
6 rows selected.
 
 
2. Query the standby database:
 
SQL> SELECT NAME, UNRECOVERABLE_CHANGE# FROM V$DATAFILE;
 
NAME UNRECOVERABLE_CHANGE#
 
/DB/PROD/system01.dbf 0
 
/DB/PROD/undotbs01.dbf 0
 
/DB/PROD/sysaux01.dbf 0
 
/DB/PROD/users01.dbf 0
 
/DB/PROD/example01.dbf 0
 
/DB/PROD/dims01.dbf 0
 
6 rows selected.
 
3. Compare the query results of the primary and standby databases.
 
Compare the value of the UNRECOVERABLE_CHANGE# column in both query results. If the value of the UNRECOVERABLE_CHANGE# column in the primary database is greater than the same column inthe standby database, then the datafile needs to be copied from the primary site to the standby site.
 
In this example, the value of the UNRECOVERABLE_CHANGE# in the primary database for theusers01.dbf datafile is greater, so you need to copy the users01.dbf datafile to the standby site.
 
Step 2
On the primary site, back up the datafile you need to copy to the standby site. Issue the followingSQL statements:
 
SQL> ALTER TABLESPACE users BEGIN BACKUP;
 
SQL> EXIT;
 
% cp users01.dbf /backup
 
SQL> ALTER TABLESPACE system END BACKUP;
 
Step 3
Copy the datafile to the standby database.
 
Copy the datafile that contains the missing redo data from the primary site to location on the physicalstandby site where files related to recovery are stored.
 
Step 4
On the standby database, restart Redo Apply.
 
Issue the following SQL statement:
 
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROMSESSION;
 
 You might get the following error messages (possibly in the alert log) when you try to restart Redo Apply:
 
ORA-00308: cannot open archived log 'standby1'
 
ORA-27037: unable to obtain file status
 
SVR4 Error: 2: No such file or directory 
 
 Additional information: 3
 
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below 
 
ORA-01152: file 1 was not restored from a sufficiently old backup
 
ORA-01110: data file 1: '/oracle/dbs/stdby/tbs_1.dbf'
 
If you get the ORA-00308 error and Redo Apply does not terminate automatically, you can cancel
 
recovery by issuing the following statement from another terminal window:
 
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
 
These error messages are returned when one or more log files in the archive gap have not beensuccessfully applied. If you receive these errors, manually resolve the gaps, and repeat Step 4.
 
 Workshop: Step for Logical Standby Database
 
Typically, you use table instantiation to re-create a table after an unrecoverable operation. You can alsouse the procedure to enable SQL Apply on a table that was formerly skipped.
 
Step 1
Stop SQL Apply:
 
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
 
Step 2
Ensure no operations are being skipped for the table in question by querying the
 
DBA_LOGSTDBY_SKIP view:
 
SQL> SELECT * FROM DBA_LOGSTDBY_SKIP;
 
Because you already have skip rules associated with the table that you want to re-create on the logicalstandby database, you must first delete those rules. You can accomplish that by calling theDBMS_LOGSTDBY.UNSKIP procedure. For example:
 
SQL> EXECUTE DBMS_LOGSTDBY.UNSKIP(stmt => 'DML', -
 
schema_name => 'HR', -
 
object_name => 'EMPLOYEES');
 
SQL> EXECUTE DBMS_LOGSTDBY.UNSKIP(stmt => 'SCHEMA_DDL', -
 
schema_name => 'HR', -
 
object_name => 'EMPLOYEES');
 
Step 3
Re-create the table HR.EMPLOYEES with all its data in the logical standby database by using theDBMS_LOGSTDBY.INSTANTIATE_TABLE procedure. For example:
 
SQL> EXECUTE DBMS_LOGSTDBY.INSTANTIATE_TABLE(shema_name => 'HR', -
 
object-+_name => 'EMPLOYEES', -
 
dblink => 'BOSTON');
 
Step 4
Start SQL Apply:
 
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
 
To ensure a consistent view across the newly instantiated table and the rest of the
 
database, wait for SQL Apply to catch up with the primary database before querying
 
this table. You can do this by performing the following steps:
 

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->