data gurad物理备份方式下以READ ONLY/WRITE模式打开物理STANDBY

一、READONLY/WRITE模式打开物理STANDBY

物理standby可以有效分担primary 数据库压力,提升资源利用,实际上说的就是这个。以read
only 或read write 模式打开物理standby,你可以转移一些查询任何啦,
备份之类的操作到standby 数据库,以这种方式来分担一些primary 的压力。
下面我们来演示一下,如何切换standby 数据库的打开模式,其实,非常
简单。例如,以Read-only 模式打开物理standby:
这里要分两种情况:
1).standby 数据库处于shutdown 状态
直接startup 即可。

SQL> startup
ORACLE 例程已经启动。
......

2).standby 数据库处于redo 应用状态。
首先取消redo 应用:

SQL> alter database recover managed standby database cancel;
数据库已更改。

然后再打开数据库

SQL> alter database open ;

数据库已更改。
提示:open 的时候不需要附加read only 子句,oracle 会根据控制文件判断是否是物理standby,从而自
动启动到read only 模式,直接startup 也是同理。

3).如果想从open 状态再切换回redo 应用状态,可以直接启用redo 应用即可,例如:

SQL> select status from v$instance;
STATUS
------------
OPEN
SQL> alter database recover managed standby database disconnect from session;
数据库已更改。

SQL> select status from v$instance;
STATUS
------------
MOUNTED

有时你也可能也要先shutdown再startup mount后再执行

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.

Total System Global Area 6442450944 bytes
Fixed Size                  2030368 bytes
Variable Size            1090520288 bytes
Database Buffers         5335154688 bytes
Redo Buffers               14745600 bytes
Database mounted.
SQL> alter database recover managed standby database disconnect from session;

Database altered.

data gurad物理备份方式中的failover转换

切换分为switchover和failover,前者是无损切换,不会丢失数据,而后者则有可能会丢失数据,并且切换后原primary 数据库也不再是该data guard 配置的一部分了.针对不同standby(逻辑或物理)的处理方式也不尽相同

角色转换前的准备工作
检查各数据库的初始化参数,主要确认对不同角色相关的初始化参数都进行了正确的配置。
确保可能成为primary 数据库的standby 服务器已经处于archivelog 模式。
确保standby 数据库的临时文件存在并匹配primary 数据库的临时文件
确保standby 数据库的RAC 实例只有一个处于open 状态。(对于rac 结构的standby 数据库,在角
色转换时只能有一个实例startup。其它rac 实例必须统统shutdown,待角色转换结束后再startup)

Switchover:
无损转换,通常是用户手动触发或者有计划的让其自动触发,比如硬件升级啦,软件升级啦之类的。
通常它给你带来的工作量非常小并且都是可预计的。其执行分两个阶段,第一步, primary 数据库转换为
standby 角色,第二步,standby 数据库(之一)转换为primary 角色,primary 和standby 只是简单的角色互换.
Failover:
不可预知原因导致primary 数据库故障并且短期内不能恢复就需要failover。
在执行failover 之前,尽可能将原primary 数据库的可用redo 都复制到standby 数据库。
注意,如果要转换角色的standby 处于maximum protection 模式,需要你首先将其切换为maximum
performance模式.转换standby 数据库到MAXIMIZE PERFORMANCE 执行下列SQL 即可:
SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;
等standby 切换为新的primary 之后,你可以再随意更改数据库的保护模式。
maximum protection 模式需要确保绝无数据丢失,因此其对于提交事务对应的redo 数据一致性要求非常高,
另外,如果处于maximum protection 模式下primary 数据库仍然与standby 数据库有数据传输,此时alter
database 语句更改standby 数据库保护模式会失败,这也是由maximum protection 模式特性决定的。

下面演示failover的过程:
一物理standby的failover
注意几点:
failover 之后,原primary 数据库默认不再是data guard 配置的一部分。
多数情况下,其它逻辑/物理standby 数据库不直接参与failover 的过程,
因此这些数据库不需要做任何操作。
某些情况下,新的primary 数据库配置之后,需要重新创建其它所有的standby 数据库。
另外,如果待转换角色的standby 处于maximum protection 或maximum availability 模式的话,
归档日志应该是连续存在的.

一般情况下failover 都是表示primary 数据库瘫痪,因此这种类型的切换基本上不需
要primary数据库做什么操作。
1、检查归档文件是否连续
查询待转换standby 数据库的V$ARCHIVE_GAP 视图,确认归档文件是否连接:

SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
未选定行

如果返回的有记录,按照列出的记录号复制对应的归档文件到待转换的standby 服务器。这一步非常重
要,必须确保所有已生成的归档文件均已存在于standby 服务器,不然可能会数据不一致造成转换时报错。
文件复制之后,通过下列命令将其加入数据字典:

SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filejytest1';

2、检查归档文件是否完整
分别在primary/standby 执行下列语句:

SQL> select distinct thread#,max(sequence#) over(partition by thread#) a from v$archived_log;

该语句取得当前数据库各线程已归档文件最大序号,如果primary 与standby 最大序号不相同,必须将
多出的序号对应的归档文件复制到待转换的standby 服务器。不过既然是failover,有可能primary 数据库此时已经无法打开,甚至无法访问.
3、启动failover执行下列语句:

SQL> alter database recover managed standby database finish force;
数据库已更改。

FORCE 关键字将会停止当前活动的RFS 进程,以便立刻执行failover。
剩下的步骤就与前面switchover 很相似了
4、切换物理standby 角色为primary

SQL> alter database commit to switchover to primary;
数据库已更改。

5、启动新的primary 数据库。
如果当前数据库已mount,直接open 即可,如果处于read-only 模式,需要首先shutdown immediate,然
后再直接startup。

SQL> alter database open;
数据库已更改

角色转换工作完成。剩下的是补救措施(针对原primary 数据库),由于此时primary 数据库已经不再是
data guard配置的一部分,我们需要做的就是尝试看看能否恢复原primary数据库,将其改造为新的standby
服务器。

data guard物理备份方式中的switchover转换

切换分为switchover和failover,前者是无损切换,不会丢失数据,而后者则有可能会丢失数据,并且切换后原primary 数据库也不再是该data guard 配置的一部分了.针对不同standby(逻辑或物理)的处理方式也不尽相同

角色转换前的准备工作
检查各数据库的初始化参数,主要确认对不同角色相关的初始化参数都进行了正确的配置。
确保可能成为primary 数据库的standby 服务器已经处于archivelog 模式。
确保standby 数据库的临时文件存在并匹配primary 数据库的临时文件
确保standby 数据库的RAC 实例只有一个处于open 状态。(对于rac 结构的standby 数据库,在角
色转换时只能有一个实例startup。其它rac 实例必须统统shutdown,待角色转换结束后再startup)

