老熊的三分地-Oracle及数据恢复

众所周知，如果一个库没有设置为force logging，而这个库在归档模式下，对表的插入操作如果采用APPEND模式，并且表设置为nologging则不会为插入的数据产生日志。那么对LOB列的存储也设置为NOLOGGING，会产生什么样的结果？

测试环境：Oracle 9.2.0.1 for Win，非归档模式

create table test1.t1(id int not null, out_row clob)
lob(out_row) store as (disable storage in row nocache nologging);

关闭数据库，备份数据文件users01.dbf

启动数据库，将表中插入数据：

insert into test1.t1 select rownum,rpad('x',5000,'x') from dba_objects where rownum<=100;

select * from test1.t1;

能够正常返回100行数据。

关闭数据库，用备份的文件还原文件users01.dbf，启动数据库时报错：

数据库装载完毕。
ORA-01113: ?? 5 ??????
ORA-01110: ???? 5: 'D:\ORACLE\ORADATA\XJ\USERS01.DBF'

SQL> recover datafile 5;
完成介质恢复。

SQL> alter session set nls_language=american;

Session altered.
SQL> alter database open;

Database altered.

SQL> select count(*) from test1.t1;

  COUNT(*)
----------
       100

SQL> select * from test1.t1;
ERROR:
ORA-01578: ORACLE data block corrupted (file # 5, block # 61)
ORA-26040: Data block was loaded using the NOLOGGING option
ORA-01110: data file 5: 'D:\ORACLE\ORADATA\XJ\USERS01.DBF'

由此可以看出，在此前的插入操作中，没有对LOB数据产生日志。

我们将test1.t1删除，再重新创建，只是将LOB设置为LOGGING。

SQL> drop table test1.t1;

表已丢弃。

SQL> create table test1.t1 (id number not  null,out_row clob)
  2  lob (out_row) store as (disable storage in row nocache logging);

重复上步实验过程，发现LOGGING模式下的LOB能够正常恢复。

将数据库设置为归档模式，重复以上测试过程，发现NOLOGGING模式下的LOB仍然不能恢复。

将数据库设置为FORCE LOGGING模式，重复以上测试过程，发现NOLOGGING模式下的LOB能够正常恢复。

经过进一步测试，对LOB字段进行UPDATE也会产生上述实验结果。

在这个测试中使用了一个比较“笨”的办法。观察LOB列是否产生日志，可以观察redo size和分析日志文件进行。在此不在细述。

经过测试，发现IN ROW的LOB列与表中的其他列数据是一致的LOGGING行为。

注意：LOB列如果设置为CACHE，则只能是LOGGING模式。

由此引出一个问题，由于对LOB列设置为NOLOGGING，虽然能够提高数据插入速度，为数据恢复设置了一道难关。需要此种情况下的备份恢复策略，或者将LOB列设置为LOGGING模式。

某个刚安装好的RAC库，由于需要更换存储，所以需要重建。由于主机系统并没有重新安装，因此只需要重建CRS和库就行了。

环境：AIX 5306+HACMP 5.2+ORACLE 10.2.0.1+祼设备，文中对节点名、网络配置等信息处了更改处理。

以下是详细操作步骤：

1、在两个节点上修改主机配置：由于网络变更的原因，需要更换VIP，因此修改/etc/hosts文件，将VIP地址对应的地址更改为新的IP地址

2、在两个节点上修改/etc/oracle/ocr.loc文件，将文件中的ocrconfig_loc=后的地址改为新的存储ocr的祼设备名（如果用的是集群文件系统，则为文件名）

3、在两个节点上删除文件/etc/oracle/scls_scr/<节点名>/oracle/cssfatal

4、在两个节点上，进入$ORA_CRS_HOME/install目录，修改paramfile.crs文件，修改变动的配置数据。这里主要包括CRS_OCR_LOCATIONS、CRS_VOTING_DISKS、CRS_NODEVIPS

5、对存储OCR CONFIG的祼设备，用dd命令进行清除。（如果是集群文件系统，只需要删除OCR CONFIG的文件即可）。这里祼设备名为rocr，dd if=/dev/zero f=/dev/rocr bs=4096 count=10000 （如果是OCR本来是存在，只是需要重建，则必须要执行这一步。就算是完全新建在祼设备上，在后面的步骤中有时也会遇到莫名其妙的问题，则也需要对祼设备用dd进行清除，dd清除的大小不能过小，bs=4096的情况下，count为10之类的数值就显得过小，后面也会出现问题）

6、在两个节点上修改文件$ORA_CRS_HOME/install/rootconfig，修改在文件前面的变量。这里也主要是CRS_OCR_LOCATIONS、CRS_VOTING_DISKS、CRS_NODEVIPS

7、如果是通过远程telnet、ssh在主机上操作，则要设置DISPLAY变量。export DISPLAY=x.x.x.x:0.0。这里x.x.x.x为操作的终端的IP地址。在操作终端上运行如xmanager这样的软件。

7、在节点一上以root用户运行$ORA_CRS_HOME/install/rootconfig，注意不要运行rootinstall

8、待节点一完全运行完后，在节点二上运行$ORA_CRS_HOME/install/rootconfig。正常情况下会弹出vip设置窗口。如果VIP设置窗口没有弹出来，则看一下是否只是vipca启动出现问题。

9、在两个节点上运行crs_stat -t，如果出现CRS没有资源或有VIP相关的资源启动（在VIP已经设置的情况下），说明CRS已经建立成功。

10、如果前面没有配置VIP，则以root用户运行vipca，配置VIP。注意在弹出的窗口中，提示选择网络接口时，选择public接口。（如果显示接口异常，在shell用oifcfg命令检查一下网络接口，如有必要，用该命令对网络接口进行重新配置）

11、至此crs已经配置完毕，用crs_stat检查crs是否正常运行。如果没有正常运行，检查crs日志。此时应该有VIP、ONS、GSD等资源运行。在两个节点上运行ifconfig -a检查VIP是否已经绑定到PUBLIC网卡上（注意要确保是在PUBLIC网卡上，有的时候粗略一下VIP已经起了，但实际上绑在了PRIVATE网卡上）

12、清除原来的监听设置，确认监听是处于关闭状态，运行netca，配置监听，配置完成后将会自动把监听加入到crs中。

12、由于存在原来的建库脚本，打开原来的脚本，修改对应的数据文件名为新的文件名（祼设备名）

13、在节点一上运行建库脚本(shell脚本)

14、一番耐心等候之后，在节点一上的数据库创建完成

15、在节点二上运行建库脚本(shell脚本)，这个过程很快

16、在两个节点上修改tnsnames.ora，内容如下（根据实际情况进行修改）：

LISTENERS_DMDB =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = dm1-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = dm2-vip)(PORT = 1521))
)

