Fans Or Not » Database

Oracle NoSQL Database

Zeeno — Wed, 19 Oct 2011 02:08:55 +0000

Oracle 终于放出了NoSQL Database的文档和二进制下载。

NoSQL并不意味着SQL或数据库的终结，而是关系型数据库的延伸。在Web2.0时代，技术人员需要扩展性更强的数据库系统以部署在众多的廉价（或昂贵）服务器上，传统的RDBMS并非最佳选择。Oralce已经拥有多款RDB产品，Oracle Database、MySQL、TimeTen等等，如今NoSQL Database的推出势必会将人们非关系型数据库的目光重新拉回Oracle身上。

可以预知的是，NoSQL Database必然会与MongoDB、SimpleDB、Bigtable、HBase之类不同，虽然也是Key-Value，但会重新定义Key-Value，之因为Oracle是霸道的搅局者，侵略者，同时也是领导者。

更多信息请访问Oracle NoSQL Database。

Large Page Size

Zeeno — Mon, 05 Sep 2011 02:42:11 +0000

Oracle Database从10g开始就支持Windows平台的Large Page，该特性有助于更快的访问数据库buffer。11gR2的文档中指出在默认情况下，最小的large page size是16M，但事实上，有人统计出如下数据：

SGA_TARGET	Large Page Request Size
256M	4,194,304
512M	4,194,304
1G	4,194,304
1G + 1 byte	16,777,216
2G	16,777,216
4G	16,777,216
8G	16,777,216
8G + 1 byte	33,554,432
16G	33,554,432
32G	67,108,864
64G	134,217,728
64G + 1 byte	268,435,456

如果配置为large page support，在长时间运行的服务器上重新启动实例可能会出现如下错误：

ORA-27102: out of memory
OSD-00022: additional error information
O/S-Error: (OS 1450) Insufficient system resources exist to complete the requested service.

该问题，在微软的Large-Page Support介绍中已经描述过：当系统运行一段时间后，内存可能会形成碎片，此时将无法获取连续的内存空间。而large page，需要连续的内存空间。

解决办法有两种，一是将ORA_LPENABLE设置为0，取消large page support；二是重启服务器以清理内存碎片。

利用RMAN的增量备份快速同步Standby

Zeeno — Tue, 30 Aug 2011 05:59:54 +0000

当因为某种原因(比如网络问题)导致Primary和Standby的Archive Gap多到一个难以追赶的数目时，为了节省时间，可能还不如重建Standby来的方便。此时可以使用RMAN的增量备份快速同步，将这个过程缩减到最小。

1，检查archive log sequence#

--Primary
SELECT MAX(sequence#) FROM v$archived_log;
--Standby
SELECT MAX(sequence#) FROM v$log_history;

如果数目相差巨大，请检查standby相关功能是否正常。

2，若功能正常，为了快速roll forward，先停止standby:

SQL> alter database recover managed standby database cancel;

3，检查SCN:

SQL> SELECT CURRENT_SCN FROM v$database;

CURRENT_SCN
-----------
    4143274

也可以通过使用recover standby database的错误提示来获取下一个SCN。暂时shutdown该库。

4，在Primary上进行差异备份

RMAN> backup incremental from scn 4143275 database format 'D:\stdby_%U.bkp';
SQL> alter database create standby controlfile as 'D:\stdby_test.ctl';

这一步是关键，从中断的SCN进行备份，并创建新的standby controlfile。

5，Copy到Standby机器上，并恢复。可以用catalog backuppiece导入新的备份文件。

RMAN> catalog backuppiece 'D:\TEST_52ML9RRT_1_1.BKP';

using target database control file instead of recovery catalog
cataloged backup piece
backup piece handle=D:\TEST_52ML9RRT_1_1.BKP RECID=126 STAMP=760542472

RMAN> catalog backuppiece 'D:\TEST_53ML9RTK_1_1.BKP';

cataloged backup piece
backup piece handle=D:\TEST_53ML9RTK_1_1.BKP RECID=127 STAMP=760542483

RMAN> recover database noredo;

先mount standby database，再做recover。

6，shutdown standby，然后替换standby controlfile。重新mount standby database，并开启日志应用。

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

整个过程，唯一需要留意的就是获取正确的SCN。
相关链接：http://www.dba-village.com/village/dvp_papers.PaperDetails?PaperIdA=5766

PHP和DRCP小记

Zeeno — Tue, 16 Aug 2011 03:33:13 +0000

(2007年就有了，只是最近涉及，才略有关注。是以记录之)

根据DRCP的技术白皮书介绍，凡是使用OCI, OCCI, JDBC, ODP.NET等方式进行连接的应用都可以充分利用DRCP功能，最为典型的，估计就是Apache+PHP之类单线程应用。

DRCP简单配置：

BEGIN
  -- 通过DBMS_CONNECTION_POOL包配置默认的SYS_DEFAULT_CONNECTION_POOL
  DBMS_CONNECTION_POOL.CONFIGURE_POOL(POOL_NAME              => NULL,
                                      MINSIZE                => 10,
                                      MAXSIZE                => 100,
                                      INCRSIZE               => 2,
                                      SESSION_CACHED_CURSORS => 20,
                                      INACTIVITY_TIMEOUT     => 300,
                                      MAX_THINK_TIME         => 600,
                                      MAX_USE_SESSION        => 500000,
                                      MAX_LIFETIME_SESSION   => 86400);
  -- 启动。也可以略过上述配置直接启动默认连接池
  DBMS_CONNECTION_POOL.START_POOL();
  -- 停止
  DBMS_CONNECTION_POOL.STOP_POOL();
END;

几张有用的视图：
1. DBA_CPOOL_INFO 连接池状态和配置信息
2. V$CPOOL_STATS 连接池统计信息
3. V$CPOOL_CC_STATS 连接池分类统计信息

再对TNSNAMES.ORA进行调整，加上SERVER=POOLED，表示连接到连接池而不是DEDICATED方式：

MYAPP =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = myapp.example.com)
      (SERVER=POOLED)
    )
)