Switchover:
无损转换,通常是用户手动触发或者有计划的让其自动触发,比如硬件升级啦,软件升级啦之类的。
通常它给你带来的工作量非常小并且都是可预计的。其执行分两个阶段,第一步, primary 数据库转换为
standby 角色,第二步,standby 数据库(之一)转换为primary 角色,primary 和standby 只是简单的角色互换.
Failover:
不可预知原因导致primary 数据库故障并且短期内不能恢复就需要failover。
在执行failover 之前,尽可能将原primary 数据库的可用redo 都复制到standby 数据库。
注意,如果要转换角色的standby 处于maximum protection 模式,需要你首先将其切换为maximum
performance模式.转换standby 数据库到MAXIMIZE PERFORMANCE 执行下列SQL 即可:
SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;
等standby 切换为新的primary 之后,你可以再随意更改数据库的保护模式。
maximum protection 模式需要确保绝无数据丢失,因此其对于提交事务对应的redo 数据一致性要求非常高,
另外,如果处于maximum protection 模式下primary 数据库仍然与standby 数据库有数据传输,此时alter
database 语句更改standby 数据库保护模式会失败,这也是由maximum protection 模式特性决定的。

下面演示switchover的过程:
一、物理standby的Switchover
注意操作步骤的先后,很关键的哟。
1、检查是否支持switchover 操作–primary 数据库操作

SQL> select switchover_status from v$database;
SWITCHOVER_STATUS
--------------------
TO STANDBY

在第一次switch的时候看primary上的switchover_status字段上的值是session active。standby上面的该字段的值是not allowed,这个第一次没关系:

NOT ALLOWED - Either this is a standby database and the primary database has
not been switched first, or this is a primary database and there are no standby databases.

SESSIONS ACTIVE - Indicates that there are active SQL sessions attached to
the primary or standby database that need to be disconnected before the
switchover operation is permitted.

SWITCHOVER PENDING - This is a standby database and the primary database
switchover request has been received but not processed.

SWITCHOVER LATENT - The switchover was in pending mode, but did not complete
and went back to the primary database.

TO PRIMARY - This is a standby database, with no active sessions, that is
allowed to switch over to a primary database.

TO STANDBY - This is a primary database, with no active sessions, that is
allowed to switch over to a standby database.

RECOVERY NEEDED - This is a standby database that has not received the
switchover request.

During normal operations it is acceptable to see the following values for
SWITCHOVER_STATUS on the primary to be SESSIONS ACTIVE or TO STANDBY.
During normal operations on the standby it is acceptable to see the values
of NOT ALLOWED or SESSIONS ACTIVE.

2、启动switchover –primary 数据库操作
说明:
主库需要注意事项
A 如果switchover_status为TO_STANDBY说明可以转换
直接转换

alter database commit to switchover to physical standby;

B 如果switchover_status为SESSIONS ACTIVE 则关闭会话

SQL>alter database commit to switchover to physical standby with session shutdown;

在备库中操作,查看备库

SQL> select switchover_status from v$database;

A 如果switchover_status为TO_PRIMARY 说明标记恢复可以直接转换为primary库

SQL>alter database commit to switchover to primary

B 如果switchover_status为SESSION ACTIVE 就应该断开活动会话

SQL>alter database commit to switchover to primary with session shutdown;

C 如果switchover_status为NOT ALLOWED 说明切换标记还没收到,此时不能
执行转换。

首先将primary 转换为standby 的角色,通过下列语句:

[oracle@weblogic28 ~]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.1.0 - Production on Mon Dec 3 10:09:33 2012

Copyright (c) 1982, 2005, Oracle.  All rights reserved.


Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options

SQL> select switchover_status from v$database;

SWITCHOVER_STATUS
--------------------
SESSIONS ACTIVE

SQL> alter database commit to switchover to physical standby with session shutdown;

Database altered.

语句执行完毕后,primary 数据库将会转换为standby 数据库,并自动备份控制文件到trace。

3、重启动到mount –原primary 数据库操作

SQL> shutdown immediate;
ORA-01507: database not mounted


ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.

Total System Global Area 6442450944 bytes
Fixed Size                  2030368 bytes
Variable Size            1090520288 bytes
Database Buffers         5335154688 bytes
Redo Buffers               14745600 bytes
Database mounted.

4、检查是否支持switchover 操作–待转换standby 数据库操作
待原primary 切换为standby 角色之后,检查待转换的standby 数据库switchover_status 列,看看是否支持角色转换。

[oracle@weblogic29 ~]$ sqlplsu /as sysdba
-bash: sqlplsu: command not found
[oracle@weblogic29 ~]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.1.0 - Production on Mon Dec 3 10:09:24 2012

Copyright (c) 1982, 2005, Oracle.  All rights reserved.


Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options

SQL> select switchover_status from v$database;

SWITCHOVER_STATUS
--------------------
TO PRIMARY

此时待转换standby 数据库switchover_status 列值应该是”TO_PRIMARY”,如否则检查其初始化参数文件中的设置,提示一下,比着原primary 数据库的初始化参数改改。

5、转换角色到primary –待转换standby 数据库操作
通过下列语句转换standby 到primary 角色:

SQL> alter database commit to switchover to primary;

Database altered.

注意:待转换的物理standby 可以处于mount 模式或open read only 模式,但不能处于open read write模式。

6、完成转换,打开新的primary 数据库

SQL> alter database open;

Database altered.

注:如果数据库处于open read-only 模式的话,需要先shutdown 然后直接startup 即可。

7、验证一下
新的primary 数据库

SQL> show parameter db_unique

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_unique_name                       string      jyrac1

SQL> alter  system  switch  logfile;

System altered

SQL> select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)
--------------
           140

新的standby 数据库

SQL> show parameter db_unique

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_unique_name                       string      jytest
SQL>

SQL> select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)
--------------
           140

转换成功。

SQL> alter database recover managed standby database disconnect from session;

data guard中增加与删除主备数据库中的联机重做日志与备重做日志文件

原主备数据库中的联机重做日志有3组备重做日志有4组,现在各增加一组

主库操作

1.1 查看redo 信息

