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

其实这篇文章，说讲述的跟DBA没有太大的关系，但是我写出来，希望对DBA有所帮助。

上个月一客户的某重要业务，出现2小时故障，事情闹得很大。故障发生在一个简单的INSERT语句上面，不幸的时执行那个SQL时总是报ORA-600[kcbget_24]这样的错误，其实导致事务一直失败。不过幸运的是，那个INSERT语句所要完成的业务功能只是整个业务环节中的可选功能，开发商也有开关来控制是否启动这个可选功能。虽然这个ORA-600错误，不能很快查到原因，但是却可以通过设置那个业务功能的开关来绕过这个问题。当时是我在现场处理的这个问题，从接到问题报告到解决问题，只花了很短的时间。那为什么整个故障历时了2小时。其主要原因在于，这个客户没有有效的监控手段，来监控错误，完全靠业务人员的反映，而业务人员又不能很快地发现问题。

事后检查错误出现的原因，发现是INSERT语句时，维护一个索引出现了索引，在做索引节点块分裂时报了ORA-600[kcbget_24]错误。ORA-600错误基本上是由BUG或数据损坏引起的，但BUG引起的可能性更大。那为什么之前好好的，怎么突然就出现错误了，再进一步追查发现出现问题的索引是新建的索引，而建这个索引的，是开发商的一个开发人员，未经过流程，就直接在表上建了。结果索引一建好，就出现问题了。

这里我想说的是，做DBA工作，不能有任何侥幸心理。这次发生的事故，是ORACLE的BUG引起，但是如果之前有过充分的测试，按流程来操作，很可能就分避免了这个问题的产生。对一个复杂的系统的维护，技术或许比较重要，但是我认为，流程和测试更重要。

这件事也让我想起2年前，我还在上一家单位（相对目前的工作性质来说是甲方）时，一个非常重要的业务系统，在一个非常重要的时间，崩溃了，完全不能用。这套系统本来还有一个月就功成身退，被新的业务系统所代替，结果最后一班岗也没站好，潜伏的一个致命的BUG爆发了（不是数据库软件的BUG,是业务软件的BUG）。头一天晚上系统的配置数据做了改动，按正常的流程是需要测试的，或许业务人员认为，配置的改动是常有的事，不需要测试，结果忽略了测试，结果第二天…..

工作中的某些环节，比如测试，是枯燥的，但是实在是不可或缺的。

有下面一段SQL脚本，朋友们看能不能找出问题所在？

create table t1_bak as select * from t1 order by col_1,col_2;
truncate table t1;
insert /*+ append */ into t1 select * from t1_bak;

先不看这段SQL代码的效率如何，我们来关注一下这段代码存在的严重的安全问题。

这段代码从语法上看完全没有问题，然而….
假如这段代码是用sqlplus来运行，而第1条create table语句由于空间不足，或者由于数据量太大，临时表空间不够，排序出错，那么t1_bak的创建就会失败，而紧接着，t1会被truncate掉，结果可想而知。

这不是我临时想来的问题，而是真真实实发生在现实中的。现实中发生的这件事，比我提到的隐含的问题就明显，就是第1条create table语句，存在语法问题，结果，表被truncate了，数据丢失了。

仔细考虑维护脚本，甚为重要。

与本系列的前几篇不同，本文将在RAC上测试TAF的一些特性。而测试环境又有所不同：运行于Red Hat Enterprise Linux 5上的Oracle 10.2.0.1，客户端为Windows上的10.2.0.1。在客户端的TNSNAME配置如下：

DMDB =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.81)(PORT = 1521))
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.82)(PORT = 1521))      
    )
    (CONNECT_DATA =
      (SERVICE_NAME = dmdb)
      (FAILOVER_MODE =
        (TYPE = SELECT)
        (METHOD = BASIC)
        (RETRIES = 180) (DELAY = 5)         
      )      
    )
  )

我们使用sqlplus连接到数据库中（为节省篇幅，对部分无关紧要的输出做了剪裁）：

D:\>sqlplus test/test@dmdb
连接到:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, Real Application Clusters, OLAP and Data Mining options

