ORACLE db top 命令(oratop)

联系:手机/微信(+86 17813235971) QQ(107644445)

标题:ORACLE db top 命令(oratop)

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

oracle 也推出来了数据库的top命令,叫做oratap,是使用c语言写的,目前只支持linux x86与x64的11gR2与12cR1
使用说明

[oracle@xifenfei tmp]$ ./oratap  -h
oratop: Release 13.2.4
Usage:
         oratop [ [Options] [Logon] ]
         Logon:
                {username[/password][@connect_identifier] | / }
                [AS {SYSDBA|SYSOPER}]
         Options:
             -i : Interval Delay (requires value in seconds, default: 3s)
             -f : Long format for header & section 4 (default: 80 column)
             -r : IORL mode for Section 2 (default is IOPS)
             -d : Real-Time Top 5 Wait Events (default: Cumulative)
             -m : MODULE/ACTION mode for Section 4 (default: USER/PROGRAM_NAME)
             -b : Batch mode
             -n : maximum number of iterations (requires number)
             -h : Help

使用说明
1. Log in to the system as the Oracle RDBMS software installation owner
2. Stage the oratop executable on the server on which the tool will be executed. On a RAC system it is only necessary to stage the executable on one node as it is RAC aware.
3. Change the name of the executable, eg.

$ mv oratop* oratop

4. Validate the permissions for oratop are 755 (-rwxr-xr-x). If the permissions are not currently set to 755, set the permissions on oratop as follows:

$ chmod 755 oratop

5. Configure the execution environment as follows (if not already set accordingly)

$ export TERM=xterm #or vt100
$ export ORACLE_HOME=<11.2 database home>
$ export LD_LIBRARY_PATH=$ORACLE_HOME/lib
$ export PATH=$ORACLE_HOME/bin:$PATH
$ export ORACLE_SID=<local 11.2 database SID to be monitored> #only needed if connecting to a local database

6. Invoke the tool to monitor a local database as follows (interval can be any interval in seconds):

$ ./oratop -i 10 / as sysdba

7. Non-dba privileged user requires specific grants to use the tool. See User Guide for grants required.
8. Databases can be monitored remotely using a tns alias as described in the oratop Users Guide .

$ ./oratop -i 10 username/password@tns_alias
$ ./oratop -i 10 system/manager@tns_alias

9. To exit the program simply press the keyboard key “q”. To abort, CTRL-C.
Troubleshooting:
If you receive an error similar to
./oratop: error while loading shared libraries: libclntsh.so.11.1: cannot open shared object file: No such file or directory that is an indication that libclntsh.so.11.1 was not found in the path defined in LD_LIBRARY_PATH similar to

$ export LD_LIBRARY_PATH=$ORACLE_HOME/lib (ie., the location of libclntsh.so.11.1)

使用效果

[oracle@xifenfei tmp]$ ./oratap  -i 10 chf/xifenfei@ora11g_p
oratop: Release 13.2.4 Production on Mon Aug 26 03:10:17 2013
Copyright (c) 2011, Oracle.  All rights reserved.
Processing ...
oratop 1:  148 ora1 03:10:13 up  3.3m,  1 ins, 301M mt,   3 sn,  1 us,   6% db
ID %CU HLD MBPS IOPS %FR PGAU ASC ASI ASW ASP   AAS USN  TPS UCPS SSRT DBC DBW
 1   0   0    0    1   5 133M   1   0   0   0   0.1   3    0    2   0u   0   0
EVENT     (Cumulative)           TOT WAITS  TIME(s)  AVG_MS PCT  WAIT_CLASS
DB CPU                                          218          68
control file parallel write           5535       30     5.5   9  System I/O
db file sequential read              10080       27     2.7   8  User I/O
os thread startup                      198       25   124.9   8  Concurrency
db file async I/O submit              2575       21     8.0   7  System I/O
ID   SID  SPID USR PROG  PGA OPN SQLID/BLOCKER  E/T STATUS STE WAIT_EVENT  W/T
 1   148  8254 CHF DEDI   2M SEL 4agz3g5aajkdc    0 ACTIVE CPU wa for cpu   0u

参考文档:
oratop – utility for near real-time monitoring of databases, RAC and Single Instance (Doc ID 1500864.1)

使用_allow_resetlogs_corruption导致ORA-00704/ORA-01555故障

联系:手机/微信(+86 17813235971) QQ(107644445)

标题:使用_allow_resetlogs_corruption导致ORA-00704/ORA-01555故障

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

以前写过一篇乱用_allow_resetlogs_corruption参数导致悲剧的文章,昨天晚上又遇到一个朋友不谨慎使用_allow_resetlogs_corruption导致ORA-00704/ORA-01555故障
环境描述
系统环境:solaris
数据库版本:10.2.0.5.7
数据存储方式:ASM
数据量:15T以上
补充事宜:数据库SCN距离headroom只有54天

报ORA-00020错误,实例crash
数据库因为超过了系统的进程数,出现dbwn进程写数据文件异常

Sun Aug 25 16:00:41 CST 2013
Errors in file /opt/oracle/admin/orcl/bdump/orcl_dbw0_7490.trc:
ORA-01148: 无法刷新数据文件 22 的文件大小
ORA-01110: 数据文件 22: '+DATA/orcl/datafile/index_jh.dbf'
ORA-00020: 超出最大进程数 ()
Sun Aug 25 16:00:41 CST 2013
Errors in file /opt/oracle/admin/orcl/bdump/orcl_dbw0_7490.trc:
ORA-01242: 数据文件出现介质故障: 数据库处于 NOARCHIVELOG 模式
ORA-01110: 数据文件 22: '+DATA/orcl/datafile/index_jh.dbf'
Sun Aug 25 16:00:41 CST 2013
DBW0: terminating instance due to error 1242
Termination issued to instance processes. Waiting for the processes to exit
Sun Aug 25 16:00:51 CST 2013
Instance termination failed to kill one or more processes
Instance terminated by DBW0, pid = 7490

ORA-00600[kcbtema_10]
实例恢复出现ORA-00600: 内部错误代码, 参数: [kcbtema_10], [1], [], [], [], [], [], []

Sun Aug 25 19:19:23 CST 2013
ALTER DATABASE OPEN
Sun Aug 25 19:19:38 CST 2013
Beginning crash recovery of 1 threads
 parallel recovery started with 16 processes
Sun Aug 25 19:19:40 CST 2013
Started redo scan
Sun Aug 25 19:20:07 CST 2013
Completed redo scan
 12016413 redo blocks read, 93405 data blocks need recovery
Sun Aug 25 19:20:19 CST 2013
Started redo application at
 Thread 1: logseq 53681, block 1091966
Sun Aug 25 19:20:19 CST 2013
Recovery of Online Redo Log: Thread 1 Group 1 Seq 53681 Reading mem 0
  Mem# 0: +DATA/orcl/onlinelog/redo_1_1.log
  Mem# 1: +DATA/orcl/onlinelog/redo_1_2.log
Sun Aug 25 19:20:21 CST 2013
Errors in file /opt/oracle/admin/orcl/bdump/orcl_p011_16944.trc:
ORA-00600: 内部错误代码, 参数: [kcbtema_10], [1], [], [], [], [], [], []
Sun Aug 25 19:20:23 CST 2013
Errors in file /opt/oracle/admin/orcl/bdump/orcl_p011_16944.trc:
ORA-00600: 内部错误代码, 参数: [kcbtema_10], [1], [], [], [], [], [], []
Sun Aug 25 19:20:23 CST 2013
Aborting crash recovery due to slave death, attempting serial crash recovery
Sun Aug 25 19:20:23 CST 2013
Beginning crash recovery of 1 threads
Sun Aug 25 19:20:23 CST 2013
Started redo scan
Sun Aug 25 19:20:47 CST 2013
Completed redo scan
 12016413 redo blocks read, 93405 data blocks need recovery
Sun Aug 25 19:20:54 CST 2013
Started redo application at
 Thread 1: logseq 53681, block 1091966
Sun Aug 25 19:20:54 CST 2013
Recovery of Online Redo Log: Thread 1 Group 1 Seq 53681 Reading mem 0
  Mem# 0: +DATA/orcl/onlinelog/redo_1_1.log
  Mem# 1: +DATA/orcl/onlinelog/redo_1_2.log