SQL> select group#,type, member from v$logfile;

    GROUP# TYPE    MEMBER

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

         3 ONLINE  /u01/app/oracle/oradata/jytest/redo03.log

         2 ONLINE  /u01/app/oracle/oradata/jytest/redo02.log

         1 ONLINE  /u01/app/oracle/oradata/jytest/redo01.log

         4 STANDBY /u01/app/oracle/oradata/jytest/redo04a.log

         4 STANDBY /u01/app/oracle/oradata/jytest/redo04b.log

         5 STANDBY /u01/app/oracle/oradata/jytest/redo05a.log

         5 STANDBY /u01/app/oracle/oradata/jytest/redo05b.log

         6 STANDBY /u01/app/oracle/oradata/jytest/redo06a.log

         6 STANDBY /u01/app/oracle/oradata/jytest/redo06b.log

         7 STANDBY /u01/app/oracle/oradata/jytest/redo07a.log

         7 STANDBY /u01/app/oracle/oradata/jytest/redo07b.log

11 rows selected

 

SQL> select group#,thread#,archived,status, bytes/1024/1024 from v$log;

    GROUP#    THREAD# ARCHIVED STATUS           BYTES/1024/1024

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

         1          1 YES      INACTIVE                      50

         2          1 NO       CURRENT                       50

         3          1 YES      INACTIVE                      50

SQL>

 

1.2 修改standby redo

SQL> ALTER DATABASE drop STANDBY LOGFILE GROUP 4;

Database altered

SQL> ALTER DATABASE drop STANDBY LOGFILE GROUP 5;

Database altered

SQL> ALTER DATABASE drop STANDBY LOGFILE GROUP 6;

Database altered

SQL> ALTER DATABASE drop STANDBY LOGFILE GROUP 7;

Database altered

SQL> select group#,type, member from v$logfile;

    GROUP# TYPE    MEMBER

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

         3 ONLINE  /u01/app/oracle/oradata/jytest/redo03.log

        2 ONLINE  /u01/app/oracle/oradata/jytest/redo02.log

         1 ONLINE  /u01/app/oracle/oradata/jytest/redo01.log

添加standby redo

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 5('/u01/app/oracle/oradata/jytest/redo05.log') SIZE50 M;

Database altered

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 6('/u01/app/oracle/oradata/jytest/redo06.log') SIZE50 M;

Database altered

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 7('/u01/app/oracle/oradata/jytest/redo07.log') SIZE50 M;

Database altered

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 8('/u01/app/oracle/oradata/jytest/redo08.log') SIZE50 M;

Database altered

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 9('/u01/app/oracle/oradata/jytest/redo09.log') SIZE50 M;

Database altered

SQL> select group#,type, member from v$logfile;

    GROUP# TYPE    MEMBER

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

         3 ONLINE  /u01/app/oracle/oradata/jytest/redo03.log

        2 ONLINE  /u01/app/oracle/oradata/jytest/redo02.log

         1 ONLINE  /u01/app/oracle/oradata/jytest/redo01.log

         5 STANDBY /u01/app/oracle/oradata/jytest/redo05.log

         6 STANDBY /u01/app/oracle/oradata/jytest/redo06.log

         7 STANDBY /u01/app/oracle/oradata/jytest/redo07.log

         8 STANDBY /u01/app/oracle/oradata/jytest/redo08.log

9 STANDBY /u01/app/oracle/oradata/jytest/redo09.log

8 rows selected

1.3 修改Online redo

SQL> select group#,thread#,archived,status, bytes/1024/1024 from v$log;

    GROUP#    THREAD# ARCHIVED STATUS           BYTES/1024/1024

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

         1          1 YES      INACTIVE                      50

         2          1 NO       CURRENT                       50

         3          1 YES      INACTIVE                      50

先处理inactive, 它表示已经完成规定的,可以删除。

但要记住必须要保留两组联机重做日志组

SQL> alter database drop logfile group 1;

Database altered

手工的把物理文件删除后,在创建:

SQL> ALTER DATABASE ADD LOGFILE GROUP 1 ('/u01/app/oracle/oradata/jytest/redo01.log')SIZE50 M;

Database altered

SQL> select group#,thread#,archived,status, bytes/1024/1024 from v$log;

    GROUP#    THREAD# ARCHIVED STATUS           BYTES/1024/1024

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

         1          1 YES      UNUSED                        50

         2          1 NO       CURRENT                       50

         3          1 YES      INACTIVE                      50

group1 搞定了。

SQL> ALTER DATABASE ADD LOGFILE GROUP 3 ('/u01/app/oracle/oradata/jytest/redo03.log')SIZE50 M;

Database altered

SQL> select group#,thread#,archived,status, bytes/1024/1024 from v$log;

    GROUP#    THREAD# ARCHIVED STATUS           BYTES/1024/1024

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

         1          1 YES      UNUSED                        50

         2          1 NO       CURRENT                       50

         3          1 YES      UNUSED                        50

Group3 搞定了。

切换一下logfile,在删除group2

SQL> alter system switch logfile;

System altered

SQL> select group#,thread#,archived,status, bytes/1024/1024 from v$log;

    GROUP#    THREAD# ARCHIVED STATUS           BYTES/1024/1024

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

         1          1 NO       CURRENT                       50

         2          1 YES      ACTIVE                        50

         3          1 YES      UNUSED                        50

上面group2正在归档

几分钟之后:

SQL> select group#,thread#,archived,status, bytes/1024/1024 from v$log;

    GROUP#    THREAD# ARCHIVED STATUS           BYTES/1024/1024

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

         1          1 NO       CURRENT                       50

         2          1 YES      INACTIVE                      50

         3          1 YES      UNUSED                        50

SQL>

SQL> alter database drop logfile group 2;

Database altered

手工的把物理文件删除后,在创建:

SQL> ALTER DATABASE ADD LOGFILE GROUP 2 ('/u01/app/oracle/oradata/jytest/redo02.log')SIZE50 M;

Database altered

SQL> ALTER DATABASE ADD LOGFILE GROUP 4 ('/u01/app/oracle/oradata/jytest/redo04.log')SIZE50 M;

Database altered

SQL> select group#,thread#,archived,status, bytes/1024/1024 from v$log;

    GROUP#    THREAD# ARCHIVED STATUS           BYTES/1024/1024

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

         1          1 YES      INACTIVE                      50

         2          1 YES      INACTIVE                      50

         3          1 NO       CURRENT                       50

         4          1 YES      UNUSED                        50

主数据库的日志文件增加与删除操作就完成了

备库操作

2.1 查看日志信息