由于负载均衡的作用，我们需要确定会话连接的实例（节点），下面的输出给出了当前会话连接的节点和会话信息：

SQL> show parameter instance_name

NAME                                 TYPE        VALUE
------------------------------------ ----------- -------
instance_name                        string      rac2

SQL> select sid from v$mystat where rownum=1;

       SID
----------
       147
SQL> select failover_type,failover_method,failed_over from v$session where sid=147;

FAILOVER_TYPE FAILOVER_M FAILED_OVE
------------- ---------- ----------
SELECT        BASIC      NO      

从上面输出的结果中的最后几行可以看出，会话已经启用了TAF。

现在将节点2上的实例（也就是rac2）关闭，在sqlplus依次执行下面的命令，得到的结果如下：

SQL> show parameter instance_name

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------
instance_name                        string      rac1

SQL> select sid from v$mystat where rownum=1;

       SID
----------
       146
       
SQL> select failover_type,failover_method,failed_over from v$session where sid=146;

FAILOVER_TYPE FAILOVER_M FAILED_OVE
------------- ---------- ----------       
SELECT        BASIC      YES

从结果来看，会话已经顺利地failover到了第1个节点（rac1）上。

在接下来的测试中，为了避免服务器端的自动均衡对测试造成的干扰，我们将两个实例的remote_listener参数设置为空，并使用lsnrctl services命令确认设置已经生效：

SQL> alter system set remote_listener=” sid=’rac1′;

System altered.

SQL> alter system set remote_listener=” sid=’rac2′;

System altered.

同时将客户端tnsname设置中原来的两个IP地址改为一个IP地址，即将：

(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.81)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.82)(PORT = 1521))

改为：

(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.81)(PORT = 1521))

退出sqlplus，再次运行sqlplus，进行跟上面同样的测试：
Read the rest of this entry »

最近有两次Oracle数据库故障与防火墙有关。这里的防火墙是硬件网络防火墙，而不是软件防火墙。

先说说简单的。一个运行在Windows系统上的Oracle 9i，客户端不能连接数据库，但是用tnsping测试没有问题。解决问题的办法很简单，但是我们仍然需要了解一下引起这个问题的原因。

这个问题首先得从客户通通过监听连接数据库的整个过程说起，此处指专用服务器连接模式：