Sun Aug 25 19:20:54 CST 2013
Errors in file /opt/oracle/admin/orcl/udump/orcl_ora_16751.trc:
ORA-00600: 内部错误代码, 参数: [kcbtema_10], [1], [], [], [], [], [], []
Sun Aug 25 19:20:56 CST 2013
Aborting crash recovery due to error 600
Sun Aug 25 19:20:56 CST 2013
Errors in file /opt/oracle/admin/orcl/udump/orcl_ora_16751.trc:
ORA-00600: 内部错误代码, 参数: [kcbtema_10], [1], [], [], [], [], [], []
ORA-600 signalled during: ALTER DATABASE OPEN...

使用隐含参数

ALTER SYSTEM SET _allow_resetlogs_corruption=TRUE SCOPE=SPFILE;

报ORA-00704/ORA-01555
因为在前面的恢复中进行了不完全恢复,因此这里加入隐含参数,然后尝试resetlogs,然后报如下错误

Sun Aug 25 20:11:54 CST 2013
alter database open resetlogs
Sun Aug 25 20:12:10 CST 2013
RESETLOGS is being done without consistancy checks. This may result
in a corrupted database. The database should be recreated.
RESETLOGS after incomplete recovery UNTIL CHANGE 13429649847189
Resetting resetlogs activation ID 1312390734 (0x4e397e4e)
Sun Aug 25 20:16:25 CST 2013
Setting recovery target incarnation to 2
Sun Aug 25 20:16:42 CST 2013
************************************************************
Warning: The SCN headroom for this database is only 54 days!
************************************************************
Sun Aug 25 20:16:43 CST 2013
Assigning activation ID 1352200163 (0x5098efe3)
Thread 1 opened at log sequence 1
  Current log# 1 seq# 1 mem# 0: +DATA/orcl/onlinelog/redo_1_1.log
  Current log# 1 seq# 1 mem# 1: +DATA/orcl/onlinelog/redo_1_2.log
Successful open of redo thread 1
Sun Aug 25 20:16:43 CST 2013
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Sun Aug 25 20:16:52 CST 2013
SMON: enabling cache recovery
Sun Aug 25 20:16:52 CST 2013
ORA-01555 caused by SQL statement below (SQL ID: 4krwuz0ctqxdt, SCN: 0x0c36.d582339b):
Sun Aug 25 20:16:52 CST 2013
select ctime, mtime, stime from obj$ where obj# = :1
Sun Aug 25 20:16:52 CST 2013
Errors in file /opt/oracle/admin/orcl/udump/orcl_ora_2859.trc:
ORA-00704: 引导程序进程失败
ORA-00704: 引导程序进程失败
ORA-00604: 递归 SQL 级别 1 出现错误
ORA-01555: 快照过旧: 回退段号 143 (名称为 "_SYSSMU143$") 过小
Error 704 happened during db open, shutting down database
USER: terminating instance due to error 704
Termination issued to instance processes. Waiting for the processes to exit
Sun Aug 25 20:17:02 CST 2013
Instance termination failed to kill one or more processes
Instance terminated by USER, pid = 2859
ORA-1092 signalled during: alter database open resetlogs...

数据库当前SCN

SQL > select CHECKPOINT_CHANGE# from v$database;
CHECKPOINT_CHANGE#
------------------
    13429649947222
SQL > select distinct CHECKPOINT_CHANGE# from v$datafile_header;
CHECKPOINT_CHANGE#
------------------
    13429649947222

解决方法
因为该数据库版本为10.2.0.5.7,已经包含了scn patch,因此不能使用event或者隐含参数来修改scn,而且该库容量15T以上(asm),因此也无法使用bbed修改数据文件头,最后决定使用ordebug来解决该问题
使用oradebug DUMPvar SGA kcsgscn_
使用oradebug poke

sqlplus / as sysdba
startup mount
oradebug setmypid
oradebug DUMPvar SGA kcsgscn_
oradebug poke
recover database;
alter database open;

事后总结
查询MOS,发现ORA-00600[kcbtema_10] Raised During Recovery Operations (Doc ID 472282.1)

--故障原因
The cause of this problem has been identified and verified in unpublished Bug 5184359 ORA-600 [KCBTEMA_10].
Due to this bug, during recovery, the class designation of a data block has changed.
--处理方法
SQL>startup mount
SQL>recover database;
SQL>alter database open;

因为MOS上给的解决思路在该数据库中已经无法尝试,不能确定该方法一定可行,但是对于本次的恢复过程中,没有任何直接recover database操作(只有一次不完全恢复)确实让人有无限的遗憾和可惜。对于本次应该先查询MOS,尝试该种方法,慎重使用_allow_resetlogs_corruption参数

ORACLE 12C dbms_utility.expand_sql_text 查看SQL视图基表

联系:手机/微信(+86 17813235971) QQ(107644445)

标题:ORACLE 12C dbms_utility.expand_sql_text 查看SQL视图基表

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

在ORACLE 12C之间的版本,如果一条sql中包含了N多视图,我们要查询这条sql访问了哪些基表,以及他们的关联条件是一件比较麻烦的时候,需要进入一个个视图然后一个个去分析,纯体力活,到了12C之后,ORACLE 提供了dbms_utility.expand_sql_text来获得某条sql所对应的全部基表,不用我们再一级一级的去看.

dbms_utility.expand_sql_text


创建测试表
三个表分别来自数据库的v$datafile,v$tablespace,v$tempfile视图

CDB_PDB@CHF> create table datafile
  2  as
  3  select * from v$datafile;
表已创建。
CDB_PDB@CHF> create table tablespace
  2  as
  3  select * from v$tablespace;
表已创建。
CDB_PDB@CHF> create table tempfile
  2  as
  3  select * from v$tempfile;
表已创建。

创建视图
创建三个视图,datafile与tablespace,tempfile与tablespace,这两个视图然后做union all产生新视图

CDB_PDB@CHF> create view v_xifenfei1 as
  2  select d.name dname,t.name tname from datafile d,tablespace t where d.ts#=t.ts#;
视图已创建。
CDB_PDB@CHF> create view v_xifenfei2 as
  2  select d.name dname,t.name tname from tempfile d,tablespace t where d.ts#=t.ts#;
视图已创建。
CDB_PDB@CHF> create view v_xifenfei
  2  as
  3  select * from v_xifenfei1
  4  union all
  5  select * from v_xifenfei2;
视图已创建。

找出查询视图sql对应基表

CDB_PDB@CHF>  set linesize 32767 pagesize 0 serveroutput on
CDB_PDB@CHF>  declare
  2     original_sql clob :='select * from v_xifenfei';
  3     expanded_sql clob := empty_clob();
  4  begin
  5      dbms_utility.expand_sql_text(original_sql,expanded_sql);
  6      dbms_output.put_line(expanded_sql);
  7  end;
  8  /
SELECT "A1"."DNAME" "DNAME","A1"."TNAME" "TNAME" FROM  ( (SELECT "A4"."DNAME" "DNAME","A4"."TNAME" "TNAME" FROM  (SELECT
 "A6"."NAME" "DNAME","A5"."NAME" "TNAME" FROM CHF."DATAFILE" "A6",CHF."TABLESPACE" "A5" WHERE "A6"."TS#"="A5"."TS#") "A4
") UNION ALL  (SELECT "A3"."DNAME" "DNAME","A3"."TNAME" "TNAME" FROM  (SELECT "A8"."NAME" "DNAME","A7"."NAME" "TNAME" FR
OM CHF."TEMPFILE" "A8",CHF."TABLESPACE" "A7" WHERE "A8"."TS#"="A7"."TS#") "A3")) "A1"
PL/SQL 过程已成功完成。

格式化sql语句

/* Formatted on 2013/8/24 22:33:33 (QP5 v5.227.12220.39754) */
SELECT "A1"."DNAME" "DNAME", "A1"."TNAME" "TNAME"
  FROM ( (SELECT "A4"."DNAME" "DNAME", "A4"."TNAME" "TNAME"
            FROM (SELECT "A6"."NAME" "DNAME", "A5"."NAME" "TNAME"
                    FROM CHF."DATAFILE" "A6", CHF."TABLESPACE" "A5"
                   WHERE "A6"."TS#" = "A5"."TS#") "A4")
        UNION ALL
        (SELECT "A3"."DNAME" "DNAME", "A3"."TNAME" "TNAME"
           FROM (SELECT "A8"."NAME" "DNAME", "A7"."NAME" "TNAME"
                   FROM CHF."TEMPFILE" "A8", CHF."TABLESPACE" "A7"
                  WHERE "A8"."TS#" = "A7"."TS#") "A3")) "A1"