SQL> select group#,type, member from v$logfile;

    GROUP# TYPE    MEMBER

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

         3 ONLINE  /u01/app/oracle/oradata/jytest/redo03.log

         2 ONLINE  /u01/app/oracle/oradata/jytest/redo02.log

         1 ONLINE  /u01/app/oracle/oradata/jytest/redo01.log

         4 STANDBY /u01/app/oracle/oradata/jytest/redo04a.log

         4 STANDBY /u01/app/oracle/oradata/jytest/redo04b.log

         5 STANDBY /u01/app/oracle/oradata/jytest/redo05a.log

         5 STANDBY /u01/app/oracle/oradata/jytest/redo05b.log

         6 STANDBY /u01/app/oracle/oradata/jytest/redo06a.log

         6 STANDBY /u01/app/oracle/oradata/jytest/redo06b.log

         7 STANDBY /u01/app/oracle/oradata/jytest/redo07a.log

         7 STANDBY /u01/app/oracle/oradata/jytest/redo07b.log

11 rows selected

SQL> select group#,thread#,archived,status, bytes/1024/1024 from v$log;

    GROUP#    THREAD# ARCHIVED STATUS           BYTES/1024/1024

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

         1          1 YES      CLEARING                      50

         3          1 YES      CLEARING_CURRENT              50

         2          1 YES      CLEARING                      50

2.2 处理standby redo

对于standby 上redo的处理之前,我们要先停掉redo 的apply:

SQL> ALTER DATABASE drop STANDBY LOGFILE GROUP 4;

ALTER DATABASE drop STANDBY LOGFILE GROUP 4

ORA-00261: log 4 of thread 1 is being archived or modified

ORA-00312: online log 4 thread 1: '/u01/app/oracle/oradata/jytest/redo04a.log'

ORA-00312: online log 4 thread 1: '/u01/app/oracle/oradata/jytest/redo04b.log'

SQL> select * from v$standby_log;

    GROUP# DBID                                        THREAD#  SEQUENCE#      BYTES       USED ARCHIVED STATUS     FIRST_CHANGE# FIRST_TIME  LAST_CHANGE# LAST_TIME

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

         4 3836176504                                        1        182   52428800    3580928 YES      ACTIVE           1236181 2012-12-4 1      1238785 2012-12-4 1

显示group 4 status为active

SQL> alter database clear  logfile group 4;

Database altered

SQL> select * from v$standby_log;

    GROUP# DBID                                        THREAD#  SEQUENCE#      BYTES       USED ARCHIVED STATUS     FIRST_CHANGE# FIRST_TIME  LAST_CHANGE# LAST_TIME

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

         4 UNASSIGNED                                        1          0   52428800          0 YES      UNASSIGNED       1236181 2012-12-4 1      1239074 2012-12-4 1

SQL> ALTER DATABASE drop STANDBY LOGFILE GROUP 4;

Database altered

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 5('/u01/app/oracle/oradata/jytest/redo05.log') SIZE50 M;

Database altered

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 6('/u01/app/oracle/oradata/jytest/redo06.log') SIZE50 M;

Database altered

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 7('/u01/app/oracle/oradata/jytest/redo07.log') SIZE50 M;

Database altered

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 8('/u01/app/oracle/oradata/jytest/redo08.log') SIZE50 M;

Database altered

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 9('/u01/app/oracle/oradata/jytest/redo09.log') SIZE50 M;

Database altered

SQL> select group#,type, member from v$logfile;

    GROUP# TYPE    MEMBER

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

         3 ONLINE  /u01/app/oracle/oradata/jytest/redo03.log

        2 ONLINE  /u01/app/oracle/oradata/jytest/redo02.log

         1 ONLINE  /u01/app/oracle/oradata/jytest/redo01.log

         5 STANDBY /u01/app/oracle/oradata/jytest/redo05.log

         6 STANDBY /u01/app/oracle/oradata/jytest/redo06.log

         7 STANDBY /u01/app/oracle/oradata/jytest/redo07.log

         8 STANDBY /u01/app/oracle/oradata/jytest/redo08.log

         9 STANDBY /u01/app/oracle/oradata/jytest/redo09.log

8 rows selected

2.3 处理online redo

先将standby_file_management设为手动:

SQL> alter system set standby_file_management='MANUAL' ;

System altered.

SQL> SELECT GROUP#, STATUS FROM V$LOG;

    GROUP# STATUS

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

         1 CLEARING

         3 CLEARING_CURRENT

         2 CLEARING

SQL> ALTER DATABASE ADD LOGFILE GROUP 1 ('/u01/app/oracle/oradata/jytest/redo01.log')SIZE50 M;

Database altered

SQL> alter database clear logfile group 2;

Database altered

SQL> alter database drop logfile group 2;

Database altered

SQL> ALTER DATABASE ADD LOGFILE GROUP 2 ('/u01/app/oracle/oradata/jytest/redo02.log')SIZE50 M;

Database altered

SQL> SELECT GROUP#, STATUS FROM V$LOG;

    GROUP# STATUS

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

         1 UNUSED

         3 CLEARING_CURRENT

         2 UNUSED

还有最后一个redo 组没有处理,这个要先切换过来:

(1)在备库启动recover 进程:

SQL> alter database recover managed standby database disconnect from session;

 

Database altered.

 

SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT='AUTO';

 

System altered.

 

(2)到主库手动切换几次redo

SQL> alter system switch logfile;

System altered.

SQL> alter system switch logfile;

System altered.

在查看备库的redo:

SQL> SELECT GROUP#, STATUS FROM V$LOG;

    GROUP# STATUS

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

         1 UNUSED

         3 CLEARING

         2 CLEARING_CURRENT

原来group3已经变成clearing了

SQL> alter database clear logfile group 3;

Database altered

SQL> alter database drop logfile group 3;

Database altered

SQL> ALTER DATABASE ADD LOGFILE GROUP 3 ('/u01/app/oracle/oradata/jytest/redo03.log')SIZE50 M;

Database altered

SQL> ALTER DATABASE ADD LOGFILE GROUP 4 ('/u01/app/oracle/oradata/jytest/redo04.log')SIZE50 M;

Database altered

查看:

SQL> select group#,thread#,archived,status, bytes/1024/1024 from v$log;

    GROUP#    THREAD# ARCHIVED STATUS           BYTES/1024/1024

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

         1          1 YES      UNUSED                        50

         4          1 YES      UNUSED                        50

         3          1 YES      UNUSED                        50

         2          1 YES      CLEARING_CURRENT              50