DMDB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = dm1-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = dm2-vip)(PORT = 1521))
(LOAD_BALANCE = yes)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = dmdb)
)
)

RAC2 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = dm2-vip)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = dmdb)
(INSTANCE_NAME = rac2)
)
)

RAC1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = dm1-vip)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = dmdb)
(INSTANCE_NAME = rac1)
)
)

EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))
)
(CONNECT_DATA =
(SID = PLSExtProc)
(PRESENTATION = RO)
)
)

17、修改两个节点的初始化参数REMOTE_LISTENERS为 'LISTENERS_DMDB'，节点一的LOCAL_LISTENER='(ADDRESS = (PROTOCOL = TCP)(HOST = IP1 )(PORT = 1521))'，节点二的
LOCAL_LISTENER='(ADDRESS = (PROTOCOL = TCP)(HOST = IP2)(PORT = 1521))'，注意这里的IP1和IP2分别是节点一和节点二的VIP地址（注意一定是IP地址，而不能是主机名）。设置LOCAL_LISTENER的目的是避免在使用负载均衡时出现ORA-12545错误。

18、在其中一个结点上创建spfile，这里spfile为祼设务rspfile：create spfile='/dev/rspfile' from pfile='xxxx'

19、关闭两个节点的实例。将数据库和实例增加到crs中，以便能够能用crs命令进行监控和用srvctl命令启停数据库实例：

srvctl add database -d dbname -o $ORACLE_HOME -y manual
srvctl add instance -d dbname -n 节点名1 -i 实例名1
srvctl add instance -d dbname -n 节点名2 -i 实例名2

这里实例名1和实例名2应分别与两个节点的ORACLE_SID一致

注意：10.2.0.1版本，实例依赖于VIP，因此如果某结点如网卡DOWN掉、VIP BUG等，将导致实例也DOWN掉。为避免出现这样的情况，可省略此步骤，不要将实例加入到CRS资源中。

至此所有工作已经全部完成