这里就非常清晰的看到是datafile与tablespace、tempfile与tablespace做union all的sql语句

ORACLE 12C Windows-Linux 部署DATAGURAD

联系:手机/微信(+86 17813235971) QQ(107644445)

标题:ORACLE 12C Windows-Linux 部署DATAGURAD

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

环境描述
win 64中的ORACLE 12C(primary)与Linux 64中的ORACLE 12C(standby)搭建datagurad

primary force logging

C:\Users\XIFENFEI>sqlplus / as sysdba
SQL*Plus: Release 12.1.0.1.0 Production on 星期六 8月 24 16:59:53 2013
Copyright (c) 1982, 2013, Oracle.  All rights reserved.
连接到:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
CDB_CDB$ROOT@SYS> select banner from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
PL/SQL Release 12.1.0.1.0 - Production
CORE    12.1.0.1.0      Production
TNS for 64-bit Windows: Version 12.1.0.1.0 - Production
NLSRTL Version 12.1.0.1.0 - Production
CDB_CDB$ROOT@SYS> alter database force logging ;
数据库已更改。

primary rman backup

backup filesperset = 5 as compressed backupset database format 'd:/backup/rman/full_%U.rman';

primary 生成standby controlfile

CDB_CDB$ROOT@SYS> ALTER DATABASE CREATE STANDBY CONTROLFILE AS 'c:/control01.ctl';
数据库已更改。
CDB_CDB$ROOT@SYS> create pfile='e:/pfile.txt' from spfile;
文件已创建。

standby 参数文件

DB_CREATE_FILE_DEST='+DATA'
db_create_online_log_dest_1='+DATA'
db_unique_name='cdb_dg'
service_names='cdb'
log_archive_dest_1='LOCATION=/u02/app/oracle/archivelog/ valid_for=(all_logfiles,all_roles)'
log_archive_dest_2='service=primary lgwr async valid_for=(online_logfiles,primary_role) db_unique_name=cdb'
log_archive_config='dg_config=(cdb,cdb_dg)'
standby_file_management=auto
db_file_name_convert='E:\APP\XIFENFEI\ORADATA\','+DATA\CDB_DG\DATAFILE\'
log_file_name_convert='E:\APP\XIFENFEI\ORADATA\','+DATA\CDB_DG\LOGFILE\'
fal_server=primary

primary 修改参数

CDB_CDB$ROOT@SYS> alter system set log_archive_config='dg_config=(cdb,cdb_dg)';
系统已更改。
CDB_CDB$ROOT@SYS> alter system set log_archive_dest_2='
 2 service=standby lgwr async valid_for=(online_logfiles,primary_role) db_unique_name=cdb_dg';
系统已更改。
CDB_CDB$ROOT@SYS> alter system set log_archive_dest_1=
  2 'LOCATION=USE_DB_RECOVERY_FILE_DEST valid_for=(all_logfiles,all_roles)';
系统已更改。
CDB_CDB$ROOT@SYS> alter system set fal_server=standby;
系统已更改。
CDB_CDB$ROOT@SYS> alter system set standby_file_management=auto;
系统已更改。
CDB_CDB$ROOT@SYS> alter system set db_file_name_convert='+DATA\CDB_DG\DATAFILE\','E:\APP\XIFENFEI\ORADATA\' scope=spfile;
系统已更改。
CDB_CDB$ROOT@SYS> alter system set log_file_name_convert='+DATA\CDB_DG\LOGFILE\','E:\APP\XIFENFEI\ORADATA\' scope=spfile;
系统已更改。

primary and standby tns

STANDBY =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.30.32 )(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = cdb)
    )
  )
PRIMARY =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.30.1 )(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = cdb)
    )
  )

standby restore controlfile

ASMCMD> cp /tmp/CONTROL01.CTL control01.ctl
copying /tmp/CONTROL01.CTL -> +data/cdb/control01.ctl

standby password file

[oracle@xifenfei dbs]$ pwd
/u01/app/oracle/product/12.1/db_1/dbs
[oracle@xifenfei dbs]$ cp /tmp/rman/PWDcdb.ora  orapwcdb

standby mount

SYS% cdb> create spfile from pfile='initcdb.ora';
File created.
SYS% cdb> startup mount;
ORACLE instance started.
Total System Global Area  521936896 bytes
Fixed Size                  2290264 bytes
Variable Size             314576296 bytes
Database Buffers          197132288 bytes
Redo Buffers                7938048 bytes
Database mounted.
SYS% cdb> select banner from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
PL/SQL Release 12.1.0.1.0 - Production
CORE    12.1.0.1.0      Production
TNS for Linux: Version 12.1.0.1.0 - Production
NLSRTL Version 12.1.0.1.0 - Production
SYS% cdb> select name from v$datafile;
NAME
--------------------------------------------------------------------------------
E:\APP\XIFENFEI\ORADATA\CDB\SYSTEM01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\PDBSEED\SYSTEM01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\SYSAUX01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\PDBSEED\SYSAUX01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\UNDOTBS01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\USERS01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\PDB\SYSTEM01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\PDB\SYSAUX01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\PDB\PDB_USERS01.DBF
9 rows selected.

standby rman restore

--清理控制文件中的备份集垃圾
DELETE noprompt OBSOLETE;
crosscheck backup;
delete noprompt expired backup;
--注册新备份集
catalog start with '/tmp/rman/';
--还原数据文件
run
{
set newname for database to '+data';
restore database;
switch datafile all;
}

standby clear redo

SYS% cdb> select group# from v$log;
    GROUP#
----------
         4
         6
         5
SYS% cdb> alter database clear logfile group 4;
Database altered.
SYS% cdb> alter database clear logfile group 5;
Database altered.
SYS% cdb> alter database clear logfile group 6;
Database altered.

standby add standby redolog

SYS% cdb> ALTER DATABASE ADD STANDBY LOGFILE GROUP 10  size 50M;
Database altered.
SYS% cdb> ALTER DATABASE ADD STANDBY LOGFILE GROUP 11  size 50M;
Database altered.
SYS% cdb> ALTER DATABASE ADD STANDBY LOGFILE GROUP 12  size 50M;
Database altered.
SYS% cdb> ALTER DATABASE ADD STANDBY LOGFILE GROUP 13  size 50M;
Database altered.

primary add standby redolog

CDB_CDB$ROOT@SYS> ALTER DATABASE ADD STANDBY LOGFILE GROUP 10  'E:\APP\XIFENFEI\ORADATA\CDB\std_redo10.log' size 50M;
数据库已更改。
CDB_CDB$ROOT@SYS> ALTER DATABASE ADD STANDBY LOGFILE GROUP 11  'E:\APP\XIFENFEI\ORADATA\CDB\std_redo11.log' size 50M;
数据库已更改。
CDB_CDB$ROOT@SYS> ALTER DATABASE ADD STANDBY LOGFILE GROUP 12  'E:\APP\XIFENFEI\ORADATA\CDB\std_redo12.log' size 50M;
数据库已更改。
CDB_CDB$ROOT@SYS> ALTER DATABASE ADD STANDBY LOGFILE GROUP 13  'E:\APP\XIFENFEI\ORADATA\CDB\std_redo13.log' size 50M;
数据库已更改。

standby readonly

SYS% cdb> ALTER DATABASE OPEN READ ONLY;
Database altered.

standby start mrp

SYS% cdb> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
Database altered.

DATAGURAD 是否正常检查

