Windows环境下的ORA-7445(ACCESS_VIOLATION)和ORA-4030错误

Posted on 2011/10/06 by yangtingkun

客户Windows环境下32位的Oracle 10.2.0.3，在告警日志中发现多次ORA-7445和ORA-4030错误信息。
详细信息为：

Mon Aug 01 15:06:06 2011
Errors IN file e:\oradata\acscnprd\trc\usr\acscnprd_ora_3356.trc:
ORA-07445: exception encountered: core dump [ACCESS_VIOLATION] [unable_to_trans_pc] [PC:0x605033BB] [ADDR:0x4] [UNABLE_TO_WRITE] []
Mon Aug 01 15:06:06 2011
Errors IN file e:\oradata\acscnprd\trc\usr\acscnprd_ora_3356.trc:
ORA-04030: OUT OF process memory WHEN trying TO allocate 753120 bytes (pga heap,kco buffer)
ORA-07445: exception encountered: core dump [ACCESS_VIOLATION] [unable_to_trans_pc] [PC:0x605033BB] [ADDR:0x4] [UNABLE_TO_WRITE] []

仅从数据库的配置和错误信息分析，导致问题的原因多半是内存不足所致。这时一个32位的数据库，因此SGA分配一般而言不能超过1.7G，而当前数据库还没有配置到极限值，SGA总共配置了1.2G左右，而PGA只配置了400M左右，而数据库的连接数则超过了200。根据这些不难判断，Oracle的内存配置偏低。
而查询metalink，发现与当前问题最为接近的是ID 763705.1，问题影响的版本同样是10.2.0.3，同样包括ORA-4030和ORA-7445 [ACCESS_VIOLATION] [unable_to_trans_pc] [PC:XXXXXXX] [ADDR:XXX] [UNABLE_TO_WRITE]错误，唯一的区别在于，metalink上的这个问题发生在64位Windows环境中Oracle，而当前的Windows环境是32位。不过这篇文章中描述问题出现的原因同样和内存不足有关，那么很可能这个错误在32位环境中同样会出现。
接近这个问题的方法就是根据主机可用内存和32位系统的限制，来提高SGA和PGA的内存分配，保证Oracle日常操作有足够的内存可以使用。

Posted in BUG | Tagged , , , , , , , | Leave a comment

ORA-600(qknltAllocate_10)错误

Posted on 2011/10/05 by yangtingkun

虽然访问外部表时Oracle提供了ROWID伪列，但是尝试通过ROWID访问外部表就会导致这个ORA-600的错误。
外部表的ROWID信息：https://yangtingkun.net/?p=176
详细错误如下：

SQL> CREATE TABLE t_alert
  2  (text varchar2(1000)
  3  )
  4  organization external
  5  (TYPE oracle_loader
  6  DEFAULT directory d_alert
  7  access parameters
  8  (records delimited BY newline
  9  FIELDS (text (1:255) CHAR))
 10  location ('alert_ytk102.log'));