PHP简单配置：
PHP需要启用php_oci8_11g这个extension，在php.ini有针对DRCP的配置项

; Connection: Set this to a user chosen connection class to be used
; for all pooled server requests with Oracle 11g Database Resident
; Connection Pooling (DRCP).  To use DRCP, this value should be set to
; the same string for all web servers running the same application,
; the database pool must be configured, and the connection string must
; specify to use a pooled server.
oci8.connection_class =MYPHP

connection_class用于区分连接分类，可以跨应用使用同一个分类。如果不指定connection_class，则系统会自动分配一个唯一标识，但这样会导致多个应用使用同样认证信息的情况下，会启用多个分类，无法共享session池。

Oracle给出了一个统计数据：假设每个session需要400K内存，每个服务器进程需要4M内存，连接池和shared server大小都是100，在5000个客户端连接的情况下，内存使用数据如下:
Dedicated Server Memory used = 5000 X (400 KB + 4 MB) = 22 GB
Shared Server Memory used = 5000 X 400 KB + 100 X 4 MB = 2.5 GB
DRCP Memory used = 100 X (400 KB + 4 MB) + (5000 X 35KB)= 615 MB

在没有应用层连接池的环境下，启用DRCP是一个非常有益的尝试。

中小型企业的数据库系统选择

Zeeno — Fri, 05 Aug 2011 11:57:07 +0000

首先，这里只定位于中小型企业，或者换个角度来说，数据库大小处于TB级，每年增长200G左右，日常使用最高并发人数大概300左右，每日发生的事务不超过200万笔。在这个规模下，我们如何选择合适的数据库管理系统？

所谓的企业内部应用系统，这里是指IT企业（软件公司、网络公司）之外的做实业的企业，在这类企业里绝大多数只考虑商业解决方案，所谓的商业方案，当然排除了PostgreSQL、MySQL之类的系统，事实上，在数据库领域，主要只是考虑这么四类产品：Oracle，SQL Server，DB2以及Sybase，当然零星的一些小系统也会考虑MySQL之类当时的非主流产品，但是这类产品往往不入职业IT经理的法眼。大约2005年及之前，Oracle Database主要是9i版本(10g刚刚推出)，SQL Server主要是2000版本，这个年代的选择非常简单，无它，Oracle的集群和Dataguard在当年是处于非常优势并且显眼的地位的，“大系统”选Oracle，“小系统”选SQL Server，几乎不需要动脑筋。没有哪个公司会专门养几个小众的fans来研究小系统大应用。

但是在SQL Server 2005出来后，这个世界貌似出现了点变化。2005版本开始的HA方案和DR方案开始成熟，从数据库集群到数据库镜像，从日志传输到数据库复制，已经初步夯实了大型应用的基石。虽然2000版本就已经存在了log shipping的简陋HA方案，但是这与其说是HA，不如说是快速事务日志备份和传输方案。只有2005版的镜像技术解决了实时同步的问题，配合精心的failover设计，可以解决大多数可用性难题。也就是说，只有到了2005版本，SQL Server的HA方案才值得单独一提。

随着SQL Server 2008的推出，上述四类HA特性得到了加强，比如数据库镜像方案中的日志压缩传输，再比如自动页修复，这个很类似Oracle的block repair。尤其的，在2008版本中各种功能可以自由搭配组合，可以将数据库镜像搭配Failover集群、Log Shipping、快照和Replication等各类功能组成牢固的可靠的数据库系统。