--primary
CDB_CDB$ROOT@SYS> archive log list;
数据库日志模式            存档模式
自动存档             启用
存档终点            USE_DB_RECOVERY_FILE_DEST
最早的联机日志序列     374
下一个存档日志序列   376
当前日志序列           376
--standby
Mon Aug 12 13:56:51 2013
All non-current ORLs have been archived.
Mon Aug 12 13:56:53 2013
Media Recovery Log /u02/app/oracle/archivelog/1_370_820595806.dbf
Mon Aug 12 13:56:57 2013
Media Recovery Log /u02/app/oracle/archivelog/1_371_820595806.dbf
Mon Aug 12 13:57:02 2013
Media Recovery Log /u02/app/oracle/archivelog/1_372_820595806.dbf
Mon Aug 12 13:57:04 2013
Media Recovery Log /u02/app/oracle/archivelog/1_373_820595806.dbf
Mon Aug 12 13:57:05 2013
Media Recovery Log /u02/app/oracle/archivelog/1_374_820595806.dbf
Media Recovery Waiting for thread 1 sequence 375
Mon Aug 12 13:57:19 2013
Primary database is in MAXIMUM PERFORMANCE mode
RFS[2]: Assigned to RFS process (PID:26114)
RFS[2]: No standby redo logfiles created for thread 1
RFS[2]: Opened log for thread 1 sequence 376 dbid 1937199326 branch 820595806
Mon Aug 12 13:57:19 2013
RFS[3]: Assigned to RFS process (PID:26118)
RFS[3]: Opened log for thread 1 sequence 375 dbid 1937199326 branch 820595806
Mon Aug 12 13:57:19 2013
Archived Log entry 16 added for thread 1 sequence 375 rlc 820595806 ID 0x7377d8de dest 2:
Mon Aug 12 13:57:22 2013
Media Recovery Log /u02/app/oracle/archivelog/1_375_820595806.dbf
Media Recovery Waiting for thread 1 sequence 376 (in transit)

ORACLE 12C Partial Global/Local Indexes for Partitioned Tables

联系:手机/微信(+86 17813235971) QQ(107644445)

标题:ORACLE 12C Partial Global/Local Indexes for Partitioned Tables

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

以前我有个想法,我只想对其中的某个或者某几个分区上创建索引,其他分区不想创建,在12C之前的版本,无论是Local还是Global index,都不能实现该需求,但是从ORACLE 12C开始引进了Partial Global/Local Indexes for Partitioned Tables,解决了该问题,可以在指定的分区上创建本地索引或者全局索引,主要语法是在表或者分区,子分区级别设置[INDEXING { ON | OFF }]
创建测试表

CDB_PDB@CHF> SELECT BANNER FROM V$VERSION;
BANNER
--------------------------------------------------------------------------------
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
PL/SQL Release 12.1.0.1.0 - Production
CORE    12.1.0.1.0      Production
TNS for 64-bit Windows: Version 12.1.0.1.0 - Production
NLSRTL Version 12.1.0.1.0 - Production
CDB_PDB@CHF> CREATE TABLE xifenfei_orders (
  2  order_id NUMBER(12),
  3  order_address varchar2(100),
  4  order_mode VARCHAR2(20))
  5  INDEXING OFF
  6  PARTITION BY RANGE (order_id)
  7  (PARTITION ord_p1 VALUES LESS THAN (100) INDEXING ON,
  8  PARTITION ord_p2 VALUES LESS THAN (200) INDEXING OFF,
  9  PARTITION ord_p3 VALUES LESS THAN (300) INDEXING ON,
 10  PARTITION ord_p4 VALUES LESS THAN (400),
 11  PARTITION ord_p5 VALUES LESS THAN (500));
表已创建。

创建LOCAL INDEX

CDB_PDB@CHF> CREATE INDEX ind_lox on xifenfei_orders(order_address) LOCAL INDEXING PARTIAL;
索引已创建。
CDB_PDB@CHF> COL INDEX_NAME FOR A10
CDB_PDB@CHF> COL PARTITION_NAME FOR A15
CDB_PDB@CHF> select index_name, partition_name,STATUS
  2   from user_ind_partitions
  3   where index_name = 'IND_LOX';
INDEX_NAME PARTITION_NAME  STATUS
---------- --------------- --------
IND_LOX    ORD_P5          UNUSABLE
IND_LOX    ORD_P4          UNUSABLE
IND_LOX    ORD_P3          USABLE
IND_LOX    ORD_P2          UNUSABLE
IND_LOX    ORD_P1          USABLE
--设置INDEXING OFF对应的index 状态为UNUSABLE,分区继承表
CDB_PDB@CHF> select partition_name,indexing from user_tab_partitions where table_name='XIFENFEI_ORDERS';
PARTITION_NAME  INDE
--------------- ----
ORD_P5          OFF
ORD_P4          OFF
ORD_P3          ON
ORD_P2          OFF
ORD_P1          ON
--因为segment 延迟,无数据,所以无分区和索引记录
CDB_PDB@CHF> SELECT PARTITION_NAME,SEGMENT_NAME FROM USER_SEGMENTS WHERE SEGMENT_NAME='IND_LOX';
未选定行
CDB_PDB@CHF> SELECT PARTITION_NAME,SEGMENT_NAME FROM USER_SEGMENTS WHERE SEGMENT_NAME='XIFENFEI_ORDERS';
未选定行
CDB_PDB@CHF> begin
  2    for i in 1 .. 449 loop
  3      insert into xifenfei_orders
  4      values
  5        (i,'www.xifenfei.com'||i,'惜分飞'||i);
  6    end loop;
  7  commit;
  8  end;
  9  /
PL/SQL 过程已成功完成。
--插入记录后,分区表有相关记录
CDB_PDB@CHF> SELECT PARTITION_NAME,SEGMENT_NAME,blocks FROM USER_SEGMENTS WHERE SEGMENT_NAME='XIFENFEI_ORDERS';
PARTITION_NAME  SEGMENT_NAME        BLOCKS
--------------- --------------- ----------
ORD_P5          XIFENFEI_ORDERS       1024
ORD_P4          XIFENFEI_ORDERS       1024
ORD_P3          XIFENFEI_ORDERS       1024
ORD_P2          XIFENFEI_ORDERS       1024
ORD_P1          XIFENFEI_ORDERS       1024
--注意:这里只有user_tab_partitions.indexing为on的有记录,也就是说,至于这些分区的索引被创建,其他的未被创建
CDB_PDB@CHF> SELECT PARTITION_NAME,SEGMENT_NAME FROM USER_SEGMENTS WHERE SEGMENT_NAME='IND_LOX';
PARTITION_NAME  SEGMENT_NAME
--------------- ---------------
ORD_P1          IND_LOX
ORD_P3          IND_LOX

分析执行计划

CDB_PDB@CHF> EXEC DBMS_STATS.GATHER_TABLE_STATS(USER,'XIFENFEI_ORDERS',CASCADE=>TRUE);
PL/SQL 过程已成功完成。
CDB_PDB@CHF> SET AUTOT TRACE
CDB_PDB@CHF> SELECT ORDER_MODE FROM XIFENFEI_ORDERS WHERE ORDER_ADDRESS='www.xifenfei.com99';
未选定行
执行计划
----------------------------------------------------------
Plan hash value: 2800545636
------------------------------------------------------------------------------------------------------------------------
--------
| Id  | Operation                                    | Name            | Rows  | Bytes | Cost (%CPU)| Time     | Pstart|
 Pstop |
------------------------------------------------------------------------------------------------------------------------
--------
|   0 | SELECT STATEMENT                             |                 |     1 |    30 |    40   (0)| 00:00:01 |       |
       |
|   1 |  VIEW                                        | VW_TE_2         |     2 |    24 |    40   (0)| 00:00:01 |       |
       |
|   2 |   UNION-ALL                                  |                 |       |       |            |          |       |
       |
|   3 |    PARTITION RANGE OR                        |                 |     1 |    34 |     1   (0)| 00:00:01 |KEY(OR)|
KEY(OR)|
|*  4 |     TABLE ACCESS BY LOCAL INDEX ROWID BATCHED| XIFENFEI_ORDERS |     1 |    34 |     1   (0)| 00:00:01 |KEY(OR)|
KEY(OR)|
|*  5 |      INDEX RANGE SCAN                        | IND_LOX         |     1 |       |     1   (0)| 00:00:01 |KEY(OR)|
KEY(OR)|
|   6 |    PARTITION RANGE OR                        |                 |     1 |    34 |    39   (0)| 00:00:01 |KEY(OR)|
KEY(OR)|
|*  7 |     TABLE ACCESS FULL                        | XIFENFEI_ORDERS |     1 |    34 |    39   (0)| 00:00:01 |KEY(OR)|
KEY(OR)|
------------------------------------------------------------------------------------------------------------------------
--------
Predicate Information (identified by operation id):
---------------------------------------------------
   4 - filter("XIFENFEI_ORDERS"."ORDER_ID"<100 OR "XIFENFEI_ORDERS"."ORDER_ID">=200 AND
              "XIFENFEI_ORDERS"."ORDER_ID"<300)
   5 - access("ORDER_ADDRESS"='www.xifenfei.com99')
   7 - filter("ORDER_ADDRESS"='www.xifenfei.com99' AND ("XIFENFEI_ORDERS"."ORDER_ID">=300 AND
"XIFENFEI_ORDERS"."ORDER_ID"<500 OR "XIFENFEI_ORDERS"."ORDER_ID"<200 AND "XIFENFEI_ORDERS"."ORDER_ID">=100))
--这里可以看到,当我们没有指定分区范围的时候,显示的执行计划是有分区index的部分直接走index,没有分区index的部分是扫描分区
统计信息
----------------------------------------------------------
         34  recursive calls
          0  db block gets
        120  consistent gets
          1  physical reads
          0  redo size
        347  bytes sent via SQL*Net to client
        533  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          5  sorts (memory)
          0  sorts (disk)
          0  rows processed