表已创建。
SQL> SELECT ROWID FROM T_ALERT WHERE ROWNUM < 10;
ROWID
-----------------------
(AADRCQAAAAAAAAAAAAAAAA
(AADRCQAAAAAAAAAAAAAAQQ
(AADRCQAAAAAAAAAAAAAAXA
(AADRCQAAAAAAAAAAAAAAhg
(AADRCQAAAAAAAAAAAAAAmg
(AADRCQAAAAAAAAAAAAAAtA
(AADRCQAAAAAAAAAAAAAA6g
(AADRCQAAAAAAAAAAAAABDA
(AADRCQAAAAAAAAAAAAABVg
已选择9行。
SQL> SELECT * FROM T_ALERT WHERE ROWID = '(AADRCQAAAAAAAAAAAAAAAA';
SELECT * FROM T_ALERT WHERE ROWID = '(AADRCQAAAAAAAAAAAAAAAA'
              *
第 1 行出现错误:
ORA-00600: 内部错误代码, 参数: [qknltAllocate_10], [53513], [], [], [], [], [], []
SQL> SELECT A.* FROM T_ALERT A WHERE A.ROWID IN (SELECT MIN(ROWID) FROM T_ALERT);
SELECT A.* FROM T_ALERT A WHERE A.ROWID IN (SELECT MIN(ROWID) FROM T_ALERT)
                *
第 1 行出现错误:
ORA-00600: 内部错误代码, 参数: [qknltAllocate_10], [53513], [], [], [], [], [], []
SQL> SELECT DBMS_ROWID.ROWID_OBJECT(ROWID) FROM T_ALERT WHERE ROWNUM = 1;
SELECT DBMS_ROWID.ROWID_OBJECT(ROWID) FROM T_ALERT WHERE ROWNUM = 1
       *
第 1 行出现错误:
ORA-06553: PLS-306: 调用 'ROWID_OBJECT' 时参数个数或类型错误
SQL> SELECT DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) FROM T_ALERT WHERE ROWNUM = 1;
SELECT DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) FROM T_ALERT WHERE ROWNUM = 1
       *
第 1 行出现错误:
ORA-06553: PLS-306: 调用 'ROWID_RELATIVE_FNO' 时参数个数或类型错误
SQL> SELECT DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) FROM T_ALERT WHERE ROWNUM = 1;
SELECT DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) FROM T_ALERT WHERE ROWNUM = 1
       *
第 1 行出现错误:
ORA-06553: PLS-306: 调用 'ROWID_BLOCK_NUMBER' 时参数个数或类型错误
SQL> SELECT DBMS_ROWID.ROWID_ROW_NUMBER(ROWID) FROM T_ALERT WHERE ROWNUM = 1;
SELECT DBMS_ROWID.ROWID_ROW_NUMBER(ROWID) FROM T_ALERT WHERE ROWNUM = 1
       *
第 1 行出现错误:
ORA-06553: PLS-306: 调用 'ROWID_ROW_NUMBER' 时参数个数或类型错误

无论用哪种方法，只要试图通过ROWID访问外部表就会导致这个ORA-600错误，可以看到，DBMS_ROWID包也是不支持外部表的ROWID的。

Tue Oct 04 18:13:40 2011
Errors IN file d:\oracle\product\admin\ytk102\udump\ytk102_ora_7764.trc:
ORA-00600: 内部错误代码, 参数: [qknltAllocate_10], [53513], [], [], [], [], [], []
Tue Oct 04 18:14:30 2011
Errors IN file d:\oracle\product\admin\ytk102\udump\ytk102_ora_7764.trc:
ORA-00600: 内部错误代码, 参数: [qknltAllocate_10], [53513], [], [], [], [], [], []

详细错误信息为：

Tue Oct 04 18:13:40 2011
ORACLE V10.2.0.5.0 - Production vsnsta=0
vsnsql=14 vsnxtr=3
Oracle DATABASE 10g Enterprise Edition Release 10.2.0.5.0 - Production
WITH the Partitioning, OLAP, DATA Mining AND REAL Application Testing options
Windows NT Version V6.1 Service Pack 1
CPU                 : 4 - TYPE 586, 2 Physical Cores
Process Affinity    : 0x00000000
Memory (Avail/Total): Ph:1914M/2995M, Ph+PgF:3697M/5989M, VA:1426M/2047M
Instance name: ytk102
Redo thread mounted BY this instance: 1
Oracle process NUMBER: 23
Windows thread id: 7764, image: ORACLE.EXE (SHAD)
*** ACTION NAME:() 2011-10-04 18:13:40.367
*** MODULE NAME:(SQL*Plus) 2011-10-04 18:13:40.367
*** SERVICE NAME:(SYS$USERS) 2011-10-04 18:13:40.367
*** SESSION ID:(141.3) 2011-10-04 18:13:40.367
*** 2011-10-04 18:13:40.367
ksedmp: internal OR fatal error
ORA-00600: 内部错误代码, 参数: [qknltAllocate_10], [53513], [], [], [], [], [], []
CURRENT SQL statement FOR this SESSION:
SELECT * FROM T_ALERT WHERE ROWID = '(AADRCQAAAAAAAAAAAAAAAA'
CHECK trace file d:\oracle\product\10.2.0\rdbms\trace\ytk102_ora_0.trc FOR preloading .sym file messages
----- Call Stack Trace -----
calling              CALL     entry                argument VALUES IN hex      
location             TYPE     point                (? means dubious VALUE)     
-------------------- -------- -------------------- ----------------------------
_ksedst+38           CALLrel  _ksedst1+0           0 1
_ksedmp+898          CALLrel  _ksedst+0            0
_ksfdmp+70           CALLrel  _ksedmp+0            3
0417C640             CALLreg  00000000             981C3B0 3
0417CA07             CALLrel  0417C5B4             981C3B0 573B20C 3B889D8 1
                                                   C2DB330
__VInfreq__qknltAll  CALLrel  _kgeasnmierr+0       981C3B0 573B20C 3B889D8 1 0
ocate+71                                           D109 0
_qkatab+4736         CALLrel  _qknltAllocate+0     
_qkajoi+296          CALLrel  _qkatab+0            
_qkaqkn+837          CALLrel  _qkajoi+0            
_qkadrv+686          CALLrel  _qkaqkn+0            574EB60 1 0 C2DB7B8
_opitca+1990         CALLrel  _qkadrv+0            574EB60 1
_kksLoadChild+8023   CALLrel  _opitca+0            577E184 247B8478
_kxsGetRuntimeLock+  CALLrel  _kksLoadChild+0      981C3B0 28480DFC C2DC910
1669                                               
_kksfbc+10697        CALLrel  _kxsGetRuntimeLock+  981C3B0 577E184 C2DC910 3 1
                              0                    
_kkspsc0+1728        CALLrel  _kksfbc+0            577E184 3 108 C2DD8BC 3E 0 0
                                                   0
_kksParseCursor+143  CALLrel  _kkspsc0+0           
_opiosq0+1923        CALLrel  _kksParseCursor+0    C2DCED0
_kpooprx+234         CALLrel  _opiosq0+0           3 E C2DD000 A4 0
_kpoal8+746          CALLrel  _kpooprx+0           C2DF63C C2DD8BC 3D 1 0 A4
_opiodr+1306         CALLreg  00000000             5E 17 C2DF638
60FFDE4A             CALLreg  00000000             5E 17 C2DF638 0
_opitsk+1102         CALL???  00000000             
_opiino+1081         CALLrel  _opitsk+0            0 0
_opiodr+1306         CALLreg  00000000             3C 4 C2DFBF8
_opidrv+819          CALLrel  _opiodr+0            3C 4 C2DFBF8 0
_sou2o+45            CALLrel  _opidrv+0            3C 4 C2DFBF8
_opimai_real+112     CALLrel  _sou2o+0             C2DFBEC 3C 4 C2DFBF8
_opimai+92           CALLrel  _opimai_real+0       2 C2DFC24
_OracleThreadStart@  CALLrel  _opimai+0            
4+726                                              
76F9ED67             CALLptr  00000000             
771B37F3             CALLreg  00000000             
771B37C3             CALLrel  771B37CE             
--------------------- Binary Stack Dump ---------------------

在metalink文档ID 395144.1中描述了这个错误，不过Oracle认为这并不是一个bug，因此也没有必要去解决，对这个问题的处理方法就是，不要尝试利用ROWID去访问外部表。看来外部表的ROWID唯一的作用可能就是用在ORDER BY语句中了。

Posted in BUG | Leave a comment

外部表的ROWID信息

Posted on 2011/10/04 by yangtingkun

ROWID是访问数据库中表的物理地址信息，Oracle提供了ROWID伪列，可以通过ROWID直接访问表中的数据。
ROWNUM固化外部表结果集存在问题：https://yangtingkun.net/?p=38
ROWNUM固化外部表结果集存在问题（二）：https://yangtingkun.net/?p=103
在测试外部表时，意外发现，外部表同样存在ROWID伪列：

SQL> CREATE directory d_alert AS 'D:\ORACLE\PRODUCT\ADMIN\YTK102\BDUMP';
目录已创建。
SQL> CREATE TABLE t_alert
  2  (text varchar2(1000)
  3  )
  4  organization external
  5  (TYPE oracle_loader
  6  DEFAULT directory d_alert
  7  access parameters
  8  (records delimited BY newline
  9  FIELDS (text (1:255) CHAR))
 10  location ('alert_ytk102.log'));
表已创建。
SQL> SELECT * FROM t_alert WHERE rownum < 10;
TEXT
-----------------------------------------------------------------------------
Dump file d:\oracle\product\admin\ytk102\bdump\alert_ytk102.log
Sat DEC 25 15:55:43  2010
ORACLE V10.2.0.5.0 - Production vsnsta=0
vsnsql=14 vsnxtr=3
Windows NT Version V6.1
CPU                 : 4 - TYPE 586, 2 Physical Cores
Process Affinity    : 0x00000000
Memory (Avail/Total): Ph:1594M/2995M, Ph+PgF:4318M/5989M, VA:1911M/2047M
Sat DEC 25 15:55:43  2010
已选择9行。
SQL> SELECT ROWID FROM T_ALERT WHERE ROWNUM < 10;
ROWID
-----------------------
(AADRCQAAAAAAAAAAAAAAAA
(AADRCQAAAAAAAAAAAAAAQQ
(AADRCQAAAAAAAAAAAAAAXA
(AADRCQAAAAAAAAAAAAAAhg
(AADRCQAAAAAAAAAAAAAAmg
(AADRCQAAAAAAAAAAAAAAtA
(AADRCQAAAAAAAAAAAAAA6g
(AADRCQAAAAAAAAAAAAABDA
(AADRCQAAAAAAAAAAAAABVg
已选择9行。

显然外部表的ROWID和普通表的ROWID有着明显的区别，其长度并非18位，换句话说，外部表的ROWID并非是OBJECT_ID + RELATIVE FILE_ID + BLOCK_NUMBER + ROW_NUMBER格式。
既然外部表的ROWID并不代表一个物理地址，因此一般也没有机会去使用这个ROWID，不过有时确实需要使用一个ROWID来解决真实的问题：

SQL> WITH A AS (SELECT ROW_NUMBER() OVER(ORDER BY ROWID) RN, TEXT FROM T_ALERT)
  2  SELECT * FROM A B 
  3  WHERE B.RN >= (SELECT MIN(C.RN) FROM A C WHERE TEXT = 'Mon Sep 19 07:18:21  2011');
        RN TEXT
---------- --------------------------------------------------------------------------------
      5739 Mon Sep 19 07:18:21  2011
      5740 Successfully onlined Undo Tablespace 1.
      5741 Mon Sep 19 07:18:21  2011
      5742 SMON: enabling tx recovery
      5743 Mon Sep 19 07:18:21  2011
      5744 DATABASE Characterset IS ZHS16GBK
      5745 Opening WITH internal Resource Manager plan
      5746 replication_dependency_tracking turned off (no async multimaster replication found)
      5747 Starting background process QMNC
      5748 QMNC started WITH pid=17, OS id=5412
      5749 Mon Sep 19 07:18:29  2011
      5750 Completed: ALTER DATABASE OPEN
已选择12行。

由于ROW_NUMBER分析函数需要一个ORDER BY排序字段，而在这个例子中，依赖于外部表的读取顺序，而并没有任何一个列能标识这个顺序，而ROWID变成了唯一的选项，恰好Oracle在实现外部表的伪列的时候，ROWID的大小是根据外部表数据读取顺序递增的，因此这里使用ROWID作为ORDER BY的排序列，可以满足查询的要求，这也是外部表ROWID有意义的应用之一。

Posted in ORACLE | Tagged , | 1 Comment

Database Firewall管理员手册

Posted on 2011/10/03 by yangtingkun

公司今后很多业务会和安全性有关，Oracle推出了Oracle Database Firewall，对这个产品目前还缺乏最基本的了解，先看看文档扫扫盲。
Oracle的这款安全性产品据说在国内还没有应用，不过随着国内环境对安全性越来越重视，相信不久之后就会有应用出现，所以现在进行一点知识储备还不算晚。
Database Firewall其实并不需要安装在数据库服务器上，它通过网络获取所有访问数据库的SQL语句，并送到专门的服务器上进行分析和报告。当然也可以在数据库服务器上安装一个本地的监视器，可以用来监控流量，以及一些用户和进程的直接访问。
这篇文档在官方网站在线地址是：http://download.oracle.com/docs/cd/E20465_01/doc/doc.50/e18695/toc.htm

Posted in BOOKS | Leave a comment

Logmnr获取SQL长度超过4000的问题

Posted on 2011/10/02 by yangtingkun

如果LOGMNR获取的SQL_REDO或SQL_UNDO的长度超过4000，则会导致Oracle自动合并拆分行记录。
一个简单的例子来描述这个问题：

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
DATABASE altered.
SQL> SELECT GROUP# FROM V$LOG WHERE STATUS = 'CURRENT';
GROUP#
----------
         2
SQL> ALTER SYSTEM SWITCH LOGFILE;
System altered.
SQL> SELECT GROUP# FROM V$LOG WHERE STATUS = 'CURRENT';
GROUP#
----------
         3
SQL> CREATE TABLE T_LARGE_SQL (ID NUMBER, COL1 VARCHAR2(4000), COL2 VARCHAR2(4000), COL3 VARCHAR2(4000));
TABLE created.
SQL> INSERT INTO T_LARGE_SQL VALUES (1, 'A', 'A', 'A');
1 ROW created.
SQL> INSERT INTO T_LARGE_SQL VALUES (2, LPAD('B', 4000, 'B'), LPAD('B', 4000, 'B'), LPAD('B', 4000, 'B'));
1 ROW created.
SQL> COMMIT;
Commit complete.
SQL> SELECT MEMBER FROM V$LOGFILE WHERE GROUP# = 3;
MEMBER
----------------------------------------------------------------------------------------
/oracle/oradata/orcl/redo03.log
SQL> ALTER SYSTEM SWITCH LOGFILE;
System altered.
SQL> EXEC DBMS_LOGMNR.ADD_LOGFILE('/oracle/oradata/orcl/redo03.log', DBMS_LOGMNR.NEW)
PL/SQL PROCEDURE successfully completed.
SQL> EXEC DBMS_LOGMNR.START_LOGMNR(OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG)
PL/SQL PROCEDURE successfully completed.
SQL> CREATE TABLE T_BAK_LOGMNR AS SELECT * FROM V$LOGMNR_CONTENTS;
TABLE created.
SQL> COL SQL_REDO FORMAT A80 WRAP
SQL> SELECT RS_ID, SSN, CSF, SQL_REDO FROM T_BAK_LOGMNR WHERE SEG_NAME = 'T_LARGE_SQL';
RS_ID                                   SSN        CSF
-------------------------------- ---------- ----------
SQL_REDO
--------------------------------------------------------------------------------
 0x000069.0000001a.005c                   0          0
CREATE TABLE T_LARGE_SQL (ID NUMBER, COL1 VARCHAR2(4000), COL2 VARCHAR2(4000), C
OL3 VARCHAR2(4000));
 0x000069.0000002a.0010                   0          0
INSERT INTO "TEST"."T_LARGE_SQL"("ID","COL1","COL2","COL3") VALUES ('1','A','A',
'A');
 0x000069.0000002a.01dc                   0          1
INSERT INTO "TEST"."T_LARGE_SQL"("ID","COL1","COL2","COL3") VALUES ('2','BBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
.
.
.
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
 0x000069.0000002a.01dc                   0          1
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB','BBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
.
.
.
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
 0x000069.0000002a.01dc                   0          1
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB','B
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
.
.
.
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
 0x000069.0000002a.01dc                   0          0
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB'
);
6 ROWS selected.

由于SQL_REDO和SQL_UNDO都是VARCHAR2(4000)类型的字段，当SQL本身很长导致长度超过4000时，必须通过多条记录来保存这一条语句。当发生这种情况时，除了SQL_REDO和SQL_UNDO外，V$LOGMNR_CONTENTS视图中通过RS_ID和SSN来唯一标识一条语句。而CSF则标识当前是否是语句的结束部分。
比较有意思的是，Oracle并没有给出一个顺序列来标识同一个语句的多个行记录之间的先后顺序。虽然默认情况下，这个顺序由Oracle自动保证，但是一旦用户在查询V$LOGMNR_CONTENTS视图时添加了排序字段，这时一个语句中的行记录顺序就可能无法保证，因此介于这种情况，对于查询V$LOGMNR_CONTENTS视图需要谨慎一些。

Posted in ORACLE | Tagged , , , , , | Leave a comment

Oracle发布Super Cluster

Posted on 2011/10/01 by yangtingkun

Oracle发布了最新的一体化设备：Super Cluster，这是基于Sparc架构的一体化设备。除了基于SPARC芯片外，Super Cluster与Exadata和Exalogic最大的区别在于，这款设备可以部署数据库、中间件和其他任意软件。
和Exadata和Exalogic架构类似，这款产品也是将Servers, Storage, Networking, Software集成在一起。
Nodes: 2 or 4 compute nodes
Storage Grid: 3 or 6 storage cells
Shared Storage: ZFS storage appliance with dual controllers
Software: Oracle Solaris 11 and Solaris 10
Oracle enterprise MANAGER Ops center
对于一个满配的SuperCluster包括下面硬件：
4*T4
6*Exadata Storage
1*zfs7320
3*sun network Infiniband
每个T4服务器包括：
4*SPARC T4 3.0HZ 8-core processor
32 * 2 * 16G DDR3 DIMMs(1T)
6*600G Internal drive
2*300G ssd
4*sun 10G network
4*qdr infiniband
此次发布的SuperCluster包含了两个新产品其中一个硬件Sparc T4服务器，一个软件Solaris 11。
SPARC T4 服务器：
单线程计算能力相对T3：整形提高5倍，浮点提高7倍
包括机型：T4-1B、T4-1、T4-2、T4-4
T4-4：3.0G with OOO execution;T4-2及以下 2.8G
Dedicated L2 128K cache
Shared L3 4M cache
8 Cores with Private L2 cache
Solaris 11操作系统：
Been designed for clouds – Zones, network virtualization, ZRS
BIG data: 128 ZFS with built in dedup, compression, crypto
Fast, secure boot and database startup
Mistake-roof patching and fast upgrade
Enterprise security with least privilege, auditing, restricted root
Network:
Built-in, no cost, network virtualization
Build out and control network access for applications
L3/L4 integrated load balancer
IP over Infiniband(IPoIB)
Lifecycle Management:
Package Management (Image Packaging);
Jumpstart 2.0 powered by AI,IPS;
Low Latency Oracle virtual environment
目前Oracle的一体化设备已经包括Exadata、Exalogic、SPARC Supercluster和刚刚面世不久的Appliance，看来Oracle正坚定的朝一体化的道路义无反顾的走下去。

Posted in NEWS | Leave a comment

高级应用开发者手册总结

Posted on 2011/09/30 by yangtingkun

这篇文档篇幅并不算很长，如果想对Oracle开发或优化方面了解更深入，建议还是读一下这篇文档。
虽然文档的名称叫做高级应用开发者手册，但是如果和现在目前在看的DATA CARTRIDGE开发手册相比，这篇文档就显得十分基础了。
而事实上这篇文章介绍的大部分内容都是基础知识，也包含了一些高级内容，全文分为SQL、PL/SQL和其他高级主题三部分。以SQL部分为例，有非常基础的部分如SQL数据类型、函数索引、约束等等，也有相对高级一些的内容，比如正则表达式和DOMAIN INDEX。
看完这篇文档后，除了巩固了一些基础外，感觉收获比较大的包括正则表达式、PL/SQL Hierarchical Profiler、闪回和版本。正则表达式以前没有用过，这篇文档算是入了个门，而闪回部分虽然没有包含FLASH DROP和FLASH DB的内容，这些属于管理的范畴，但已经是我目前看到所有文档里面最全面的一篇了：闪回查询、闪回版本查询、闪回事务、闪回事务版本查询、行SCN、DBMS_FLASHBACK包以及闪回数据归档，而且大部分的内容都会有具体的使用实例，并不是简单的概念介绍。而版本的内容也相当全面，尤其是利用版本升级部分，花了相当大的篇幅介绍CROSS TRIGGER。

Posted in BOOKS | Leave a comment

LOGMINER当前日志出现ORA-310和ORA-334错误

Posted on 2011/09/29 by yangtingkun

测试LOGMINER的时候出现了ORA-310和ORA-334错误。
测试代码如下：

SQL> SELECT GROUP# FROM V$LOG WHERE STATUS = 'CURRENT';
GROUP#
----------
         2
SQL> SELECT MEMBER FROM V$LOGFILE WHERE GROUP# = 2;
MEMBER
--------------------------------------------------------------------
/oracle/oradata/orcl/redo02.log
SQL> EXEC DBMS_LOGMNR.ADD_LOGFILE('/oracle/oradata/orcl/redo02.log', DBMS_LOGMNR.NEW)
PL/SQL PROCEDURE successfully completed.
SQL> EXEC DBMS_LOGMNR.START_LOGMNR(OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG)
PL/SQL PROCEDURE successfully completed.
SQL> CREATE TABLE T_BAK_LOGMNR AS SELECT * FROM V$LOGMNR_CONTENTS;
CREATE TABLE T_BAK_LOGMNR AS SELECT * FROM V$LOGMNR_CONTENTS
*
ERROR at line 1:
ORA-00310: archived log contains SEQUENCE 98; SEQUENCE 95 required
ORA-00334: archived log: '/oracle/oradata/orcl/redo02.log'
SQL> ALTER SYSTEM SWITCH LOGFILE;
System altered.
SQL> EXEC DBMS_LOGMNR.END_LOGMNR
PL/SQL PROCEDURE successfully completed.
SQL> EXEC DBMS_LOGMNR.ADD_LOGFILE('/oracle/oradata/orcl/redo02.log', DBMS_LOGMNR.NEW)
PL/SQL PROCEDURE successfully completed.
SQL> EXEC DBMS_LOGMNR.START_LOGMNR(OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG)
PL/SQL PROCEDURE successfully completed.
SQL> CREATE TABLE T_BAK_LOGMNR AS SELECT * FROM V$LOGMNR_CONTENTS;
CREATE TABLE T_BAK_LOGMNR AS SELECT * FROM V$LOGMNR_CONTENTS
*
ERROR at line 1:
ORA-00310: archived log contains SEQUENCE 101; SEQUENCE 98 required
ORA-00334: archived log: '/oracle/oradata/orcl/redo02.log'
SQL> EXEC DBMS_LOGMNR.END_LOGMNR
PL/SQL PROCEDURE successfully completed.
SQL> SELECT GROUP# FROM V$LOG WHERE STATUS = 'CURRENT';
GROUP#
----------
         2
SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS';
SESSION altered.
SQL> SELECT GROUP#, SEQUENCE#, STATUS, FIRST_TIME, NEXT_TIME FROM V$LOG;
GROUP# SEQUENCE#  STATUS           FIRST_TIME          NEXT_TIME
---------- ---------- ---------------- ------------------- -------------------
         1 100        INACTIVE         2011-09-29 17:03:26 2011-09-29 17:03:51
         2 101        CURRENT          2011-09-29 17:03:51
         3 99         INACTIVE         2011-09-29 17:02:52 2011-09-29 17:03:26

第一次出现这个错误的时候，很快意识到自己犯了一个低级的错误，对当前日志进行了LOGMINER，导致错误的产生。
但是SWITCH LOGFILE之后，问题居然仍然会出现。检查当前的日志，发现当前日志居然又会到了GROUP 2，说明第二次进行LOGMINER的时候同样是当前日志。
仔细整理了一下思路，发现问题的原因。第一次导致错误的时候只是认为是由于LOGMINER当前日志所致，并没有仔细研究错误信息。由于采用CREATE TABLE AS SELECT * FROM V$LOGMNR_CONTENTS的方法，且视图中查询的是当前日志中的信息，就会导致CREATE TABLE产生的日志出现在V$LOGMNR_CONTENTS视图中，而视图中的记录使得CREATE TABLE产生更多的内容，并最终导致了一个死循环。
当联机日志写满后，Oracle自动切换，但是LOGMINER并没有结束，而是继续抽取新的日志，知道三个日志都被写满，这是Oracle要切换的时候发现第一个日志仍然被使用，于是出现了ORA-310和ORA-334的错误。而第二次开始前的切换，恰好使得联机日志切回第二个日志，于是错误完全的重演了一次。

Posted in ORACLE | Tagged , , | Leave a comment

DBSNMP用户的BSLN_INTERNAL出现ORA-6502错误

Posted on 2011/09/28 by yangtingkun

11.2.0.2环境的数据库，出现了ORA-12012和ORA-6502错误。
在alert文件中发现了这个错误，详细错误信息如下：

2011-09-04 00:00:01.014000 +08:00
Errors IN file /u01/app/oracle/diag/rdbms/fhacdb1/fhacdb1/trace/fhacdb1_j000_13709.trc:
ORA-12012: error ON auto EXECUTE OF job "SYS"."BSLN_MAINTAIN_STATS_JOB"
ORA-06502: PL/SQL: NUMERIC OR VALUE error
ORA-06512: at "DBSNMP.BSLN_INTERNAL", line 2073
ORA-06512: at line 1

其中TRACE信息内容基本上和上面的错误信息一致，没有更多有价值的东西。
检查错误信息可以发现，出现错误的是SYS下的JOB，而报错的过程是DBSNMP下的BSLN_INTERNAL，怎么看都是Oracle内部的东西，显然从错误信息就可以判断，这是一个bug。
查询了一下metalink，发现在11.1.0.7上就有这个问题：Bug 10110625: DBSNMP.BSLN_INTERNAL RECEIVES ORA-06502，可惜的是Oracle目前只是确认了这个bug，解决方案和补丁目前都还没有。
不过好在问题只是偶尔出现，且对数据库来说并没有太多的影响，因此可以忽略掉。

Posted in BUG | Tagged , , | 1 Comment

会话级指定和提示级指定OPTIMIZER_FEATURES_ENABLE结果不同

Posted on 2011/09/27 by yangtingkun

帮客户优化时发现，同样是OPTIMIZER_FEATURES_ENABLE参数，在会话级设置和在HINT中指定的效果不同。
客户的数据库从11.1.0.6升级到最新的11.2.0.2之后，一些原本运行正常的SQL，查询性能变得比较差，尝试利用OPTIMIZER_FEATURES_ENABLE方式来恢复原始的执行计划，但是发现有时在会话级设置OPTIMIZER_FEATURES_ENABLE参数执行计划并没有改变，而如果直接在SQL中设置OPTIMIZER_FEATURES_ENABLE提示，则可以使得SQL的执行计划恢复到升级之前。
由于SQL 本身比较复杂，而且事实上和当前这个主题的关系不大，这里就不列出来了。一共针对6个性能变差的SQL进行调整，发现如果使用ALTER SESSION SET OPTIMIZER_FEATURES_ENABLE = ’11.1.0.6’的方式，则有3个语句恢复11.1.0.6中的执行计划，而对于另外3个执行计划并没有改变。
而如果尝试在SQL中直接嵌入提示/*+ OPTIMIZER_FEATURES_ENABLE(’11.1.0.6’) */结果发现其中5个SQL恢复了11.1.0.6的执行计划，而只有1个SQL执行计划没有改变。
虽然一直都清楚，使用OPTIMIZER_FEATURES_ENABLE并不能100%保证SQL的执行计划恢复到指定版本，但是确实没有想到，OPTIMIZER_FEATURES_ENABLE在提示中指定和在会话级设置还会有所区别。如果说HINT的优先级更高会覆盖会话级设置，这可以理解，但是二者效果有所区别，就说不过去了。除非是OPTIMIZER_FEATURES_ENABLE在会话级的设置不足以覆盖某些其他的会话级参数设置，从而导致这个现象的产生。

Posted in ORACLE | Tagged , , | Leave a comment