v$datafile 의 status 에 recover로 표시되는 경우
2010.05.12 08:39
원문 : http://www.ischo.net -- 조인상 // 시스템 엔지니어
Writer : http://www.ischo.net -- ischo // System Engineer in Replubic Of Korea
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
본문 : http://www.ischo.net -- 조인상 //시스템 엔지니어
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
ACTIVE DATABASE에서 DATAFILE RESIZE 작업 후 STANDBY DB에 적용한 경우....
java.sql.SQLException: IO 예외 상황: The Network Adapter could not establish the connection
No. 11996
PRIMARY DATABASE에서 DATAFILE RESIZE 작업 후 STANDBY DB에 적용하는 방법
=====================================================================
PURPOSE
-------
Primary/Standby DB에서 datafile resize후 datafile status가 recovery 상태로 변경되는데
이에 대한 원인과 해결 방안에 대해 알아보고자 한다.
Explanation
-----------
Primary/Standby database에서 datafile resize 작업을 하게 되면 Primary DB에서
v$datafile을 조회시 resize가 적용된것을 확인하실 수 있다.
그러나 Standby database에서 v$datafile 을 조회하게 되면 status가 recover상태로
되어 있는것을 발견할 수 있다.
이것은 primary db에서 datafile resize 작업이 automatic하게 standby db에 적용되지 않기 때문이다.
이럴 경우 다음과 같은 작업으로 해결 할 수 있다.
On standby database
-------------------
SVRMGR>startup nomount pfile=initstd.ora
SVRMGR>alter database mount standby database;
Let's check datafile in the dictionnary's views before recovering:
SVRMGR> select file#,status,name,bytes from v$datafile where file#=3;
FILE# status NAME
BYTES
---------- ------- ------------------------------------
3 recover /U01/DATA/USERS01.DBF
113246208
1 row selected.
standby db에 datafile resize를 적용시키시려면 다음과 같이 수행한다.
SVRMGR>recover standby database;
작업을 수행하게 되면 standby db쪽의 datafile에 resize가 적용된募.
SVRMGR> select file#, name,bytes from v$datafile where file#=3;
FILE# NAME
BYTES
---------- ------- ------------------------------------
3 /U01/DATA/USERS01.DBF
119537664
1 row selected.
아래 bytes를 확인해 보시면 113246208 -> 119537664 로 변경된것을 확인할 수 있다.
그러나 status는 여전히 recover 상태로 존재하게 된다.
이것은 standby db가 readonly 상태이기 때문이며 standby db가 activated(활성화) 되게 되면
read write 상태가 되어 정상적으로 online 상태를 유지하게 된다.
Reference Document
------------------
<note. 123883.1>
PURPOSE
-------
This document describes the standby database's behaviour an various
questions and answers regarding the resize of datafile.
SCOPE & APPLICATION
-------------------
On the primary database the initial size of the datafile is 113246208
and now we decide to resize it by :
SVRMGR>Alter database datafile '/u01/data/users01.dbf ' resize 115M;
The size of the datafile become 119537664.
On standby database
-------------------
SVRMGR>startup nomount pfile=initstd.ora
SVRMGR>alter database mount standby database;
Let's check datafile in the dictionnary's views before recovering:
SVRMGR> select file#,status,name,bytes from v$datafile where file#=3;
FILE# NAME
BYTES
---------- ------- ------------------------------------
3 /U01/DATA/USERS01.DBF
113246208
1 row selected.
SVRMGR>recover standby database;
...
When looking the alert.log any information was applied to notice that
the file is resized.we only see the following:
ORA-279 signalled during: ALTER DATABASE RECOVER LOGFILE
'e:\archive\base...
Mon Nov 06 13:55:30 2000
ALTER DATABASE RECOVER CANCEL
Mon Nov 06 13:55:30 2000
Media Recovery Cancelled
Completed: ALTER DATABASE RECOVER CANCEL
...
Whereas in the directory where the datafile resides we can see
that the size of the datafile is changed.
Let's check again the datafile in the dictionnary's views:
SVRMGR> select file#,status,name,bytes from v$datafile where file#=3;
FILE# NAME
BYTES
---------- ------- ------------------------------------
3 /U01/DATA/USERS01.DBF
119537664
1 row selected.
The size of datafile on the standby is now 1199537664 and match
with the primary.
The only thing to be made before applying the logs is to make sure that
there is space necessary for the enlarging of the file. Oracle
propagates
all during the recover on the controlfile,the datafile and resize
automatically the datafile in its directory.
On the other hand some views of the dictionary such as v$datafile,
v$recover_file can present the file with a status "RECOVER".
This status does not prevent the correct operation of the base even
in read only.
Once the database is activated i.e. opened in Read Write, the datafile
does not have any more status "RECOVER".
RELATED DOCUMENTS
-----------------
Backup & recovery guide
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
ACTIVE DATABASE에서 DATAFILE RESIZE 작업 후 STANDBY DB에 적용한 경우....
java.sql.SQLException: IO 예외 상황: The Network Adapter could not establish the connection
No. 11996
PRIMARY DATABASE에서 DATAFILE RESIZE 작업 후 STANDBY DB에 적용하는 방법
=====================================================================
PURPOSE
-------
Primary/Standby DB에서 datafile resize후 datafile status가 recovery 상태로 변경되는데
이에 대한 원인과 해결 방안에 대해 알아보고자 한다.
Explanation
-----------
Primary/Standby database에서 datafile resize 작업을 하게 되면 Primary DB에서
v$datafile을 조회시 resize가 적용된것을 확인하실 수 있다.
그러나 Standby database에서 v$datafile 을 조회하게 되면 status가 recover상태로
되어 있는것을 발견할 수 있다.
이것은 primary db에서 datafile resize 작업이 automatic하게 standby db에 적용되지 않기 때문이다.
이럴 경우 다음과 같은 작업으로 해결 할 수 있다.
On standby database
-------------------
SVRMGR>startup nomount pfile=initstd.ora
SVRMGR>alter database mount standby database;
Let's check datafile in the dictionnary's views before recovering:
SVRMGR> select file#,status,name,bytes from v$datafile where file#=3;
FILE# status NAME
BYTES
---------- ------- ------------------------------------
3 recover /U01/DATA/USERS01.DBF
113246208
1 row selected.
standby db에 datafile resize를 적용시키시려면 다음과 같이 수행한다.
SVRMGR>recover standby database;
작업을 수행하게 되면 standby db쪽의 datafile에 resize가 적용된募.
SVRMGR> select file#, name,bytes from v$datafile where file#=3;
FILE# NAME
BYTES
---------- ------- ------------------------------------
3 /U01/DATA/USERS01.DBF
119537664
1 row selected.
아래 bytes를 확인해 보시면 113246208 -> 119537664 로 변경된것을 확인할 수 있다.
그러나 status는 여전히 recover 상태로 존재하게 된다.
이것은 standby db가 readonly 상태이기 때문이며 standby db가 activated(활성화) 되게 되면
read write 상태가 되어 정상적으로 online 상태를 유지하게 된다.
Reference Document
------------------
<note. 123883.1>
PURPOSE
-------
This document describes the standby database's behaviour an various
questions and answers regarding the resize of datafile.
SCOPE & APPLICATION
-------------------
On the primary database the initial size of the datafile is 113246208
and now we decide to resize it by :
SVRMGR>Alter database datafile '/u01/data/users01.dbf ' resize 115M;
The size of the datafile become 119537664.
On standby database
-------------------
SVRMGR>startup nomount pfile=initstd.ora
SVRMGR>alter database mount standby database;
Let's check datafile in the dictionnary's views before recovering:
SVRMGR> select file#,status,name,bytes from v$datafile where file#=3;
FILE# NAME
BYTES
---------- ------- ------------------------------------
3 /U01/DATA/USERS01.DBF
113246208
1 row selected.
SVRMGR>recover standby database;
...
When looking the alert.log any information was applied to notice that
the file is resized.we only see the following:
ORA-279 signalled during: ALTER DATABASE RECOVER LOGFILE
'e:\archive\base...
Mon Nov 06 13:55:30 2000
ALTER DATABASE RECOVER CANCEL
Mon Nov 06 13:55:30 2000
Media Recovery Cancelled
Completed: ALTER DATABASE RECOVER CANCEL
...
Whereas in the directory where the datafile resides we can see
that the size of the datafile is changed.
Let's check again the datafile in the dictionnary's views:
SVRMGR> select file#,status,name,bytes from v$datafile where file#=3;
FILE# NAME
BYTES
---------- ------- ------------------------------------
3 /U01/DATA/USERS01.DBF
119537664
1 row selected.
The size of datafile on the standby is now 1199537664 and match
with the primary.
The only thing to be made before applying the logs is to make sure that
there is space necessary for the enlarging of the file. Oracle
propagates
all during the recover on the controlfile,the datafile and resize
automatically the datafile in its directory.
On the other hand some views of the dictionary such as v$datafile,
v$recover_file can present the file with a status "RECOVER".
This status does not prevent the correct operation of the base even
in read only.
Once the database is activated i.e. opened in Read Write, the datafile
does not have any more status "RECOVER".
RELATED DOCUMENTS
-----------------
Backup & recovery guide