SQL> select group#,type, member from v$logfile;

    GROUP# TYPE    MEMBER

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

         3 ONLINE  /u01/app/oracle/oradata/jytest/redo03.log

         2 ONLINE  /u01/app/oracle/oradata/jytest/redo02.log

         1 ONLINE  /u01/app/oracle/oradata/jytest/redo01.log

         5 STANDBY /u01/app/oracle/oradata/jytest/redo05.log

         6 STANDBY /u01/app/oracle/oradata/jytest/redo06.log

         7 STANDBY /u01/app/oracle/oradata/jytest/redo07.log

         8 STANDBY /u01/app/oracle/oradata/jytest/redo08.log

         9 STANDBY /u01/app/oracle/oradata/jytest/redo09.log

         4 ONLINE  /u01/app/oracle/oradata/jytest/redo04.log

9 rows selected

搞定,最后启动recover,验证:

SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT='AUTO';

 

System altered.

 

SQL> alter database recover managed standby database disconnect from session;

 

Database altered.

 

主库:

SQL> alter system switch logfile;

System altered.

SQL> alter system switch logfile;

System altered.

 

SQL> select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)

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

           185

备库:

SQL> select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)

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

           185

同步了

oracle10g data guard 主备数据库配置参数说明

oracle10g data guard 主备数据库配置参数说明:

下列参数为primary角色相关的初始化参数:
DB_NAME 注意保持同一个Data Guard中所有数据库DB_NAME相同。

例如:DB_NAME=jytest

DB_UNIQUE_NAME 为每一个数据库指定一个唯一的名称,该参数一经指定不会再发生变化,

除非你主动修改它。

例如:DB_UNIQUE_NAME=jytest

LOG_ARCHIVE_CONFIG 该参数通过DG_CONFIG属性罗列同一个Data Guard中所有

DB_UNIQUE_NAME(含primary db及standby db),以逗号分隔

例如:LOG_ARCHIVE_CONFIG=’DB_CONFIG=(jytest,jyrac1)’

CONTROL_FILES 没啥说的,控制文件所在路径。
LOG_ARCHIVE_DEST_n 归档文件的生成路径。该参数非常重要,并且属性和子参数也特别多(这里

不一一列举,后面用到时单独讲解如果你黑好奇,建议直接查询oracle

方文档。Data guard白皮书第14章专门介绍了该参数各属性及子参数的功

能和设置)。例如:

LOG_ARCHIVE_DEST_1=’LOCATION=/u01/app/oracle/arch/jytest VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=jytest’

LOG_ARCHIVE_DEST_STATE_n 指定参数值为ENABLE,允许redo传输服务传输redo数据到指定的路径。

该参数共拥有4个属性值,功能各不相同。

REMOTE_LOGIN_PASSWORDFILE 推荐设置参数值为EXCLUSIVE或者SHARED,注意保证相同Data Guard

配置中所有db服务器sys密码相同。

LOG_ARCHIVE_FORMAT 指定归档文件格式。
LOG_ARCHIVE_MAX_PRODUCESSES 指定归档进程的数量(1-30),默认值通常是4。
以下参数为standby角色相关的参数,建议在Primary数据库的初始化参数中也进行设置,这样在role transition

后(Primary转为Standby)也能正常运行:

FAL_SERVER 指定一个数据库的DB_UNIQUE_NAME,通常该库为primary角色。

例如:FAL_SERVER=jytest

FAL_CLIENT 指定一个数据库的DB_UNIQUE_NAME,通常该库为standby角色。

例如:FAL_CLIENT=jyrac1

提示:FAL是Fetch Archived Log的缩写

DB_FILE_NAME_CONVERT 在做duplicate复制和传输表空间的时候这类参数讲过很多遍,该参数及上

述内容中同名参数功能,格式等完全相同。

LOG_FILE_NAME_CONVERT 同上
STANDBY_FILE_MANAGEMENT 如果primary数据库数据文件发生修改(如新建,重命名等)则按照本参数

的设置在standby中做相应修改。设为AUTO表示自动管理。设为MANUAL

表示需要手工管理。

例如:STANDBY_FILE_MANAGEMENT=AUTO

expdp与impdp例子

CREATE OR REPLACE DIRECTORY dir_dump  AS '/u01/RLZY/';



GRANT read,write ON DIRECTORY dir_dump TO public;

C:\Documents and Settings\Administrator>expdp insur_backup/backup@rlzy directory
=dir_dump dumpfile=backupchangde.dmp logfile=backupchangde.log


将insur_backup(cdcs表空间)用户的对象导入insur_test(hygeiatest表空间)
C:\Documents and Settings\Administrator>impdp insur_backup/backup@rlzy directory
=dir_dump dumpfile=backupchangde.dmp remap_schema=insur_backup:insur_test remap_
tablespace=cdcs:hygeiatest logfile=impjy.log parallel=2

V$SESSION_LONGOPS

V$SESSION_LONGOPS视图记录了执行时间长于6秒的某个操作(这些操作可能是备份,恢复,Hash Join,Sort ,Nested loop,Table Scan, Index Scan 等等)。

要想V$SESSION_LONGOPS视图中有记录
1.必须将初始化参数 timed_statistics设置为true或者开启sql_trace
2.必须用ANALYZE或者DBMS_STATS对对象收集过统计信息
要理解的就是:比如某个SQL语句执行时间比较长,但是每个操作都没有超过6秒钟,那么你在V$SESSION_LONGOPS这个视图中就无法查询到该信息。还有一点就是,即使某个操作完成了,你在该视图中也可能查询到该操作依然记录在视图中。
这个视图通常用来分析SQL运行缓慢的原因,配合V$SESSION视图。
下面的查询显示未完成操作的信息

col start_time format a20
col last_update_time a30
select sid,message, start_time,last_update_time,time_remaining,
elapsed_seconds from V$SESSION_LONGOPS where time_remaining>0;

如果是RAC:

col start_time format a20
col last_update_time a30
select inst_id,sid,message, start_time,last_update_time,time_remaining,
elapsed_seconds from GV$SESSION_LONGOPS where time_remaining>0;

oracle v$sysstat性能视图

V$SYSSTAT中包含多个统计项,这部分介绍了一些关键的v$sysstat统计项,在调优方面相当有用。下列按字母先后排序:

数据库使用状态的一些关键指标:

        CPU used by this session:所有session的cpu占用量,不包括后台进程。这项统计的单位是百分之x秒.完全调用一次不超过10ms

        db block changes:那部分造成SGA中数据块变化的insert,update或delete操作数 这项统计可以大概看出整体数据库状态。在各项事务级别,这项统计指出脏缓存比率。

        execute count:执行的sql语句数量(包括递归sql)

        logons current:当前连接到实例的Sessions。如果当前有两个快照则取平均值。

        logons cumulative:自实例启动后的总登陆次数。

        parse count (hard):在shared pool中解析调用的未命中次数。当sql语句执行并且该语句不在shared pool或虽然在shared pool但因为两者存在部分差异而不能被使用时产生硬解析。如果一条sql语句原文与当前存在的相同,但查询表不同则认为它们是两条不同语句,则硬解析即会发生。硬解析会带来cpu和资源使用的高昂开销,因为它需要oracle在shared pool中重新分配内存,然后再确定执行计划,最终语句才会被执行。

        parse count (total):解析调用总数,包括软解析和硬解析。当session执行了一条sql语句,该语句已经存在于shared pool并且可以被使用则产生软解析。当语句被使用(即共享) 所有数据相关的现有sql语句(如最优化的执行计划)必须同样适用于当前的声明。这两项统计可被用于计算软解析命中率。

        parse time cpu:总cpu解析时间(单位:10ms)。包括硬解析和软解析。

        parse time elapsed:完成解析调用的总时间花费。

        physical reads:OS blocks read数。包括插入到SGA缓存区的物理读以及PGA中的直读这项统计并非i/o请求数。

        physical writes:从SGA缓存区被DBWR写到磁盘的数据块以及PGA进程直写的数据块数量。

        redo log space requests:在redo logs中服务进程的等待空间,表示需要更长时间的log switch。

        redo size:redo发生的总次数(以及因此写入log buffer),以byte为单位。这项统计显示出update活跃性。

        session logical reads:逻辑读请求数。

        sorts (memory) and sorts (disk):sorts(memory)是适于在SORT_AREA_SIZE(因此不需要在磁盘进行排序)的排序操作的数量。sorts(disk)则是由于排序所需空间太大,SORT_AREA_SIZE不能满足而不得不在磁盘进行排序操作的数量。这两项统计通常用于计算in-memory sort ratio。

        sorts (rows): 列排序总数。这项统计可被'sorts (total)'统计项除尽以确定每次排序的列。该项可指出数据卷和应用特征。

        table fetch by rowid:使用ROWID返回的总列数(由于索引访问或sql语句中使用了'where rowid=&rowid'而产生)

        table scans (rows gotten):全表扫描中读取的总列数

        table scans (blocks gotten):全表扫描中读取的总块数,不包括那些split的列。

        user commits + user rollbacks:系统事务起用次数。当需要计算其它统计中每项事务比率时该项可以被做为除数。例如,计算事务中逻辑读,可以使用下列公式:session logical reads / (user commits + user rollbacks)。


注:SQL语句的解析有软解析soft parse与硬解析hard parse之说,以下是5个步骤:

1:语法是否合法(sql写法)

2:语义是否合法(权限,对象是否存在)

3:检查该sql是否在公享池中存在

— 如果存在,直接跳过4和5,运行sql. 此时算soft parse

4:选择执行计划

5:产生执行计划

— 如果5个步骤全做,这就叫hard parse.

注意物理I/O

  oracle报告物理读也许并未导致实际物理磁盘I/O操作。这完全有可能因为多数操作系统都有缓存文件,可能是那些块在被读取。块也可能存于磁盘或控制级缓存以再次避免实际I/O。Oracle报告有物理读也许仅仅表示被请求的块并不在缓存中。

由V$SYSSTAT得出实例效率比(Instance Efficiency Ratios)

下列是些典型的instance efficiency ratios 由v$sysstat数据计算得来,每项比率值应该尽可能接近1:

Buffer cache hit ratio:该项显示buffer cache大小是否合适。

公式:

1-((physical reads-physical reads direct-physical reads direct (lob)) / session logical reads)

执行:

select 1-((a.value-b.value-c.value)/d.value)

 from v$sysstat a,v$sysstat b,v$sysstat c,v$sysstat d

 where a.name='physical reads' and

         b.name='physical reads direct' and

         c.name='physical reads direct (lob)' and

         d.name='session logical reads';



       Soft parse ratio:这项将显示系统是否有太多硬解析。该值将会与原始统计数据对比以确保精确。例如,软解析率仅为0.2则表示硬解析率太高。不过,如果总解析量(parse count total)偏低,这项值可以被忽略。

公式:1 - ( parse count (hard) / parse count (total) )

执行:

select 1-(a.value/b.value)

 from v$sysstat a,v$sysstat b

 Where a.name='parse count (hard)' and b.name='parse count (total)';



      In-memory sort ratio:该项显示内存中完成的排序所占比例。最理想状态下,在OLTP系统中,大部分排序不仅小并且能够完全在内存里完成排序。

公式:sorts (memory) / ( sorts (memory) + sorts (disk) )

执行:

select a.value/(b.value+c.value)

 from v$sysstat a,v$sysstat b,v$sysstat c

 where a.name='sorts (memory)' and

         b.name='sorts (memory)' and c.name='sorts (disk)';



    Parse to execute ratio:在生产环境,最理想状态是一条sql语句一次解析多数运行。

公式:1 - (parse count/execute count)

执行:

select 1-(a.value/b.value)

 from v$sysstat a,v$sysstat b

 where a.name='parse count (total)' and b.name='execute count';



      Parse CPU to total CPU ratio:该项显示总的CPU花费在执行及解析上的比率。如果这项比率较低,说明系统执行了太多的解析。

公式:1 - (parse time cpu / CPU used by this session)

执行:

select 1-(a.value/b.value)

 from v$sysstat a,v$sysstat b

 where a.name='parse time cpu' and

         b.name='CPU used by this session';



   Parse time CPU to parse time elapsed:通常,该项显示锁竞争比率。这项比率计算

是否时间花费在解析分配给CPU进行周期运算(即生产工作)。解析时间花费不在CPU周期运算通常表示由于锁竞争导致了时间花费

公式:parse time cpu / parse time elapsed

执行:

select a.value/b.value

 from v$sysstat a,v$sysstat b

 where a.name='parse time cpu' and b.name='parse time elapsed';



从V$SYSSTAT获取负载间档(Load Profile)数据



  负载间档是监控系统吞吐量和负载变化的重要部分,该部分提供如下每秒和每个事务的统计信息:logons cumulative, parse count (total), parse count (hard), executes, physical reads, physical writes, block changes, and redo size.



  被格式化的数据可检查'rates'是否过高,或用于对比其它基线数据设置为识别system profile在期间如何变化。例如,计算每个事务中block changes可用如下公式:

db block changes / ( user commits + user rollbacks )