CDB_PDB@CHF> SELECT ORDER_MODE FROM XIFENFEI_ORDERS t WHERE ORDER_ADDRESS='www.xifenfei.com499' and order_id>200 and ord
er_id<300;
未选定行
执行计划
----------------------------------------------------------
Plan hash value: 3337708912
------------------------------------------------------------------------------------------------------------------------
------
| Id  | Operation                                  | Name            | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| P
stop |
------------------------------------------------------------------------------------------------------------------------
------
|   0 | SELECT STATEMENT                           |                 |     1 |    34 |     2   (0)| 00:00:01 |       |
     |
|   1 |  PARTITION RANGE SINGLE                    |                 |     1 |    34 |     2   (0)| 00:00:01 |     3 |
   3 |
|*  2 |   TABLE ACCESS BY LOCAL INDEX ROWID BATCHED| XIFENFEI_ORDERS |     1 |    34 |     2   (0)| 00:00:01 |     3 |
   3 |
|*  3 |    INDEX RANGE SCAN                        | IND_LOX         |     1 |       |     1   (0)| 00:00:01 |     3 |
   3 |
------------------------------------------------------------------------------------------------------------------------
------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter("ORDER_ID">200)
   3 - access("ORDER_ADDRESS"='www.xifenfei.com499')
--指定分区查询,可以明确的看到,该sql直接使用了分区索引
统计信息
----------------------------------------------------------
          1  recursive calls
          0  db block gets
          1  consistent gets
          0  physical reads
          0  redo size
        347  bytes sent via SQL*Net to client
        533  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          0  rows processed
CDB_PDB@CHF> SELECT ORDER_MODE FROM XIFENFEI_ORDERS t WHERE ORDER_ADDRESS='www.xifenfei.com499' and order_id>300 and ord
er_id<400;
未选定行
执行计划
----------------------------------------------------------
Plan hash value: 2072227240
----------------------------------------------------------------------------------------------------------
| Id  | Operation              | Name            | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |                 |     1 |    34 |    14   (0)| 00:00:01 |       |    |
|   1 |  PARTITION RANGE SINGLE|                 |     1 |    34 |    14   (0)| 00:00:01 |     4 |     4 |
|*  2 |   TABLE ACCESS FULL    | XIFENFEI_ORDERS |     1 |    34 |    14   (0)| 00:00:01 |     4 |     4 |
----------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter("ORDER_ADDRESS"='www.xifenfei.com499' AND "ORDER_ID">300)
--当指定的分区无index之时,直接判断走全表扫描
统计信息
----------------------------------------------------------
          1  recursive calls
          0  db block gets
         22  consistent gets
          0  physical reads
          0  redo size
        347  bytes sent via SQL*Net to client
        533  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          0  rows processed

创建Global index

CDB_PDB@CHF> ALTER INDEX ind_lox INVISIBLE;
索引已更改。
CDB_PDB@CHF> CREATE INDEX IND_G_LOX ON XIFENFEI_ORDERS(ORDER_ADDRESS) Global  INDEXING PARTIAL;
索引已创建。
CDB_PDB@CHF> select index_name,indexing from dba_indexes where index_name='IND_G_LOX';
INDEX_NAME INDEXIN
---------- -------
IND_G_LOX  PARTIAL

执行计划

CDB_PDB@CHF> SELECT ORDER_MODE FROM XIFENFEI_ORDERS t WHERE ORDER_ADDRESS='www.xifenfei.com99';
未选定行
执行计划
----------------------------------------------------------
Plan hash value: 1912382893
------------------------------------------------------------------------------------------------------------------------
--------
| Id  | Operation                                    | Name            | Rows  | Bytes | Cost (%CPU)| Time     | Pstart|
 Pstop |
------------------------------------------------------------------------------------------------------------------------
--------
|   0 | SELECT STATEMENT                             |                 |     1 |    30 |    41   (0)| 00:00:01 |       |
       |
|   1 |  VIEW                                        | VW_TE_2         |     2 |    24 |    41   (0)| 00:00:01 |       |
       |
|   2 |   UNION-ALL                                  |                 |       |       |            |          |       |
       |
|*  3 |    TABLE ACCESS BY GLOBAL INDEX ROWID BATCHED| XIFENFEI_ORDERS |     1 |    34 |     2   (0)| 00:00:01 | ROWID |
 ROWID |
|*  4 |     INDEX RANGE SCAN                         | IND_G_LOX       |     1 |       |     1   (0)| 00:00:01 |       |
       |
|   5 |    PARTITION RANGE OR                        |                 |     1 |    34 |    39   (0)| 00:00:01 |KEY(OR)|
KEY(OR)|
|*  6 |     TABLE ACCESS FULL                        | XIFENFEI_ORDERS |     1 |    34 |    39   (0)| 00:00:01 |KEY(OR)|
KEY(OR)|
------------------------------------------------------------------------------------------------------------------------
--------
Predicate Information (identified by operation id):
---------------------------------------------------
   3 - filter("T"."ORDER_ID"<100 OR "T"."ORDER_ID">=200 AND "T"."ORDER_ID"<300)
   4 - access("ORDER_ADDRESS"='www.xifenfei.com99')
   6 - filter("ORDER_ADDRESS"='www.xifenfei.com99' AND ("T"."ORDER_ID">=300 AND "T"."ORDER_ID"<500 OR
              "T"."ORDER_ID"<200 AND "T"."ORDER_ID">=100))
--这里可以看到因为没有指定分区范围,该sql在含index的分区使用全局index,在没有index的分区直接使用全表扫描
统计信息
----------------------------------------------------------
          1  recursive calls
          0  db block gets
         67  consistent gets
          0  physical reads
          0  redo size
        347  bytes sent via SQL*Net to client
        533  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          0  rows processed
CDB_PDB@CHF> SELECT ORDER_MODE FROM XIFENFEI_ORDERS t WHERE ORDER_ADDRESS='www.xifenfei.com99' and order_id<100;
执行计划
----------------------------------------------------------
Plan hash value: 3717359654
------------------------------------------------------------------------------------------------------------------------
------
| Id  | Operation                                  | Name            | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| P
stop |
------------------------------------------------------------------------------------------------------------------------
------
|   0 | SELECT STATEMENT                           |                 |     1 |    31 |     2   (0)| 00:00:01 |       |
     |
|*  1 |  TABLE ACCESS BY GLOBAL INDEX ROWID BATCHED| XIFENFEI_ORDERS |     1 |    31 |     2   (0)| 00:00:01 |     1 |
   1 |
|*  2 |   INDEX RANGE SCAN                         | IND_G_LOX       |     1 |       |     1   (0)| 00:00:01 |       |
     |
------------------------------------------------------------------------------------------------------------------------
------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("ORDER_ID"<100)
   2 - access("ORDER_ADDRESS"='www.xifenfei.com99')
--指定了分区范围,而且该分区又有index,直接使用全局index
统计信息
----------------------------------------------------------
          1  recursive calls
          0  db block gets
          2  consistent gets
          0  physical reads
          0  redo size
        551  bytes sent via SQL*Net to client
        544  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
