對於資料衛士，您可以在物理備用和邏輯備用之間進行選擇。讓我們先來看一下兩者有哪些不同！我將首先演示物理備用，隨後轉換至邏輯備用（資料庫也由此命名）：

[oracle@uhesse1 ~]$ dgmgrl sys/oracle@prima

DGMGRL for Linux: Version 11.2.0.1.0 - 64bit Production

Welcome to DGMGRL, type "help" for information.

Connected.

DGMGRL> show configuration;

Configuration - myconf

Protection Mode: MaxPerformance

Databases:

prima - Primary database

logst - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:

SUCCESS

到目前為止，logst仍然是物理備用。被稱為物理備用的原因是，prima和logst的資料檔案在物理上是相同的。我甚至可以從一個還原至另一個：

DGMGRL> edit database logst set state=apply-off;

Succeeded.

DGMGRL> exit

[oracle@uhesse1 ~]$ sqlplus sys/oracle@prima as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Fri Feb 20 11:43:07 2015

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production

SYS@prima > select name from v$datafile where file#=4;

NAME

--------------------------------------------------

/u01/app/oracle/oradata/prima/users01.dbf

SYS@prima > alter database datafile 4 offline;

Database altered.

現在，我從備用伺服器uhesse2中將資料檔案複製到主伺服器uhesse1，有不同的方法可以做到這一點，但scp是一個：

SYS@logst > select name from v$datafile where file#=4;

NAME

--------------------------------------------------

/u01/app/oracle/oradata/logst/users01.dbf

SYS@logst > exit

Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production

[oracle@uhesse2 ~]$ scp /u01/app/oracle/oradata/logst/users01.dbf uhesse1:/u01/app/oracle/oradata/prima/users01.dbf

The authenticity of host 'uhesse1 (192.168.56.10)' can't be established.

RSA key fingerprint is e9:e7:5b:8b:b2:33:42:26:89:03:54:0c:16:0d:98:57.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added 'uhesse1,192.168.56.10' (RSA) to the list of known hosts.

oracle@uhesse1's password:

users01.dbf 100% 5128KB 5.0MB/s 00:00

[oracle@uhesse2 ~]$

當我嘗試將資料檔案在prima上再次上線時，看起來就像我想從備份中將其恢復：

SYS@prima > alter database datafile 4 online;

alter database datafile 4 online

*

ERROR at line 1:

ORA-01113: file 4 needs media recovery

ORA-01110: data file 4: '/u01/app/oracle/oradata/prima/users01.dbf'

SYS@prima > recover datafile 4;

Media recovery complete.

SYS@prima > alter database datafile 4 online;

Database altered.

在此處的兩個站點中，資料檔案和歸檔的日誌檔案在物理上都是相同的，只有控制文件是不同的。 v$database（比如v$datafile）從控制檔案獲取其內容：

SYS@prima > select name,dbid,database_role from v$database;

NAME DBID DATABASE_ROLE

-------------------------------------------------- ---------- ----------------

PRIMA 2012613220 PRIMARY

SYS@prima > connect sys/oracle@logst as sysdba

Connected.

SYS@logst > select name,dbid,database_role from v$database;

NAME DBID DATABASE_ROLE

-------------------------------------------------- ---------- ----------------

PRIMA 2012613220 PHYSICAL STANDBY

現在，我要將其轉換至邏輯備用：

DGMGRL> edit database logst set state=apply-off;

Succeeded.

DGMGRL> exit

[oracle@uhesse1 ~]$ sqlplus sys/oracle@prima as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Fri Feb 20 17:29:16 2015

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production

SYS@prima > exec dbms_logstdby.build

PL/SQL procedure successfully completed.

SYS@prima > connect sys/oracle@logst as sysdba

Connected.

SYS@logst > alter database recover to logical standby logst;

Database altered.

SYS@logst > shutdown immediate

ORA-01507: database not mounted

ORACLE instance shut down.

SYS@logst > startup mount

ORACLE instance started.

Total System Global Area 521936896 bytes

Fixed Size 2214936 bytes

Variable Size 314573800 bytes

Database Buffers 201326592 bytes

Redo Buffers 3821568 bytes

Database mounted.

SYS@logst > alter database open resetlogs;

Database altered.

SYS@logst > select name,dbid,database_role from v$database;

NAME DBID DATABASE_ROLE

-------------------------------------------------- ---------- ----------------

LOGST 3156487356 LOGICAL STANDBY

SYS@logst > exit

Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production

[oracle@uhesse1 ~]$ dgmgrl sys/oracle@prima