• 服务器上的监听进程在1521端口上进行侦听
• 客户端发起一个数据库连接请求
• 监听进程fork一个Oracle服务器进程（Server Process），也可称之为影子进程 (Shadow Process）。服务器进程选择一个大于1024的端口号进行侦听，监听进程把这个端口号发回到客户端，要求客户端重新连接这个指定的端口。
• 客户端重新连接监听指定的新端口，也就是重新进行连接。
• 客户端与Server Process直接对话，不再通过监听，进行会话认证（登录），执行SQL等等。

从上述过程可以看到，客户端最终连接的端口实际上并不是1521。由于防火墙一般只开放了几个端口，对Oracle数据库只开放了1521端口，这样在客户端进行第二次连接时，不能通过防火墙，导致连接数据库失败。

值得庆幸的是，只有Windows平台上的9i及以下版本的Oracle才会有这个问题。Oracle在Linux以及Unix平台下，多个进程间可以对端口进行复用，Oracle Server Process仍然使用的是跟监听进程一个端口（1521）。通过在linux使用strace跟踪客户端连接数据库的过程可以发现，客户端只连接了一次，并没有进行第二次连接，与上面描述的流程相比已经发生了变化。在Windows平台上，10g及以上版本的库，也同样利用端口复用，避免了这样的问题。

那么Windows上运行的Oracle 9i怎么解决这个问题呢？答案很简单，在Windows注册表的\HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOMEn（这里n指Oracle Home的序号，只有一个Oracle Home时是0）键下面增加一项USE_SHARED_SOCKET，其值为TRUE。然后重启监听及Oracle服务（注意要重启Oracle的服务，而不仅仅是重启数据库），就可以解决此问题。实际上10g就是默认USE_SHARED_SOCKET为TRUE。

对于这种问题，或者是让防火墙打开针对数据库主机的所有端口访问，也能解决。但是这种方案往往会被负责安全的人否决。

下面这个由防火墙导致的问题，就相对复杂一点了。
Read the rest of this entry »

前两篇文章（TAF PartI和TAF PartII）主要描述了在TAF发生故障转移时正在执行SELECT时的行为。本文将观察当故障转移发生时如果正在执行DML和DDL语句的行为。

本文将继续使用上一篇文章TAF PartII同样的测试环境。

我们先测试当会话update时，在另一个会话立即start force实例：

SQL> update t1 set object_name=lpad(’x',40,’x'),created=sysdate;
update t1 set object_name=lpad(’x',40,’x'),created=sysdate
*
ERROR 位于第 1 行:
ORA-25408: 无法安全重放调用

SQL> select * from dual;

D
-
X

SQL> select failed_over from v$session where sid=(select sid from v$mystat where rownum=1);

FAI
---
YES

可以看到，在数据库实例重启完成后，会话报“ORA-25408: 无法安全重放调用”错误。为什么会报这个错。我的猜测是，由于在FAILOVER后，会话实际上是重新来执行这个SQL，但是DML语句不像SELECT一样，前者是对当前时间点的数据进行修改，保证数据修改是最新的；而SELECT的机制是保证查询的时间点一致，DML语句在重新执行时，当前时间点的数据已经跟上次执行时的数据可能不相同了，不能保证是相同的，也就是“不安全”的。

从上面的输出可以看到，在会话报错之后，仍然可以执行查询，并且从结果来看表明会话是failover后的新会话。注意，ORA-25408这个错误是在failover之后才报的，并不是数据库实例DOWN下后马上就报错。

如果我们在数据库实例级别开启sql trace，在failover后我们可以从trace文件里面可以发现，UPDATE语句并没有再次被解析和执行，而不是在UPDATE重新执行然后报错。

下面我们来看看DDL语句的情况：
Read the rest of this entry »

接上文，在这一节中我们来观察一下使用TAF发生故障转移时，Oracle让Select语句能够继续执行的一些现象。

测试环境跟上文一样，但是TNSNAME配置有些变化，增加了“RETRY”和“DELAY”，增加的选项是为了避免在failover时，如果正在执行SQL，客户端报ORA-03113错误：

XTY =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.114)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = XTY)
      (FAILOVER_MODE =
        (TYPE = SELECT)
        (METHOD = BASIC)
        (RETRIES = 180) (DELAY = 5)         
      )
    )
  )

首先，我们在TEST用户下建一个测试的表，同时将系统的sql_trace参数设置为TRUE：

SQL> create table test.t1 as select * from dba_objects;

Table created.

SQL> alter system set sql_trace=true scope=spfile;

System altered.

在客户端，使用sqlplus连接数据库，连接的用户名为TEST。连接后，执行下面的语句：

SQL> spool 1.txt
SQL> select rownum,object_id,owner,object_name from t1 where rownum< =5000 order by object_id;

在客户端显示输出的过程中，在另一个会话重启数据库：

SQL> startup force;
ORA-32004: obsolete and/or deprecated parameter(s) specified
ORACLE instance started.

Total System Global Area 167772160 bytes
Fixed Size 1266392 bytes
Variable Size 100666664 bytes
Database Buffers 62914560 bytes
Redo Buffers 2924544 bytes
Database mounted.
Database opened.

正在查询T1表的会话，在数据库重启时，会短暂地停止，在我的测试中，停止时显示的输出为：

   1140       1186 SYS                            V_$WAITSTAT

在数据库重启完成后，sqlplus继续输出数据，直到完成所有输出：

1094       1140 SYS                            V_$LOGHIST 
1095       1141 PUBLIC                         V$LOGHIST  
1096       1142 SYS                            V_$SQLAREA 
……（输出很多，略过）…..

我们在生成的sql trace文件中，可以看到下面的内容：