去年，SQL Server Denali的CTP1版本让人看到了更加强大的企业级HA特性，尤其是组合Windows 2008 R2强大的WSFC(Windows Server Failover Clustering)功能后，可以对整个数据库应用进行强化。这里有一点Oracle DBA们可能不是很理解，SQL Server的Instance和Database，跟Oracle的同类数据有着几乎完全相反的意思，简单来说，SQL Server是单个实例操作多个数据库，而Oracle则是多个实例操作单个数据库。事实上，很多资深的Oracle DBA在跳出专业的小圈子接手多个数据库系统时，往往会有一段时间的不适应。在SQL Server的世界里，往往可以见到一个实例下挂着N个数据库。这里需要提起的时，之前所述的HA方案，都是基于单个Database而言的，面对数目众多的Database时，对整套应用所用的数据库进行failover会有点烦。所以Denali中完善的AlwaysOn Availability Groups解决了这个问题。

到了这个时代，Oracle的RAC、Dataguard、Streams、SecureFiles等等令人津津乐道的强大功能，至少光从功能角度来说，SQL Server Denali都给出了对应的解决方案——除了RMAN。我认为SQL Server目前最大的一个不足，就是其本身没有良好的备份、恢复解决方案，虽然基于单个Database的操作异常简单，但是缺乏一个类似RMAN的体验良好的管理器，在对于N个数据库的恢复时非常没有效率。

之所以花这么多篇幅介绍SQL Server而不是其他，是因为DB2多数存在于大型系统中，Sybase已末路黄花，新行业新应用很少选择了，NoSQL世界依旧水中花，SAP的MaxDB基本上挂了，其他开源DBMS则很少涉足企业级应用。在本文所限定的中小型企业级应用系统中，对于数据库系统的选择基本上集中在SQL Server和Oracle两者。尽管Denali还只是CTP3，还没有正式发布，但其增长势头不容忽视，从可见的功能上说，已经并不明显逊于Oracle 10g。

在当前讲究软件+硬件的整体解决方案世界里，如果你还不需要云Box，如果你不是Oracle Fans，如果稍微理性一点，或许SQL Server已经可以在你的备选目录中稍微往上移一位了。

SQL Server Denali的FileTable简介

Zeeno — Mon, 01 Aug 2011 07:46:26 +0000

老一辈的DBA们在处理非结构化数据时可能会条件反射的有这么一种思路：将二进制文档、图片等存放于文件系统上，在数据库中记录其元数据，这种经典方案一直持续到Oracle 11g的推出，在SecureFiles的理念得以普及后，一些企业级应用的非结构化数据存储方案有了更多的选择。今天，SQL Server Denali也引入了这个功能，命名为FileTable。

FileTable基于SQL Server 2008引入的FileStream功能进行构建，在概念和功能上都和SecureFiles几乎一致，充分利用了DBMS的优势来管理非结构化数据，同时也打通了文件系统的壁垒，直接通过Windows资源管理器来访问FileTable文件夹。这种特性使非结构化数据的全文索引、SQL操纵文件、基于DBMS的安全机制和快速访问机制等得以轻松的实现。

在SQL Server中启用FileTable的方式非常简单，只需要启用数据库级的非事务型访问(和FILESTREAM的配置是相对独立的)，然后就可以通过SQL Server Management Studio或者简单的TSQL来创建FileTable了：

CREATE TABLE DocumentStore AS FileTable
    WITH (
          FileTable_Directory = ’DocumentTable’,
          FileTable_Collate_Filename = database_default
         );
GO

在denali(至少到CTP3为止)中，相比其他功能而言，FileTable目前还不支持以下功能：

不支持分区
不支持分发(Replication)
Windows中无法进行回滚或恢复等操作(TSQL可以)
自服务数据库(Contained Databases)的支持尚不完善
在备份恢复方面，因为启用非事务型访问，所以无法实现常规意义的基于事务日志的PIT(Point-in-Time)恢复。
对于Windows文件操作，无法进行审计(Audit)

继Oracle和SQL Server之后，估计还会有更多的DBMS会陆续增加类似特性。

APEX 上传xls文件

Zeeno — Sun, 22 Aug 2010 02:31:29 +0000

上一篇文章介绍了APEX中上传文件的方式，以纯文本文件为例说明了如何对上传的文件进行后续处理。PL/SQL可以直接对纯文本内容进行处理，那么如果直接上传xls二进制文件呢？通常，可以用Java Procedure做这件事，但是自APEX Listener 1.x 发布后，有更简单的方式实现对xls内容的处理。 1.10 版本之后，apex-config.xml 中多了下面这个参数： false 将该参数设置为true则开启excel到collection的转换功能，简单设置步骤如下： 1. 添加File Browse…的Page Item，名字为P1_FILENAME，Storage Type 为 WWV_FLOW_FILES 2. 添加名为UPLOAD的Button Item，Button Request 设置为 xls2collection 运行该页面，选择一个xls后缀的Excel文件，点击UPLOAD按钮即可上传该Excel文件。上传的文件和数据分别存放在wwv_flow_files和apex_collections中。其中COLLECTION_NAME的默认名称为Page Item的名称，此例中为P1_FILENAME，C001为Excel的TAB页名称，接下来的各字段为表格内容。 SELECT * FROM apex_collections a WHERE a.collection_name = 'P1_FILENAME' apex_collections是视图，限制了security_group_id，你需要在应用程序中，并且是当前会话中使用。删除Collection方式为： apex_collection.delete_collection(p_collection_name => 'P1_FILENAME'); 详细说明可参考APEX 4.0的API Reference文档中的APEX_COLLECTION章节。有了APEX Listener，很多事情变得更简单了，当然，除了文档，APEX的文档令人吃惊的简单，很多内容都没有提及。