CDB_PDB@CHF> SELECT ORDER_MODE FROM XIFENFEI_ORDERS t WHERE ORDER_ADDRESS='www.xifenfei.com99' and order_id>400
未选定行
执行计划
----------------------------------------------------------
Plan hash value: 2072227240
----------------------------------------------------------------------------------------------------------
| Id  | Operation              | Name            | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |                 |     1 |    34 |    14   (0)| 00:00:01 |       |    |
|   1 |  PARTITION RANGE SINGLE|                 |     1 |    34 |    14   (0)| 00:00:01 |     5 |     5 |
|*  2 |   TABLE ACCESS FULL    | XIFENFEI_ORDERS |     1 |    34 |    14   (0)| 00:00:01 |     5 |     5 |
----------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter("ORDER_ADDRESS"='www.xifenfei.com99' AND "ORDER_ID">400)
--指定了分区范围,但是该分区无index,直接使用全表扫描
统计信息
----------------------------------------------------------
          1  recursive calls
          0  db block gets
         22  consistent gets
          0  physical reads
          0  redo size
        347  bytes sent via SQL*Net to client
        533  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          0  rows processed

结论
通过测试,证明Partial Global/Local Indexes for Partitioned Tables确实能够实现对部分分区创建index。
1)如果查询条件确定的分区无index,那直接走全表扫描;
2)如果查询条件可以确定的分区范围内有index,会直接使用index(无论是Local还是GLobal);
3)如果查询条件未确定分区范围(含index和无index分区情况),那该sql会在有index分区使用index,在没有index区域走全表扫描

修改props$.NLS_CHARACTERSET导致ORA-00900异常恢复

联系:手机/微信(+86 17813235971) QQ(107644445)

标题:修改props$.NLS_CHARACTERSET导致ORA-00900异常恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

今天一朋友和我说他的数据库不能open,open过程提示ORA-00900错误,通过分析alert日志和props$表,发现他们修改了一个无效的NLS_CHARACTERSET值,导致数据库无法正常启动(准确的说,因为数据库里面该值无效,当数据库open的过程中,检测到控制文件指定的编码和该值不一致,然后修改控制文件的编码,修改之后,数据库一到mount状态执行任何语句都报ORA-00900错误),通过一些工具修改NLS_CHARACTERSET为正确值该故障解决

重现ORA-00900故障

SQL> select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
PL/SQL Release 11.2.0.3.0 - Production
CORE    11.2.0.3.0      Production
TNS for Linux: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production
SQL> select value$ from props$ where name='NLS_CHARACTERSET';
VALUE$
-------------------------------------------------------
ZHS16GBK
SQL> update props$ set value$='AL16UTF16' where name='NLS_CHARACTERSET';
1 row updated.
SQL> commit;
Commit complete.
SQL> alter database backup controlfile to trace as '/tmp/ora11g.ctl';
Database altered.
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area  175775744 bytes
Fixed Size                  1343668 bytes
Variable Size             117444428 bytes
Database Buffers           50331648 bytes
Redo Buffers                6656000 bytes
Database mounted.
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00604: error occurred at recursive SQL level 1
ORA-00900: invalid SQL statement
Process ID: 5277
Session ID: 125 Serial number: 5
SQL> startup nomount;
ORACLE instance started.
Total System Global Area  175775744 bytes
Fixed Size                  1343668 bytes
Variable Size             117444428 bytes
Database Buffers           50331648 bytes
Redo Buffers                6656000 bytes
SQL> alter database mount;
Database altered.
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-00900: invalid SQL statement
SQL>select * from dual;
select * from dual
*
ERROR at line 1:
ORA-00900: invalid SQL statement
SQL> shutdown abort
ORACLE instance shut down.

第一次startup(open)过程报错

SMON: enabling tx recovery
Updating character set in controlfile to AL16UTF16
Errors in file /u01/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_ora_5277.trc:
ORA-00604: error occurred at recursive SQL level %s
ORA-00900: invalid SQL statementursive SQL level %s
Errors in file /u01/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_ora_5277.trc:
ORA-00604: error occurred at recursive SQL level %s
ORA-00900: invalid SQL statementursive SQL level %s
Error 604 happened during db open, shutting down database
USER (ospid: 5277): terminating the instance due to error 604
Errors in file /u01/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_smon_5243.trc:
ORA-00604: error occurred at recursive SQL level %s
ORA-00900: invalid SQL statementursive SQL level %s
Instance terminated by USER, pid = 5277
ORA-1092 signalled during: ALTER DATABASE OPEN...
opiodr aborting process unknown ospid (5277) as a result of ORA-1092
Sat May 18 00:44:27 2013
ORA-1092 : opitsk aborting process

这里比较明显的看到有一条(Updating character set in controlfile to AL16UTF16),正是由于这个操作,更新控制文件的编码为一个无效的编码,从而导致在后面数据库mount(加载控制文件)之后,就不能再进行其他任何操作

解决思路
使用odu找出来block位置,或者在同版本库中查询
使用dul或者bbed修改props$的NLS_CHARACTERSET值
重建控制文件(noresetlogs方式)

处理过程

SQL> shutdown abort
ORACLE instance shut down.
odu找出来block位置
dul或者bbed修改block值
重建控制文件(noresetlogs方式)
SQL> startup
ORACLE instance started.
Total System Global Area  175775744 bytes
Fixed Size                  1343668 bytes
Variable Size             117444428 bytes
Database Buffers           50331648 bytes
Redo Buffers                6656000 bytes
Database mounted.
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/u01/oracle/oradata/ora11g/system01.dbf'
SQL> recover database;
Media recovery complete.
SQL> alter database open;
Database altered.

从oracle 9i开始,修改数据库的编码,直接使用alter database character set internal_use方式进行,而不要使用直接修改props$基表,更不能修改一个实际中不存在的编码值(本文中数据库编码和国家编码搞混淆从而出现该故障)

ORACLE 12C 支持在相同列创建多个索引

联系:手机/微信(+86 17813235971) QQ(107644445)

标题:ORACLE 12C 支持在相同列创建多个索引

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

从ORACLE 12C开始允许在同一列上创建不同类型的index,用来做性能调优,不同类型的index主要包括(B*TREE vs BITMAP,Local vs Global)
ORACLE 11G

SQL> select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
PL/SQL Release 11.2.0.3.0 - Production
CORE    11.2.0.3.0      Production
TNS for Linux: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production
SQL> CREATE TABLE T_XIFENFEI
  2    (
  3    EMPNO      NUMBER(9)       PRIMARY KEY ,
  4    EMPNAME    VARCHAR2(15)    NOT NULL,
  5    )
  6    /
Table created.
SQL> CREATE INDEX EMP_DEPT_BTREE_IDX ON EMP(DEPTNO);
Index created.
SQL> CREATE BITMAP INDEX EMP_DEPTNO_BITMAP_IDX ON EMP(DEPTNO) INVISIBLE  ;
CREATE BITMAP INDEX EMP_DEPTNO_BITMAP_IDX ON EMP(DEPTNO) INVISIBLE
                                                 *
ERROR at line 1:
ORA-01408: such column list already indexed

ORACLE 12C

CDB_PDB@CHF> select * from v$version;
BANNER                                                                               CON_ID
-------------------------------------------------------------------------------- ----------
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production              0
PL/SQL Release 12.1.0.1.0 - Production                                                    0
CORE    12.1.0.1.0      Production                                                        0
TNS for 64-bit Windows: Version 12.1.0.1.0 - Production                                   0
NLSRTL Version 12.1.0.1.0 - Production                                                    0
CDB_PDB@CHF> CREATE TABLE T_XIFENFEI
  2    (
  3    EMPNO      NUMBER(9)       PRIMARY KEY ,
  4    EMPNAME    VARCHAR2(15)    NOT NULL
  5    )
  6    /
表已创建。
CDB_PDB@CHF> CREATE INDEX EMP_DEPT_BTREE_IDX ON EMP(DEPTNO);
索引已创建。
CDB_PDB@CHF> CREATE BITMAP INDEX EMP_DEPTNO_BITMAP_IDX ON EMP(DEPTNO);
CREATE BITMAP INDEX EMP_DEPTNO_BITMAP_IDX ON EMP(DEPTNO)
                                                 *
第 1 行出现错误:
ORA-01408: 此列列表已索引
CDB_PDB@CHF> CREATE BITMAP INDEX EMP_DEPTNO_BITMAP_IDX ON EMP(DEPTNO) INVISIBLE ;
索引已创建。

ORACLE 12C Temporary undo 测试

联系:手机/微信(+86 17813235971) QQ(107644445)

标题:ORACLE 12C Temporary undo 测试

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