由于ORACLE默认的表名都是不区分大小写，在创建表时，在数据字典中存储的表名为大写。在有些情况下，如果创建的表在表名上加上双引号(")，则创建的表其表名在数据字典中不作转换。比如

create table test1."Table1" as select * from dba_objects where rownum<=10;

表已创建。

select table_name from dba_tables where owner='TEST1';

TABLE_NAME
------------------------------------------------------------
T1
T2
Table1
tt

可以看到刚创建的Table1表在数据字典中为"Table1"而不是TABLE1

在导出这样的表时，按用户导出是没有问题的：

exp test1/test1 wner=test1

. 即将导出 TEST1 的表通过常规路径 ...
. . 正在导出表 T1 0 行被导出
. . 正在导出表 T2 0 行被导出
. . 正在导出表 Table1 10 行被导出
. . 正在导出表 tt 10 行被导出

而要单独导出表的话，则需求作特殊处理

exp test1/test1 tables=Table1

即将导出指定的表通过常规路径 ...
EXP-00011: TEST1.TABLE1 不存在
导出成功终止，但出现警告。

将table1用双引号或单引号引起也是一样

exp test1/test1 tables=\"Table1\"

也是一样的结果

用下面的写法可以成功

exp test1/test1 tables='\"Table1\"'

即将导出指定的表通过常规路径 ...
. . 正在导出表 Table1 10 行被导出
在没有警告的情况下成功终止导出。

用参数文件时，由用tables='"Table1"'，去掉反斜杠

注意tables='\"Table1\"'这里是外面一个单引号加反斜杠再加一双引号

在job执行过程中，all_jobs中，this_date和this_sec记录本次开始执行的时间。next_date和next_sec则在开始执行时按interval计算好。执行完成后，无论失败与否，last_date和last_sec为上次执行（也即刚执行过）开始的时间。next_date和next_sec为下次开始执行时间。

如果执行失败，failures字段加1，同时下次执行时间为本次执行时间+2分钟（不知这两分钟从何而来，有空再研究一下），如果再次失败，由下次执行的时间为上次开始执行时间+4，再次失败则+8，以此类推。

执行成功后，failures字段清0.

在同一个数据库内，被引用对象上进行了alter、drop等操作，该对象的依赖对象如view、function、procedure等，状态会自动标记为Invalid，再重新使用这些依赖对象时，系统会自动重新compile。

而一个数据库内的对象引用了远程数据库的对象（这里指程序对象，如procedure等），则远程数据库对象发生了变更，由于本地数据库并不知晓此种情况，本地数据库的这些对象状态仍然为valid，在调用这些对象时，Oracle会根据remote_dependencies_mode参数值，确定采用timestamp或signature进行依赖性检查。如果发现不匹配，则会直接报错返回，同时将依赖该远程对象的所有本地对象标记为invalid。

通过以下测试可以进行验证

先在远程数据库上创建一个测试存储过程

SQL> create or replace procedure p_r_test
2 is
3 begin
4 null;
5 end;
6 /

Procedure created

然后在本地数据库上创建两个测试存储过程

create or replace procedure p_test1
is
begin
p_r_test@testlink
end;

/

create or replace procedure p_test2
is
begin
p_r_test@testlink
end;

/

执行一下测试程序过程

SQL> exec p_test1;

PL/SQL procedure successfully completed

查看这两个存储过程的状态

SQL> select object_name,object_type,status from all_objects where object_name in ('P_TEST1','P_TEST2');

OBJECT_NAME                    OBJECT_TYPE        STATUS
------------------------------ ------------------ -------
P_TEST1                        PROCEDURE          VALID
P_TEST2                        PROCEDURE          VALID

在远程数据库上重新create or replace一下程储过程，再查看本地数据库两个存储过程的状态

SQL> select object_name,object_type,status from all_objects where object_name in ('P_TEST1','P_TEST2');

OBJECT_NAME                    OBJECT_TYPE        STATUS
------------------------------ ------------------ -------
P_TEST1                        PROCEDURE          VALID
P_TEST2                        PROCEDURE          VALID

执行存储过程p_test1

SQL> exec p_test1;

begin p_test1; end;

ORA-04068: 已丢弃程序包 的当前状态
ORA-04062: timestamp (属 procedure "TEST.P_R_TEST") 已被更改
ORA-06512: 在"TEST.P_TEST1", line 4
ORA-06512: 在line 2

再看两个存储过程的状态

SQL> select object_name,object_type,status from all_objects where object_name in ('P_TEST1','P_TEST2');

OBJECT_NAME                    OBJECT_TYPE        STATUS
------------------------------ ------------------ -------
P_TEST1                        PROCEDURE          INVALID
P_TEST2                        PROCEDURE          INVALID

如果这个时候再执行p_test1，则系统发现状态为INVALID，会进行重新编译。

因此在涉及到调用远程存储过程的本地对象，如function、package、procedure等，需要注意远程对象变更这种情况的发生，避免出现本地对象失效，从而引起程序问题，特别是在JOB这样的应用中。