APEX 4 中的文件上传功能

Zeeno — Fri, 13 Aug 2010 00:24:00 +0000

有一个APEX小应用需要提供Excel数据上传功能，并且要对上传的数据进行后续加工处理，于是就有了下面这段有点通用的代码。

APEX 4.0中上传的存储位置有两个选择，一个是集中式的WWV_FLOW_FILES，一个是自定义的表。对于前者我不喜欢，所有应用上传的文件都存储在一个地方，有些时候管理起来不够方便；如果是自定义的表，每个应用单独存放，那么不论在迁移还是某些维护都相对简单，当然，对于上传功能的设计而言就需要多花几分钟时间了。下面是自定义表的一个例子。

1. 先创建存储表

attach_data	blob	二进制数据
attach_mimetype	varchar2(255)	文件类型
attach_filename	varchar2(255)	文件名
attach_last_update	date	上传时间
attach_charset	varchar2(128)	字符集
attach_id	number	文件ID

一般而言，最好将该表最小化，包含必须的几个字段即可，如果需要和其他表关联，则可以通过ATTACH_ID关联。

2. APEX页面中增加File…上传的item，属性设置如下：

3. 添加提交表单的按钮，提交时触发一次Automatic Row Processing (DML)的Process，设置表名和主键，系统会自动将相关数据（包括上传的文件）插入对应的表中。关于主键ID的自动生成，可以在After header位置增加一个自动fetch row的设置即可。

4. 文件上传功能本身是非常简单的，接下来是针对该上传文件的后续处理。在顺序上，要先有处理上传的Process(就是第3步)，然后再有后续处理的Process。手工在Page Process处再添加一个名为Parsing Attachment(名字随意)的Process，在Source处理加入匿名PL/SQL代码。例如我喜欢直接调用写好的包，那就写上：

process_upload.process_file_upload;

这里需要用户首先对Excel做一个另存为文本文件的操作，目前为止，我还没发现可以用PL/SQL来直接操作二进制Excel文件。如果有必要，可以考虑使用Java Procedure对Excel文件进行处理。

附上几段代码：

PROCEDURE process_file_upload IS
    l_blob_data       BLOB;
    l_blob_len        NUMBER;
    l_position        NUMBER;
    l_raw_chunk       RAW(2);
    l_raw_line        RAW(32767);
    l_line            VARCHAR2(32767) DEFAULT NULL;
    l_array           wwv_flow_global.vc_arr2;
    l_first_line_flag BOOLEAN;
  BEGIN
    SELECT s.attach_data
      INTO l_blob_data
      FROM sw_detail_attachment s
     WHERE s.attach_id = v('P7_ATTACH_ID');

    DELETE FROM sw_detail_attachment s
     WHERE s.attach_id = v('P7_ATTACH_ID');

    l_blob_len        := dbms_lob.getlength(l_blob_data);
    l_position        := 1;
    l_first_line_flag := TRUE;
    WHILE (l_position <= l_blob_len) LOOP
      l_raw_chunk := dbms_lob.substr(l_blob_data, 1, l_position);

      -- chr(10)
      IF l_raw_chunk = utl_raw.cast_to_raw(chr(10)) THEN
        l_line := utl_raw.cast_to_varchar2(l_raw_line);
        -- remove carriage return
        l_line  := REPLACE(l_line, chr(13), '');
        l_array := string_to_table(l_line);

        IF NOT l_first_line_flag THEN
          insert_data(l_array);
        END IF;
        l_raw_line        := NULL;
        l_first_line_flag := FALSE;
      ELSE
        l_raw_line := l_raw_line || l_raw_chunk;
      END IF;
      l_position := l_position + 1;

    END LOOP;
  END process_file_upload;

上传的文件是以TAB分割的Excel表格数据，我这里先取出文件数据放到l_blob_data中，然后针对换行符进行分割(Windows文件还需要清理掉回车符号)，再对每一行使用标准函数wwv_flow_utilities.string_to_table进行解析。该函数可能存在一个问题，就是如果Excel最后一列数据为空，将导致解析后的列数缺少一列，我用下面这种方式修复该问题：

FUNCTION string_to_table(x_str IN VARCHAR2) RETURN wwv_flow_global.vc_arr2 IS
    l_col_num NUMBER := 20;
    l_array   wwv_flow_global.vc_arr2;
  BEGIN
    -- CHR(9) is tab key
    l_array := wwv_flow_utilities.string_to_table(x_str, chr(9));

    IF l_array.count = l_col_num - 1 THEN
      l_array(l_col_num) := NULL;
    END IF;

    RETURN l_array;
  END string_to_table;