ORACLE 8i中引进了全局临时表,而且把临时表的数据存储在临时表空间以减少资源开销。全局临时表在临时表空间的数据会随着一个事务或者一个会话而结束。一个临时表上执行dml操作自身不产生redo,因为这些数据是存储在临时表空间,但是这些操作会产生uundo,而undo存储是永久表空间,进而undo反过来会产生redo。而对于这些临时表是不需要恢复的,因此这些redo是不是可以不要产生,在ORACLE 12C中引进了Temporary undo的功能(temp_undo_enabled参数控制),很大程度上解决了该问题

创建临时表

CDB_CDB$ROOT@SYS> conn chf/xifenfei@pdb
已连接。
CDB_PDB@CHF> select * from v$version;
BANNER                                                                               CON_ID
-------------------------------------------------------------------------------- ----------
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production              0
PL/SQL Release 12.1.0.1.0 - Production                                                    0
CORE    12.1.0.1.0      Production                                                        0
TNS for 64-bit Windows: Version 12.1.0.1.0 - Production                                   0
NLSRTL Version 12.1.0.1.0 - Production                                                    0

temp_undo_enabled=false测试

CDB_PDB@CHF> show parameter temp_undo_enabled;
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
temp_undo_enabled                    boolean     FALSE
CDB_PDB@CHF> create global temporary table g_t_xifenfei(c1 number(8), c2 char(100));
表已创建。
CDB_PDB@CHF> select name, value from v$mystat natural join v$statname
  2    where name = 'redo size' or name = 'redo entries';
NAME                                                                  VALUE
---------------------------------------------------------------- ----------
redo entries                                                             29
redo size                                                              8596
CDB_PDB@CHF> insert into g_t_xifenfei select level, level from dual connect by level <= 10000;
已创建 10000 行。
CDB_PDB@CHF> select name, value from v$mystat natural join v$statname
  2    where name = 'redo size' or name = 'redo entries';
NAME                                                                  VALUE
---------------------------------------------------------------- ----------
redo entries                                                            314
redo size                                                             69892

这里可以发现当temp_undo_enabled=false之时,redo的量在该执行过程中还是增加的很明显,从8596增加到69892(增加了61296 byte的redo),redo entries也增加了285

temp_undo_enabled=true测试

CDB_PDB@CHF> alter session set temp_undo_enabled = true;
会话已更改。
CDB_PDB@CHF> select name, value from v$mystat natural join v$statname
  2    where name = 'redo size' or name = 'redo entries';
NAME                                                                  VALUE
---------------------------------------------------------------- ----------
redo entries                                                              2
redo size                                                               720
CDB_PDB@CHF> insert into g_t_xifenfei select level, level from dual connect by level <= 10000;
已创建 10000 行。
CDB_PDB@CHF> select name, value from v$mystat natural join v$statname
  2    where name = 'redo size' or name = 'redo entries';
NAME                                                                  VALUE
---------------------------------------------------------------- ----------
redo entries                                                              3
redo size                                                              1000

这里可以看到redo的量之时增加了280byte,redo entries增加了1,增加量非常小,完全和temp_undo_enabled=false不是一个等量级

补充说明
在临时表使用比较多的系统中,设置temp_undo_enabled=true可以减少不少的redo产生,正是因为这样的机制产生,可以实现ORACLE 12C ADG中可以实现全局临时表的DML操作

pdb正常运行丢失数据文件相关恢复

联系:手机/微信(+86 17813235971) QQ(107644445)

标题:pdb正常运行丢失数据文件相关恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

上篇文章(某个pdb可以在root pdb open状态下进行恢复)发布后,还是有不少朋友有各种争议,比如我的cdb本来就是open的,比如与oracle 12c 新特性文档描述不符等等,这里根据weibo上的各种争论和各位想的测试情况,我继续测试如下
查询数据库相关状态

C:\Users\XIFENFEI>sqlplus / as sysdba
SQL*Plus: Release 12.1.0.1.0 Production on 星期二 8月 13 12:49:47 2013
Copyright (c) 1982, 2013, Oracle.  All rights reserved.
连接到:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
SQL> show pdbs;
    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB                            READ WRITE NO
SQL> select name from v$datafile where con_id=3;
NAME
--------------------------------------------------------------------------------
E:\APP\XIFENFEI\ORADATA\CDB\PDB\SYSTEM01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\PDB\SYSAUX01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\PDB\PDB_USERS01.DBF

删除pdb system01.dbf文件

SQL> host dir E:\APP\XIFENFEI\ORADATA\CDB\PDB\SYSTEM01.DBF
 驱动器 E 中的卷没有标签。
 卷的序列号是 000C-3B41
 E:\APP\XIFENFEI\ORADATA\CDB\PDB 的目录
找不到文件

做checkpoint操作

--删除pdb的数据文件(本测试中是system01.dbf),因为dbwr无法写入数据到文件,导致crash,在实际中也有可能是ckpt,lgwr进程等
SQL> alter system checkpoint ;
alter system checkpoint
*
第 1 行出现错误:
ORA-03113: 通信通道的文件结尾
进程 ID: 9316
会话 ID: 136 序列号: 3165

alert日志中写明是dbwr进程无法写文件导致整个cdb crash

Tue Aug 13 12:51:10 2013
Thread 1 advanced to log sequence 316 (LGWR switch)
  Current log# 4 seq# 316 mem# 0: E:\APP\XIFENFEI\ORADATA\CDB\REDO04.LOG
Tue Aug 13 12:51:12 2013
Archived Log entry 5 added for thread 1 sequence 315 ID 0x7377d8de dest 1:
Tue Aug 13 12:51:16 2013
KCF: read, write or open error, block=0x6ad1 online=1
        file=7 'E:\APP\XIFENFEI\ORADATA\CDB\PDB\SYSTEM01.DBF'
        error=27070 txt: 'OSD-04016: 异步 I/O 请求排队时出错。'