PARSING IN CURSOR #3 len=87 dep=0 uid=55 oct=3 lid=55 tim=1208634047724259 hv=533322034 ad=’2999e344′
select rownum,object_id,owner,object_name from t1 where rownum< =5000 order by object_id
END OF STMT
PARSE #3:c=40994,e=476949,p=301,cr=172,cu=0,mis=1,r=0,dep=0,og=1,tim=1208634047724244
EXEC #3:c=0,e=131,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1208634047724505
FETCH #3:c=12998,e=12276,p=29,cr=64,cu=0,mis=0,r=1,dep=0,og=1,tim=1208634047736908
FETCH #3:c=0,e=50,p=0,cr=0,cu=0,mis=0,r=2,dep=0,og=1,tim=1208634047745324
FETCH #3:c=0,e=36,p=0,cr=0,cu=0,mis=0,r=2,dep=0,og=1,tim=1208634047745861

可以看到，发生会话failover重新连接之后，又重新执行了我们测试的那个SQL。但是输出的结果表明，客户端自动跳过了前面已经得到的数据。

我们继续做下一个测试。这一次我们将SQL修改一下：
Read the rest of this entry »

TAF，透明应用故障转移（Transparent Application Failover），是Oracle数据库提供的一项高可用特性，普遍应用于RAC环境中，当然也可以用于Data Guard和传统的HA实现的主从热备的环境中。

TAF中的Transparent和Failover，点出了这个高可用特性的两大特点：

• TAF是用于故障转移的，也就是切换。当Oracle连接的会话由于数据库发生故障不可用时，会话能够自动切换到RAC中的其他可用的节点上，或者切换到Standby上面，或者切换到HA方式中的另一个可用的节点上面。
• TAF的故障转移，对应用来说是透明的，应用系统不需要进行特别的处理就能够自动进行故障转移。

但是，TAF是完美的吗？是不是使用了TAF，应用就能真的无缝地进行切换呢？对应用和数据库有没有其他什么要求？要回答这些问题，我们需要全面地了解、掌握TAF。我始终认为，要用好一个东西，首先得掌握这个东西背后的工作原理与机制。

首先来看看Failover。Failover有两种，一种是连接时Failover，另一种则是运行时Failover。前者的作用在于，应用（客户端）在连接数据库时，如果由于网络、实例故障等原因，连接不上时，能够连接数据库中的其他实例。后者的作用在于，对于一个已经在工作的会话（也就是连接已经建立），如果这个会话的实例异常中止等，应用（客户端）能够连接到数据库的其他实例（或备用库）。

首先，TAF是ORACLE客户端提供的一项特性。使用TAF，对客户端的环境有一定的要求。比如JAVA的JDBC驱动、Oracle客户端的版本等（8i开始支持TAF）。这个问题将在本系统文章的后面部分详细描述。

下面看一个有趣的例子：
Read the rest of this entry »

在安装oracle时，oracle会提示输入sysdba用户组名，凡是以操作系统认证方式的连接，如果连接的用户在这个指定的用户组中，就可以用sysdba用户登陆。一般情况下，也是建议的sysdba用户组为dba。