Excel数据还可以采用复制粘贴的方式直接通过表单提交上去，不过，如果Excel文件内容比较复杂，存在多个标签页，则直接上传导入Oracle数据库应该还是有相当大的需求的，如果有时间做一个配置性强的上传插件的话估计下载量会不少。

Update
APEX 4.0.1 的一个bug：如果采用非WWV_FLOW_FILES表存储上传的文件，如果用IE内核的浏览器，无法上传任何数据。

EBS 11i数据库升级(9i->10g)几点事项

Zeeno — Wed, 09 Jun 2010 07:31:00 +0000

最近几日在评估和测试EBS的系统升级(11i升级到R12)，虽然官方的升级文档里介绍的比较详细了，但是依旧会出现一些容易疏忽的问题，这里做一些记录。这里并不是单纯的数据库升级，需要考虑EBS的特殊应用。对于升级方案，标准的有三种：

同时升级数据库和应用。
先升级数据库到10gR2，然后升级应用到R12。
先升级数据库到11gR2，然后升级应用到R12。

其中第2和第3种方案有点类似，都是将整个升级方案划分为两个阶段，只是数据库版本不同。实际上，从技术上看，第1种方案也是两步走，只是在应用层跳过一些过渡性的补丁直接升级到R12。

在数据库升级方面，升级路线主要有下面两种：

路线1: 9.2.0.6 -> 9.2.0.8 -> 11.2.0.1
如果是Solaris系统，则要求系统版本至少为 Solaris 10 Update 6。
路线2: 9.2.0.6 -> 10.2.0.1 -> 10.2.0.4
注：最新patchset是10.2.0.5，只是升级文档依旧停留在10.2.0.4。

从一般认识上讲，Oracle数据库在下一个大版本出来后，上一个版本才被认为是相对更稳定的，所以此处选择第二条路线。

数据库升级方式简单而言有以下几种：

DBUA，直接通过图形化工具升级，这个最简单。
Manual，类似于上一种方式，只是手工进行各个步骤的升级操作。
Export/Import
有利于数据表的整理，重构数据库，比如修改字符集、数据文件、表空间参数等，在升级时间上，比DBUA和Manual两种方式都要长。
利用数据复制等技术，升级备用环境后再切换。

由于允许停机，并且暂无特殊的要求，所以这里使用DBUA做升级操作。

在升级之前，建议卸载statspack，并且先解决Invalid Objects的问题。此外，数据库升级后DBLINK需要重建，所以先准备相关重建脚本。下面按照文档步骤升级数据库9.2.0.6 至 10.2.0.4，每个步骤都列在下面，对几个步骤中需要额外关注的地方做了备注。

Verify software versions
检查现在软件版本，基本上应该不会有问题的，留意一下AD版本，最新版本是11i.AD.I.7，不过要求11i.AD.I.6就可以了。
Migrate to Oracle Portal 10g (conditional)
Deregister the current database server (conditional)
Update application tier context file with new database listener port number (conditional)
Export OLAP analytical workspaces (conditional)
Prepare to create the 10.2.0 Oracle home
设置ORACLE_HOME环境变量，如 export ORACLE_HOME=/u08/test/proddb/10.2.0
Install the base 10.2.0 software
安装10gR2软件，不要选择升级现有数据库，因为要先打一些补丁。这个过程最后会写oraclehomproperties.xml，要保证对应目录有可写权限。比如我曾遭遇了这个错误
inventory/ContentsXML/oraclehomproperties.xml (Permission denied).
Install Oracle Database 10g Products from the 10g Companion CD

Perform 10.2.0.4 patch set pre-installation tasks
这是正常的打数据库补丁操作，留意几个环境变量的修改就可以了。如：

export PATH=$ORACLE_HOME/bin:$ORACLE_HOME/perl/bin:$PATH
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH
export PERL5LIB=$ORACLE_HOME/perl/lib:$ORACLE_HOME/perl/lib/site_perl:$PERL5LIB

Perform 10.2.0.4 patch set installation tasks
Create nls/data/9idata directory
Apply additional 10.2.0.4 RDBMS patches
Shut down Applications server processes and database listener
Prepare to upgrade
Upgrade the database instance
执行utlu102i.sql查看升级后的变动情况，然后执行DBMS_STATS.GATHER_SCHEMA_STATS 收集统计数据以加快升级速度。在升级的时候如果没有列出所需的ORACLE_HOME，则需要检查并整理一下oratab。
Modify initialization parameters
对于sga_target等参数，最好先计算以下之前的SGA大小再设置，其余的参考文档设置即可。
Additional database configuration
Perform 10.2.0.4 patch set post-installation tasks
Install Oracle Data Mining and OLAP
Natively compile PL/SQL code (optional)