Tue Aug 13 12:51:16 2013
Errors in file E:\APP\XIFENFEI\diag\rdbms\cdb\cdb\trace\cdb_dbw0_8612.trc:
Tue Aug 13 12:51:16 2013
Errors in file E:\APP\XIFENFEI\diag\rdbms\cdb\cdb\trace\cdb_dbw0_8612.trc:
ORA-63999: 数据文件出现介质故障
ORA-01114: 将块写入文件 7 时出现 IO 错误 (块 # 27345)
ORA-01110: 数据文件 7: 'E:\APP\XIFENFEI\ORADATA\CDB\PDB\SYSTEM01.DBF'
ORA-27070: 异步读取/写入失败
OSD-04016: 异步 I/O 请求排队时出错。
USER (ospid: 8612): terminating the instance due to error 63999
Tue Aug 13 12:51:17 2013
System state dump requested by (instance=1, osid=8612 (DBW0)), summary=[abnormal instance termination].
System State dumped to trace file E:\APP\XIFENFEI\diag\rdbms\cdb\cdb\trace\cdb_diag_9720.trc
Dumping diagnostic data in directory=[cdmp_20130813125117], requested by (instance=1, osid=8612 (DBW0)), summary=[abnormal instance termination].
Tue Aug 13 12:51:29 2013
Instance terminated by USER, pid = 8612

open cdb数据库

SQL> conn / as sysdba
已连接到空闲例程。
SQL> startup
ORACLE 例程已经启动。
Total System Global Area  521936896 bytes
Fixed Size                  2404552 bytes
Variable Size             293605176 bytes
Database Buffers          218103808 bytes
Redo Buffers                7823360 bytes
数据库装载完毕。
ORA-01157: 无法标识/锁定数据文件 7 - 请参阅 DBWR 跟踪文件
ORA-01110: 数据文件 7: 'E:\APP\XIFENFEI\ORADATA\CDB\PDB\SYSTEM01.DBF'
--直接在cdb中无法offline pdb数据文件
SQL> alter database datafile 7 offline;
alter database datafile 7 offline
*
第 1 行出现错误:
ORA-01516: 不存在的日志文件, 数据文件或临时文件 "7"
SQL> alter session set container=pdb;
会话已更改。
SQL> alter database datafile 7 offline;
数据库已更改。
SQL> conn / as sysdba
已连接。
SQL> alter database open;
数据库已更改。
SQL> show pdbs;
    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB                            MOUNTED
SQL> exit
从 Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options 断开

恢复并open pdb

C:\Users\XIFENFEI>rman target /
恢复管理器: Release 12.1.0.1.0 - Production on 星期二 8月 13 12:56:54 2013
Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.
已连接到目标数据库: CDB (DBID=1937199326)
RMAN> restore datafile 7;
启动 restore 于 13-8月 -13
使用目标数据库控制文件替代恢复目录
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: SID=361 设备类型=DISK
通道 ORA_DISK_1: 正在开始还原数据文件备份集
通道 ORA_DISK_1: 正在指定从备份集还原的数据文件
通道 ORA_DISK_1: 将数据文件 00007 还原到 E:\APP\XIFENFEI\ORADATA\CDB\PDB\SYSTEM01.DBF
通道 ORA_DISK_1: 正在读取备份片段 D:\PDB_SYS_01OH54LF_1_1.RMAN
通道 ORA_DISK_1: 段句柄 = D:\PDB_SYS_01OH54LF_1_1.RMAN 标记 = TAG20130812T223943
通道 ORA_DISK_1: 已还原备份片段 1
通道 ORA_DISK_1: 还原完成, 用时: 00:00:16
完成 restore 于 13-8月 -13
RMAN> recover datafile 7;
启动 recover 于 13-8月 -13
使用通道 ORA_DISK_1
正在开始介质的恢复
线程 1 序列 314 的归档日志已作为文件 E:\APP\XIFENFEI\FAST_RECOVERY_AREA\CDB\ARCHIVELOG\2013_08_12\O1_MF_1_314_90KXOZSF_.
ARC 存在于磁盘上
线程 1 序列 315 的归档日志已作为文件 E:\APP\XIFENFEI\FAST_RECOVERY_AREA\CDB\ARCHIVELOG\2013_08_13\O1_MF_1_315_90MGSZ0X_.
ARC 存在于磁盘上
线程 1 序列 316 的归档日志已作为文件 E:\APP\XIFENFEI\FAST_RECOVERY_AREA\CDB\ARCHIVELOG\2013_08_13\O1_MF_1_316_90MH1FGD_.
ARC 存在于磁盘上
归档日志文件名=E:\APP\XIFENFEI\FAST_RECOVERY_AREA\CDB\ARCHIVELOG\2013_08_12\O1_MF_1_314_90KXOZSF_.ARC 线程=1 序列=314
介质恢复完成, 用时: 00:00:02
完成 recover 于 13-8月 -13
RMAN> exit
恢复管理器完成。
C:\Users\XIFENFEI>sqlplus / as sysdba
SQL*Plus: Release 12.1.0.1.0 Production on 星期二 8月 13 12:58:42 2013
Copyright (c) 1982, 2013, Oracle.  All rights reserved.
连接到:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
SQL> alter session set container=pdb;
会话已更改。
SQL> alter database open;
alter database open
*
第 1 行出现错误:
ORA-01147: SYSTEM 表空间文件 7 处于脱机状态
SQL> alter database datafile 7 online;
数据库已更改。
SQL> alter database open;
数据库已更改。
SQL> conn / as sysdba
已连接。
SQL> show pdbs;
    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB                            READ WRITE NO

整个操作过程说明一下问题
1.当pdb丢失数据文件或者影响dbwr,lgwr,ckpt等后台进程工作之时,将导致整个cdb crash,因为这些进程都是公用的
2.如果pdb丢失数据文件,通过在pdb中offline该文件,可以正常open cdb和其他pdb,不会长时间影响其他pdb工作
3.在cdb open的情况下,可以恢复pdb的任何数据文件(特殊pdb除外,root,seed之类)

某个pdb可以在root pdb open状态下进行恢复

联系:手机/微信(+86 17813235971) QQ(107644445)

标题:某个pdb可以在root pdb open状态下进行恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

最近在weibo上有流言:pdb的system还原的时候必须整个cdb处于mount状态下进行,我怎么也想不通ORACLE会这么蠢,如果这样,那如果一个pdb异常了,其他pdb都不能工作对业务影响太大了,经过测试证明事实是:某个pdb可以直接在root pdb open的状态下进行,不影响其他pdb

pdb的system文件备份

E:\dul10>rman target sys/xifenfei@pdb
恢复管理器: Release 12.1.0.1.0 - Production on 星期一 8月 12 22:38:58 2013
Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.
已连接到目标数据库: CDB (DBID=1937199326)
RMAN> backup tablespace system format 'd:/pdb_sys_%U.rman';
启动 backup 于 12-8月 -13
使用目标数据库控制文件替代恢复目录
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: SID=367 设备类型=DISK
通道 ORA_DISK_1: 正在启动全部数据文件备份集
通道 ORA_DISK_1: 正在指定备份集内的数据文件
输入数据文件: 文件号=00007 名称=E:\APP\XIFENFEI\ORADATA\CDB\PDB\SYSTEM01.DBF
通道 ORA_DISK_1: 正在启动段 1 于 12-8月 -13
通道 ORA_DISK_1: 已完成段 1 于 12-8月 -13
段句柄=D:\PDB_SYS_01OH54LF_1_1.RMAN 标记=TAG20130812T223943 注释=NONE
通道 ORA_DISK_1: 备份集已完成, 经过时间:00:00:15
完成 backup 于 12-8月 -13
启动 Control File and SPFILE Autobackup 于 12-8月 -13
段 handle=E:\APP\XIFENFEI\FAST_RECOVERY_AREA\CDB\AUTOBACKUP\2013_08_12\O1_MF_S_823300799_90KWY0OR_.BKP comment=NONE
完成 Control File and SPFILE Autobackup 于 12-8月 -13

使用系统命令强制删除pdb的system文件,使得open pdb之时提示文件不存在,然后使用rman进行还原恢复操作

还原恢复pdb system文件

E:\dul10>sqlplus / as sysdba
SQL*Plus: Release 12.1.0.1.0 Production onXQ 星期一 8月 12 22:43:27 2013
Copyright (c) 1982, 2013, Oracle.  All rights reserved.
连接到:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Product
With the Partitioning, OLAP, Advanced Analytics and Real Application Test
SQL> show pdbs;
    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB                            MOUNTED
SQL> alter session set container=pdb;
会话已更改。
SQL> alter database open;
alter database open
*
第 1 行出现错误:
ORA-01157: 无法标识/锁定数据文件 7 - 请参阅 DBWR 跟踪文件
ORA-01110: 数据文件 7: 'E:\APP\XIFENFEI\ORADATA\CDB\PDB\SYSTEM01.DBF'
SQL> exit
从 Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options 断开
E:\dul10>rman target sys/xifenfei@pdb
恢复管理器: Release 12.1.0.1.0 - Production on 星期一 8月 12 22:44:39 2013
Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.
已连接到目标数据库: CDB (DBID=1937199326, 未打开)
RMAN> restore datafile 7;
启动 restore 于 12-8月 -13
使用目标数据库控制文件替代恢复目录
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: SID=369 设备类型=DISK
通道 ORA_DISK_1: 正在开始还原数据文件备份集
通道 ORA_DISK_1: 正在指定从备份集还原的数据文件
通道 ORA_DISK_1: 将数据文件 00007 还原到 E:\APP\XIFENFEI\ORADATA\CDB\PDB\SYSTEM01.DBF
通道 ORA_DISK_1: 正在读取备份片段 D:\PDB_SYS_01OH54LF_1_1.RMAN
通道 ORA_DISK_1: 段句柄 = D:\PDB_SYS_01OH54LF_1_1.RMAN 标记 = TAG20130812T223943
通道 ORA_DISK_1: 已还原备份片段 1
通道 ORA_DISK_1: 还原完成, 用时: 00:00:35
完成 restore 于 12-8月 -13
RMAN> recover database;
启动 recover 于 12-8月 -13
使用通道 ORA_DISK_1
正在开始介质的恢复
介质恢复完成, 用时: 00:00:01
完成 recover 于 12-8月 -13
RMAN> alter database open;
已处理语句
RMAN>
RMAN> exit
恢复管理器完成。
E:\dul10>slqplus / as sysdba
'slqplus' 不是内部或外部命令,也不是可运行的程序
或批处理文件。
E:\dul10>sqlplus / as sysdba
SQL*Plus: Release 12.1.0.1.0 Production on 星期一 8月 12 22:46:36 2013
Copyright (c) 1982, 2013, Oracle.  All rights reserved.
连接到:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
SQL> show pdbs;
    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB                            READ WRITE NO