有的时候，也存在这样一种情况，安装oracle软件的时候，输入了错误的sysdba用户组名（主要是由于创建oracle用户时指定到了错误的其他用户组中，现实中这种情况曾经出现过）。这样一来，就会导致不规范的安装，或者oracle后来修改回正确的用户组(dba），将导致oracle用户不能以sysdba权限连接数据库，甚至不能启动数据库）。不规范的安装，如果将安装的oracle软件tar到其他机器，会导致那个机器的oracle也出现oracle不能以sysdba连接的问题（有的人安装oracle时，如果有现成的，他就喜欢用tar的方式）。

如果指定了错误的sysdba用户组名，怎么样快捷修改而又不用重新安装oracle软件呢？既然在安装时可以指定，那么一定会有一个地方，存储了这个配置，这个存储的文件就是$ORACLE_HOME/rdbms/lib/config.c。

我们看看config.c这个文件的内容：
[oracle@xty lib]$ cat config.c

/* SS_DBA_GRP defines the UNIX group ID for sqldba adminstrative access. */
/* Refer to the Installation and User’s Guide for further information. */

#define SS_DBA_GRP “dba”
#define SS_OPER_GRP “dba”

char *ss_dba_grp[] = {SS_DBA_GRP, SS_OPER_GRP};

从这个文件中，可以看到SYSDBA的用户组为”dba”，而SYSOPER的用户组也为”dba”。如果我们把#define SS_DBA_GRP “dba”这一行改为#define SS_DBA_GRP “adm”，然后执行下面的命令：relink all，再用oracle用户连接数据库时：

[oracle@xty ~]$ sqlplus /nolog

SQL*Plus: Release 10.2.0.3.0 - Production on Sat Jan 10 15:30:17 2009

Copyright (c) 1982, 2006, Oracle. All Rights Reserved.

SQL> connect / as sysdba
ERROR:
ORA-01031: insufficient privileges

SQL> connect / as sysoper
Connected to an idle instance

可以看到，oracle用户已经不能够用sysdba权限连接到数据库，也就更谈不上启动数据库了。但是由于sysoper的用户组没有改变，所以oracle仍然是可以用sysoper权限连接数据库并启动数据库的。（不过如果我们不使用操作系统认证，比如通过网络连接的方式用SID连接，并提供sys用户的密码，使用密码文件认证，也一样能够使用sysdba权限连接）

如果修改用户oracle的用户组为adm，则可以使用sysdba用户连接了。
[root@xty ~]# usermod -G adm oracle
oracle用户重新登陆到服务器上

[root@xty ~]# su - oracle
[oracle@xty ~]$ sqlplus “/ as sysdba”

SQL*Plus: Release 10.2.0.3.0 - Production on Sat Jan 10 15:42:47 2009

Copyright (c) 1982, 2006, Oracle. All Rights Reserved.

Connected to an idle instance.

最后，我们把config.c修改回原来的值(”dba”)，再relink all，再把oracle的用户组修改回dba，oracle也就恢复了原状。

在数据库服务器上，如果采用操作系统认证，而oracle用户又不能以sysdba权限连接(ORA-01031错误），在其他可能都排除后，有必要检查一下config.c，以确认sysdba用户组是正确的。

前面两篇文章简要介绍了db_block_checking和db_block_checksum参数，并提到这两个参数对性能的影响。下面做个测试：

首先建一个测试表，并设置db_block_checking和db_block_checksum为false：

SQL> create table t2 (a int) tablespace test;

表已创建。
SQL> alter system set db_block_checking=false;

系统已更改。

SQL> alter system set db_block_checksum=false;

向测试表T2中四次分别插入100，000行数据：

SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 06.02
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.02
SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 05.04
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.02
SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

Read the rest of this entry »

在之前的一篇文章db_block_checking和db_block_checksum，简要地描述了db_block_checking和db_block_checksum这两个参数的作用以及性能方面的影响。在10gR1及这前的版本中，这两个参数可以设置为false和true。而在10gR2版本中，这两个参数发生了一点变化。

先来看看db_block_checking，这个参数现在有四个可能的设置：

• OFF - 与原来的FALSE一样，对非SYSTEM表空间的块关闭检查，这个值在设置时仍然可以用false。
• LOW - 只检查块头。这个检查发生在当块的内容在内存中发生改变时，比如UPDATE、INSERT、DELETE等，以及将块从磁盘读入、RAC结点间块的传输。
• MEDIUM - 比LOW更高一级，还包括了非IOT的表的块内部检查（即不仅仅是块头）。
• FULL - 与原来的TRUE一样，与MEDIUM相比，还包括了索引块的检查。

再看看db_block_checksum这个参数有什么变化：

• OFF - 与原来的FALSE一样，只会给SYSTEM表空间的块计算checksum值。
• TYPICAL - 与原来的TRUE一样，Oracle在向磁盘写入块时计算checksum值，下次读入时进行校验。
• FULL - 这是新增的值，Oracle不关在写入块时计算checksum值，而且在更改块（比如执行UPDATE语句等）之前对checksum值进行校验，同时在更改块之后对checksum值进行重新计算。另外Oracle也会在写入日志块时，计算块的checksum。这个设置大大增加了系统负荷，大约带来了4-5%的负荷。而TYPICAL值会带来1-2%的负荷。