Fix Korean lexers
升级韩语分词，对于简体中文用户不必进行。
注意：如果将来需要升级EBS至R12，则这一步是必须的，否则升级过程中会出错：

Uploading from staging tables
  Error loading seed data for CS_KB_SOLN_CATEGORIES_VL:  CATEGORY_ID = 1,  ORA-29877: failed in the execution of the ODCIINDEXUPDATE routine
ORA-20000: Oracle Text error:
DRG-50857: oracle error in textindexmethods.ODCIIndexUpdate
ORA-20000: Oracle Text error:
DRG-10602: failed to queue DML change to column   for primary key
DRG-13201: KOREAN_LEXER is desupported
ORA-30576: ConText Option dictionary loading error

Import OLAP analytical workspaces (conditional)
同上，如果将来需要升级EBS至R12，则这一步是必须的，稍微不同的时，到时可以不必做“升级”操作，而是直接删除重建：

exec dbms_aw.execute('aw delete zpb.zpbcode');
exec dbms_aw.execute('aw delete zpb.zpbdata');
exec dbms_aw.execute('aw delete zpb.zpbannot');
sqlplus '/ as sysdba' @$APPL_TOP/zpb/12.0.0/patch/115/SQL/zpbmakeaws.sql

Start the new database listener (conditional)
Run adgrants.sql (conditional)
Grant create procedure privilege on CTXSYS
Implement and run AutoConfig
先检查TNS_ADMIN变量是否指向新的路径，并检查listener.ora，看SID_LIST_TEST中是否已经添加了相应的SID，netca创建的listener.ora可能会缺少这个信息。
这里尤其需要留意的是，adbldxml.pl 创建配置文件后，如果做adconfig.pl会报错：
```
Can't locate object method "runPipedCmd" via package "ADX::util::Sysutil" at /u08/test/proddb/10.2.0/appsutil/bin/adconfig.pl line 806.
```
这是由于PERL5LIB没有包含新的appsutil中的perl lib所致，手工加上再执行就可以了。
afdbprf.sh 这一步还会报错：
```
ORA-12504: TNS:listener was not given the SID in CONNECT_DATA
```
手工执行可以通过，可能是afdbprf.sh 中传递变量有问题。

Gather statistics for SYS schema
dbms_stats.gather_schema_stats这一步没有问题，但是执行dbms_stats.gather_fixed_objects_stats时会报错：

declare
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [1350], [1], [13], [], [], [], [],
[]
ORA-06512: at "SYS.DBMS_STATS", line 13210
ORA-06512: at "SYS.DBMS_STATS", line 13517
ORA-06512: at "SYS.DBMS_STATS", line 14039
ORA-06512: at line 3
ORA-06512: at line 33

这应该是个BUG，据说在11gR2中被修复了。

Re-create custom database links (conditional)
升级之前就已经准备好了DBLINK的重建脚本，直接重建即可。
Re-create grants and synonyms
Apply Oracle Receivables patch
Restart Applications server processes (conditional)

按标准步骤做完后，数据库成功升级到10.2.0.4，升级后需要留意以下事项：

检查 .profile ，使用使用新的环境变量。
如果有快速启动脚本之类的，看是否指向了新的路径。
检查AutoConfig新创建的env文件，看PATH变量是否正确，删除指向旧数据库的路径。

用adadmin重新生成messages并编译包，否则Web页面登录可能会报错：

oracle.apps.fnd.framework.OAException: Application: FND, Message Name: FND_GENERIC_MESSAGE. Tokens: MESSAGE = java.sql.SQLException: ORA-00003: Message 3 not found;  product=RDBMS; facility=ORA
ORA-06512: ? "SYS.DBMS_UTILITY", line 70
ORA-06512: ? line 1

最好转换SYSTEM表空间到Local Management。

主要参考文档
Database Preparation Guidelines for an E-Business Suite Release 12.1.1 Upgrade [ID 761570.1]
Oracle Applications Release 11i with Oracle 10g Release 2 (10.2.0) [ID 362203.1]

Planning Manager诊断过程和10046事件

Zeeno — Wed, 26 May 2010 08:37:46 +0000

在一次Planning Manager性能问题的诊断中，用到了Oracle ERP环境中非常典型的诊断操作和过程，特全程记录于此。

当发现某个程序存在性能问题时，首先当然是快速检查一下SESSION的相关信息，看看主要在执行或等待些什么：

SELECT stat.sid,
       n.name,
       n.class,
       stat.value
  FROM v$sesstat  stat,
       v$statname n
 WHERE stat.statistic# = n.statistic#
   AND stat.sid = 121
 ORDER BY upper(n.name);

这里观察到bytes received via SQL*Net from client, bytes sent via SQL*Net to client 和 SQL*Net roundtrips to/from client 都在飙升。这对应了两个events：SQL*Net message to client和SQL*Net message from client，这两个事件数值大并不意味着网络状况不好，前者仅仅表示Oracle数据库将数据放入TCP send buffer的时间，而后者表示从客户端接收到反馈指令的时间，两者反映了SQL*Net和数据库之间的时间消耗，而不是网络传输的时间消耗。基于对系统架构的了解，排除SQL*Net的性能问题，那么两个事件预示了什么呢？