执行:

select a.value/(b.value+c.value)

 from v$sysstat a,v$sysstat b,v$sysstat c

 where a.name='db block changes' and

         b.name='user commits' and c.name='user rollbacks';





其它计算统计以衡量负载方式,如下:

     Blocks changed for each read:这项显示出block changes在block reads中的比例。它将指出是否系统主要用于只读访问或是主要进行诸多数据操作(如:inserts/updates/deletes)

公式:db block changes / session logical reads

执行:

select a.value/b.value

 from v$sysstat a,v$sysstat b

 where a.name='db block changes' and

         b.name='session logical reads' ;



      Rows for each sort:

公式:sorts (rows) / ( sorts (memory) + sorts (disk) )

执行:

select a.value/(b.value+c.value)

 from v$sysstat a,v$sysstat b,v$sysstat c

 where a.name='sorts (rows)' and

 b.name='sorts (memory)' and c.name='sorts (disk)';
 

DBMS_STATS.GATHER_SCHEMA_STATS介绍使用

dbms_stats能良好地估量统计数据(尤其是针对较大的分区表),并能取得更好的统计后果,最终制订出速度更快的SQL施行计划。

  exec dbms_stats.gather_schema_stats(
  ownname          => 'SCOTT',
  options          => 'GATHER AUTO',
  estimate_percent => dbms_stats.auto_sample_size,
  method_opt       => 'for all columns size repeat',
  degree           => 15
  )

为了充沛认识dbms_stats的益处,需要仔细领会每一条次要的预编译指令(directive)。上面让咱们钻研每一条指令,并领会如何用它为基于代价的SQL优化器搜罗最高品质的统计数据。
  options参数
  使用4个预设的法子之一,这个选项能把握Oracle统计的刷新方法:
  gather——重新剖析整个架构(Schema)。
  gather empty——只剖析目前还没有统计的表。
  gather stale——只重新剖析修改量超过10%的表(这些修改包含拔出、更新和删除)。
  gather auto——重新剖析以后没有统计的对象,以及统计数据过期(变脏)的对象。注意,使用gather auto相似于组合使用gather stale和gather empty。
  注意,不论gather stale仍是gather auto,都请求进行监视。假如你施行一个alter table xxx monitoring命令,Oracle会用dba_tab_modifications视图来跟踪发生发火变动的表。这样一来,你就确实地知道,自从上 一次剖析统计数据以来,发生发火了多少次拔出、更新和删除操作。

  estimate_percent选项
  estimate_percent参数是一种比照新的设计,它答应Oracle的dbms_stats在搜罗统计数据时,自动估量要采样的一个segment的最佳百分比:
  estimate_percent => dbms_stats.auto_sample_size
  要考证自动统计采样的准确性,你可检视dba_tables sample_size列。一个有趣的地方是,在使用自动采样时,Oracle会为一个样本尺寸挑选5到20的百分比。记住,统计数据品质越好,CBO做出的抉择越好。

  method_opt选项
  method_opt:for table –只统计表
  for all indexed columns –只统计有索引的表列
  for all indexes –只剖析统计相干索引
  for all columns
  dbms_stats的method_opt参数尤其合适在表和索引数据发生发火变动时刷新统计数据。method_opt参数也合适用于判断哪些列需要直方图(histograms)。
  某些情形下,索引内的各个值的散播会影响CBO是使用一个索引仍是施行一次全表扫描的决议计划。例如,假如在where子句中指定的值的数量不合错误称,全表扫描就显得比索引走访更经济。
  假如你有一个高度歪斜的索引(某些值的行数不合错误称),就可创建Oracle直方图统计。但在现实世界中,出现这种情形的机率相称小。使用 CBO时,最罕见的过失之一就是在CBO统计中不用要地引入直方图。根据经验,只需在列值请求必需修改施行计划时,才应使用直方图。
  为了智能地生成直方图,Oracle为dbms_stats准备了method_opt参数。在method_opt子句中,还有一些首要的新选项,包含skewonly,repeat和auto:
  method_opt=>’for all columns size skewonly’
  method_opt=>’for all columns size repeat’
  method_opt=>’for all columns size auto’

  skewonly选项会耗损大量处置时间,因为它要检查每个索引中的每个列的值的散播情形。
  假如dbms_stat觉察一个索引的各个列散播得不均匀,就会为那个索引创建直方图,辅助基于代价的SQL优化器抉择是进行索引走访,仍是进行全表 扫描走访。例如,在一个索引中,假设有一个列在50%的行中,如清单B所示,那么为了检索这些行,全表扫描的速度会快于索引扫描。
  –*************************************************************
  – SKEWONLY option—Detailed analysis
  –
  – Use this method for a first-time analysis for skewed indexes
  – This runs a long time because all indexes are examined
  –*************************************************************

  
    begin
  dbms_stats.gather_schema_stats(
  ownname          => 'SCOTT',
  estimate_percent => dbms_stats.auto_sample_size,
  method_opt       => 'for all columns size skewonly',
  degree           => 7
  );
  end;

  重新剖析统计数据时,使用repeat选项,重新剖析义务所耗费的资源就会少一些。使用repeat选项(清单C)时,只会为现有的直方图重新剖析索引,不再搜寻其余直方图机会。活期重新剖析统计数据时,你应当采用这种方法。
  –*************************************************************
  – REPEAT OPTION – Only reanalyze histograms for indexes
  – that have histograms
  –
  – Following the initial analysis, the weekly analysis
  – job will use the “repeat” option. The repeat option
  – tells dbms_stats that no indexes have changed, and
  – it will only reanalyze histograms for
  – indexes that have histograms.
  –**************************************************************

  begin
  dbms_stats.gather_schema_stats(
  ownname          => 'SCOTT',
  estimate_percent => dbms_stats.auto_sample_size,
  method_opt       => 'for all columns size repeat',
  degree           => 7
  );
  end;

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

Exec dbms_stats.gather_schema_stats(ownname=>'用户名称',estimate_percent=>100,cascade=> TRUE, degree =>12);

DBMS_STATS.GATHER_TABLE_STATS详解

由于Oracle的优化器是CBO,所以对象的统计数据对执行计划的生成至关重要!

作用:DBMS_STATS.GATHER_TABLE_STATS统计表,列,索引的统计信息(默认参数下是对表进行直方图信息收集,包含该表的自身-表的行数、数据块数、行长等信息;列的分析–列值的重复数、列上的空值、数据在列上的分布情况;索引的分析-索引页块的数量、索引的深度、索引聚合因子).
DBMS_STATS.GATHER_TABLE_STATS的语法如下:

DBMS_STATS.GATHER_TABLE_STATS ( ownname VARCHAR2,  tabname VARCHAR2,  partname VARCHAR2, estimate_percent NUMBER,  block_sample BOOLEAN, method_opt VARCHAR2, degree NUMBER, granularity VARCHAR2,  cascade BOOLEAN, stattab VARCHAR2,  statid VARCHAR2, statown VARCHAR2, no_invalidate BOOLEAN, force BOOLEAN);

参数说明:

ownname:要分析表的拥有者

tabname:要分析的表名.

partname:分区的名字,只对分区表或分区索引有用.

estimate_percent:采样行的百分比,取值范围[0.000001,100],null为全部分析,不采样. 常量:DBMS_STATS.AUTO_SAMPLE_SIZE是默认值,由oracle决定最佳取采样值.

block_sapmple:是否用块采样代替行采样.

method_opt:决定histograms信息是怎样被统计的.method_opt的取值如下(默认值为FOR ALL COLUMNS SIZE AUTO):

for all columns:统计所有列的histograms.

for all indexed columns:统计所有indexed列的histograms.

for all hidden columns:统计你看不到列的histograms

for columns SIZE | REPEAT | AUTO | SKEWONLY:统计指定列的histograms.N的取值范围[1,254]; REPEAT上次统计过的histograms;AUTO由oracle决定N的大小;SKEWONLY multiple end-points with the same value which is what we define by “there is skew in thedata

degree:决定并行度.默认值为null.

granularity:Granularity of statistics to collect ,only pertinent if the table is partitioned.

cascade:是收集索引的信息.默认为FALSE.

stattab:指定要存储统计信息的表,statid如果多个表的统计信息存储在同一个stattab中用于进行区分.statown存储统计信息表的拥有者.以上三个参数若不指定,统计信息会直接更新到数据字典.

no_invalidate: Does not invalidate the dependent cursors if set to TRUE. The procedure invalidates the dependent cursors immediately if set to FALSE.

force:即使表锁住了也收集统计信息.

例子:

execute dbms_stats.gather_table_stats(ownname => 'owner',tabname => 'table_name' ,estimate_percent => null ,method_opt => 'for all indexed columns' ,cascade => true);

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

自从Oracle8.1.5引入dbms_stats包,Experts们便推荐使用dbms_stats取代analyze。 理由如下
dbms_stats可以并行分析
dbms_stats有自动分析的功能(alter table monitor )
analyze 分析统计信息的不准确some times
1,2好理解,且第2点实际上在VLDB中是最吸引人的;3以前比较模糊,看了metalink236935.1 解释,analyze在分析Partition表的时候,有时候会计算出不准确的Global statistics .
原因是,dbms_stats会实在的去分析表全局统计信息(当指定参数);而analyze是将表分区(局部)的statistics 汇总计算成表全局statistics ,可能导致误差。
如果想分析整个用户或数据库,还可以采用工具包,可以并行分析
Dbms_utility(8i以前的工具包)
Dbms_stats(8i以后提供的工具包)

dbms_stats.gather_schema_stats(User,estimate_percent=>100,cascade=> TRUE);
dbms_stats.gather_table_stats(User,TableName,degree => 4,cascade => true);

如何使用dbms_stats分析统计信息

--创建统计信息历史保留表

sql>execdbms_stats.create_stat_table(ownname=>'scott',stattab=>'stat_table');

--导出整个scheme的统计信息

sql>execdbms_stats.export_schema_stats(ownname=>'scott',stattab=>'stat_table');

--分析scheme

Execdbms_stats.gather_schema_stats(
ownname=>'scott',
options=>'GATHERAUTO',
estimate_percent=>dbms_stats.auto_sample_size,
method_opt=>'forallindexedcolumns',
degree=>6)

--分析表

sql>execdbms_stats.gather_table_stats(ownname=>'scott',tabname=>'work_list',estimate_percent=>10,method_opt=>'forallindexedcolumns');

--分析索引

SQL>execdbms_stats.gather_index_stats(ownname=>'crm2',indname=>'IDX_ADM_PERMISSION_PID_MID',estimate_percent=>'10',degree=>'4');

--如果发现执行计划走错,删除表的统计信息

SQL>dbms_stats.delete_table_stats(ownname=>'scott',tabname=>'work_list');

--导入表的历史统计信息

sql>execdbms_stats.import_table_stats(ownname=>'scott',tabname=>'work_list',stattab=>'stat_table');

--如果进行分析后,大部分表的执行计划都走错,需要导回整个scheme的统计信息

sql>execdbms_stats.import_schema_stats(ownname=>'scott',stattab=>'stat_table');

--导入索引的统计信息

SQL>execdbms_stats.import_index_stats(ownname=>'crm2',indname=>'IDX_ADM_PERMISSION_PID_MID',stattab=>'stat_table')

--检查是否导入成功

SQL>selecttable_name,num_rows,a.blocks,a.last_analyzedfromall_tablesawherea.table_name='WORK_LIST';

分析数据库(包括所有的用户对象和系统对象):gather_database_stats
分析用户所有的对象(包括表、索引、簇):gather_schema_stats
分析表:gather_table_stats
分析索引:gather_index_stats
删除数据库统计信息:delete_database_stats
删除用户方案统计信息:delete_schema_stats
删除表统计信息:delete_table_stats
删除索引统计信息:delete_index_stats
删除列统计信息:delete_column_stats
设置表统计信息:set_table_stats
设置索引统计信息:set_index_stats
设置列统计信息:set_column_stats

可以查看表 DBA_TABLES来查看表是否与被分析过,如:

SELECT TABLE_NAME, LAST_ANALYZED FROM DBA_TABLES

这是对命令与工具包的一些总结
1、对于分区表,建议使用DBMS_STATS,而不是使用Analyze语句。
a) 可以并行进行,对多个用户,多个Table
b) 可以得到整个分区表的数据和单个分区的数据。
c) 可以在不同级别上Compute Statistics:单个分区,子分区,全表,所有分区
d) 可以倒出统计信息
e) 可以用户自动收集统计信息
2、DBMS_STATS的缺点
a) 不能Validate Structure
b) 不能收集CHAINED ROWS, 不能收集CLUSTER TABLE的信息,这两个仍旧需要使用Analyze语句。
c) DBMS_STATS 默认不对索引进行Analyze,因为默认Cascade是False,需要手工指定为True
3、对于oracle 9里面的External Table,Analyze不能使用,只能使用DBMS_STATS来收集信息。