DGMGRL for Linux: Version 11.2.0.1.0 - 64bit Production

Welcome to DGMGRL, type "help" for information.

Connected.

DGMGRL> remove database logst;

Removed database "logst" from the configuration

DGMGRL> add database logst as connect identifier is logst;

Database "logst" added

DGMGRL> enable database logst;

Enabled.

DGMGRL> show configuration;

Configuration - myconf

Protection Mode: MaxPerformance

Databases:

prima - Primary database

logst - Logical standby database

Fast-Start Failover: DISABLED

Configuration Status:

SUCCESS

一處重要的改變是， DBID和名稱現已不同於上面看到的主資料庫。資料檔案在物理上也不再是相同的：

DGMGRL> edit database logst set state=apply-off;

Succeeded.

DGMGRL> exit

[oracle@uhesse1 ~]$ sqlplus sys/oracle@prima as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Fri Feb 20 17:38:56 2015

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production

SYS@prima > alter database datafile 4 offline;

Database altered.

SYS@prima > select name from v$datafile where file#=4;

NAME

--------------------------------------------------

/u01/app/oracle/oradata/prima/users01.dbf

SYS@prima > host cp /u01/app/oracle/oradata/prima/users01.dbf /u01/app/oracle/oradata/prima/users01.old

我複製原始檔案的原因是，我知道從logst恢復將不起作用。為了證明我的觀點：

[oracle@uhesse2 ~]$ scp /u01/app/oracle/oradata/logst/users01.dbf uhesse1:/u01/app/oracle/oradata/prima/users01.dbf

oracle@uhesse1's password:

users01.dbf 100% 5128KB 5.0MB/s 00:00

SYS@prima > alter database datafile 4 online;

alter database datafile 4 online

*

ERROR at line 1:

ORA-01122: database file 4 failed verification check

ORA-01110: data file 4: '/u01/app/oracle/oradata/prima/users01.dbf'

ORA-01206: file is not part of this database - wrong database id

沒錯，logst現在是一個自主資料庫，它只是偶然地使用與prima（幾乎）相同的DML。它在Oracle資料塊方面已不再與prima相同。對於logst來說，來自於prima的rowids已不再有意義：

DGMGRL> edit database logst set state=apply-on;

Succeeded.

SYS@prima > insert into scott.dept values (50,'TEST','TEST');

insert into scott.dept values (50,'TEST','TEST')

*

ERROR at line 1:

ORA-00376: file 4 cannot be read at this time

ORA-01110: data file 4: '/u01/app/oracle/oradata/prima/users01.dbf'

SYS@prima > host cp /u01/app/oracle/oradata/prima/users01.old /u01/app/oracle/oradata/prima/users01.dbf

SYS@prima > alter database datafile 4 online;

alter database datafile 4 online

*

ERROR at line 1:

ORA-01113: file 4 needs media recovery

ORA-01110: data file 4: '/u01/app/oracle/oradata/prima/users01.dbf'

SYS@prima > recover datafile 4;

Media recovery complete.

SYS@prima > alter database datafile 4 online;

Database altered.

SYS@prima > insert into scott.dept values (50,'TEST','TEST');

1 row created.

SYS@prima > commit;

Commit complete.

SYS@prima > select rowid,dept.* from scott.dept where deptno=50;

ROWID DEPTNO DNAME LOC

------------------ ---------- -------------- -------------

AAADS8AAEAAAACNAAE 50 TEST TEST

這就是我們通常記錄在重做日誌條目中的rowid，在我們進行“Redo Apply”（“恢復資料庫”的另一種術語）時，該rowid足以在主資料庫上以及一個物理備用上對該行進行檢索。但這個rowid在logst上是不同的：

SYS@logst > connect sys/oracle@logst as sysdba

Connected.

SYS@logst > select rowid,dept.* from scott.dept where deptno=50;

ROWID DEPTNO DNAME LOC

------------------ ---------- -------------- -------------

AAADS8AAEAAAACOAAA 50 TEST TEST

這就是為什麼我們需要將附加資訊（補充日誌資料）放入主資料庫的重做日誌條目中。這將幫助SQL Apply機制對該行進行檢索：

資料衛士

邏輯備用架構

補充日誌資料應至少額外包括上圖中的主鍵。在沒有主鍵的情況下，修改行的每一列將被寫入重做日誌。邏輯備用的另一個嚴重缺點是，SQL Apply機制並不支援每個資料型別和每個在主資料庫上的操作。然而，不支援的資料型別數量隨著版本的升級正在逐漸減少。

資料衛士

相關文章