SELECT * FROM v$sess_io v WHERE v.sid = 61;

观察会话中的数据库读取情况，CONSISTENT_GETS 值在持续增长。结合上面SQL*Net的情况，大致可以判断出该程序在反复执行某个查询语句，每次获取的数据量很小但频率很高。我们知道，客户端在读取数据时，可能影响的因素有Array Fetch Size、SQL*Net中的SDU和数据库服务器每次读取的数据量，简单计算SQL*Net每次传输大致的数据量后将问题定位到SQL的性能问题上。

开始跟踪Planning Manager的全过程。Planning Manager 是一种特殊的并发程序(Immediate)，它直接依附于并发管理器MRP Manager执行。但是作为并发请求，它的常规诊断方式是一样的。如果有计划管理器在运行，则先停掉它，然后启用Trace：

关于详细操作和Trace文件的查找可参考另一篇文章《跟踪(Trace)并发请求》

进入MRP计划管理员设置界面，启动Planning Manager。对于其他独立的并发请求，可以直接手工提交。等待Planning Manager处理完预先准备的接口数据后，立即取消该请求，并取消Trace。

接下来就是对Trace文件的解读。对于并发请求的Trace，其实就是对应的一次10046事件(event)，该事件可简单分为以下四个级别：

Level 1: 跟踪SQL
Level 4: Level 1 + 跟踪绑定变量
Level 8: Level 1 + 跟踪等待事件
Level 12: Level 4 + Level 8 (跟踪SQL, 绑定变量和等待事件)

手工方式的话可通过下面的命令启用：

alter session set events='10046 trace name context forever, level 8' ;

它和下面的命令类似：

ALTER SESSION SET SQL_TRACE = TRUE

只是前一个命令，可以根据需要指定不同的level，比如此处的level 8，表示跟踪到SQL和等待事件，而不获取绑定变量的数据。也可以通过包DBMS_System来启用，例如：

EXEC DBMS_System.Set_Sql_Trace_In_Session(sid, serial#, true );
EXEC DBMS_System.Set_Ev(sid, serial#, event, level, name);

在某些场合下，针对并发请求的跟踪可能会产生不止一个Trace文件，此时第一个Trace文件中会指明第二个Trace文件标识，如：

PARSE #41:c=0,e=565,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,tim=19728618248238
EXEC #41:c=0,e=781,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=19728618249248
=====================
PARSING IN CURSOR #41 len=54 dep=1 uid=44 oct=42 lid=44 tim=19728618250006 hv=4121095646 ad='f7b931f8'
ALTER SESSION SET TRACEFILE_IDENTIFIER='XZB_CR8909488'
END OF STMT
PARSE #41:c=0,e=249,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,tim=19728618250001

*** TRACE DUMP CONTINUES IN FILE
……/udump/test_ora_14443_XZB_CR8909488.trc ***

先来大致看一下Trace文件中都有些什么。

Dump file ……/udump/test_ora_14443.trc
Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.6.0 - Production
ORACLE_HOME = /u08/test/proddb/9.2.0
System name:	SunOS
Node name:	erptest
Release:	5.10
Version:	Generic_118833-03
Machine:	sun4u
Instance name: TEST
Redo thread mounted by this instance: 1
Oracle process number: 59
Unix process pid: 14443, image: oracle@erptest (TNS V1-V3)

这是文件头，显示了相关环境信息。接着往下翻，关键在具体某条SQL的执行情况上，如下：

=====================
PARSING IN CURSOR #75 len=332 dep=0 uid=44 oct=3 lid=44 tim=19728619902280 hv=3581312695 ad='f2b4eb00'
select count(*)  into :b0  from wip_requirement_operations wro ,mtl_system_items items
where ((((((wro.inventory_item_id=items.inventory_item_id and wro.organization_id=items.organization_id) and items.bom_item_type=4)
and wro.wip_entity_id=:b1) and wro.wip_supply_type=6)
and wro.organization_id=:b2) and wro.inventory_item_id=:b3)
END OF STMT
PARSE #75:c=10000,e=2221,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=0,tim=19728619902273
EXEC #75:c=0,e=2841,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=19728619905363
WAIT #75: nam='db file sequential read' ela= 6392 p1=66 p2=135783 p3=1
……
FETCH #74:c=0,e=1248,p=0,cr=36,cu=0,mis=0,r=0,dep=0,og=4,tim=19728777309437
WAIT #74: nam='SQL*Net message to client' ela= 6 p1=1952673792 p2=1 p3=0
WAIT #74: nam='SQL*Net message from client' ela= 338 p1=1952673792 p2=1 p3=0
EXEC #74:c=0,e=256,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=19728777310344
WAIT #74: nam='SQL*Net message to client' ela= 1 p1=1952673792 p2=1 p3=0
WAIT #74: nam='SQL*Net message from client' ela= 205 p1=1952673792 p2=1 p3=0
EXEC #75:c=0,e=110,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=19728777310795
WAIT #75: nam='SQL*Net message to client' ela= 2 p1=1952673792 p2=1 p3=0
FETCH #75:c=30000,e=26138,p=0,cr=2028,cu=0,mis=0,r=1,dep=0,og=4,tim=19728777336976
WAIT #75: nam='SQL*Net message from client' ela= 278 p1=1952673792 p2=1 p3=0
FETCH #74:c=0,e=749,p=0,cr=36,cu=0,mis=0,r=0,dep=0,og=4,tim=19728777338168
WAIT #74: nam='SQL*Net message to client' ela= 2 p1=1952673792 p2=1 p3=0
WAIT #74: nam='SQL*Net message from client' ela= 304 p1=1952673792 p2=1 p3=0
EXEC #74:c=0,e=112,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=19728777338769
WAIT #74: nam='SQL*Net message to client' ela= 1 p1=1952673792 p2=1 p3=0
WAIT #74: nam='SQL*Net message from client' ela= 227 p1=1952673792 p2=1 p3=0
EXEC #75:c=0,e=272,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=19728777339533
WAIT #75: nam='SQL*Net message to client' ela= 7 p1=1952673792 p2=1 p3=0
FETCH #75:c=30000,e=27212,p=0,cr=2028,cu=0,mis=0,r=1,dep=0,og=4,tim=19728777366810
WAIT #75: nam='SQL*Net message from client' ela= 415 p1=1952673792 p2=1 p3=0
……

这里显示了cursor语句的执行情况，发现编号为#74和#75的语句执行次数非常多，并且间隔执行，每次execute速度很快，fetch消耗时间相对较多，每次读取后立即发送给客户端。（格式的解读参考附注）

由于无法查看源代码，也没有任何技术文档，所以这里，大胆猜测这两个语句在一个LOOP中执行的可能性非常大。Tkprof格式化后，迅速定位最耗时的那个步骤：

select count(*)  into :b0
from
 wip_requirement_operations wro ,mtl_system_items items where
  ((((((wro.inventory_item_id=items.inventory_item_id and wro.organization_id=
  items.organization_id) and items.bom_item_type=4) and wro.wip_entity_id=:b1)
   and wro.wip_supply_type=6) and wro.organization_id=:b2) and
  wro.inventory_item_id=:b3)

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.01       0.00          0          0          0           0
Execute   8890      0.89       0.92          0          0          0           0
Fetch     8890    223.66     231.45       1951   18028921          0        8890
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total    17781    224.56     232.37       1951   18028921          0        8890

Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 44  

Rows     Row Source Operation
-------  ---------------------------------------------------
   8890  SORT AGGREGATE
      0   NESTED LOOPS
   8890    TABLE ACCESS BY INDEX ROWID MTL_SYSTEM_ITEMS_B
   8890     INDEX UNIQUE SCAN MTL_SYSTEM_ITEMS_B_U1 (object id 18977994)
      0    TABLE ACCESS BY INDEX ROWID WIP_REQUIREMENT_OPERATIONS
61341000     INDEX RANGE SCAN WIP_REQUIREMENT_OPERATIONS_N1 (object id 18977444)

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  db file sequential read                      1951        0.08         11.65
  SQL*Net message to client                    8891        0.00          0.03
  SQL*Net message from client                  8891        0.01          2.82
  latch free                                     19        0.01          0.12

到这里终于确定了主要问题所在，下一步就是对该语句进行优化。由于无法修改代码，因此只能从执行计划角度考虑。检查该语句的执行计划，仔细检查发现虽然利用了索引WIP_REQUIREMENT_OPERATIONS_N1，看上去很漂亮，但是仔细检查索引字段发现这是个组合索引，若走这个索引或导致大量的逻辑块读。到此，整个诊断过程也顺利结束了。

附Trace格式解读：

PARSING IN CURSOR
len	Length of SQL statement.
dep	Recursive depth of the cursor.
uid	Schema user id of parsing user.
oct	Oracle command type.
lid	Privilege user id.
ela	Elapsed time. 8i: in 1/1000th of a second, 9i: 1/1'000'000th of a second
tim	Timestamp.
hv	Hash id.
ad	SQLTEXT address (see?v$sqlarea?and?v$sqltext).

PARSE, EXEC or FETCH
#n	n = number of cursor
c	cpu time
e	elapsed time
p	physical reads
cr	consistant reads
cu	current mode reads
mis	miss in cache
r	rows processed
dep	recursive depth
og	optimizer goal
tim	time

详见 http://www.adp-gmbh.ch/ora/misc/trace_file_format.html

有用的链接：

Update
2010-05-27 其实是可以看到源代码的，下一篇文章会详细阐述。