tbwshc

discover_server报错OVMAPI_4010E

posted @ 2012-09-03 17:12 chen11-1| 编辑 收藏

Oracle VM Server安装手册

简单描述一下Oracle VM Server的安装过程。

需要注意，VM 3.0以上版本才支持升级操作，因此在VM 2.2没有办法升级到当前版本，安装VM 3.0将会删除服务器上所有的数据。

将VM Server的光盘放入，并从光盘启动服务器。

在启动界面直输入Enter开始安装过程：

Oracle会提示是否监测截至，这里可以直接SKIP跳过；

键盘选择：选择us；

然后是版权声明，选择Accept后，开始正式的安装步骤；

如果服务器上没有系统，那么会直接进入后面的分区阶段，否则会提示重装系统还是在原有系统上升级；

选择ReInstall后，会显示当前系统磁盘分区信息，首先选择准备进行系统安装的分区，然后选择Remove tb all partitions and create a new default partition layout，Oracle在格式化分区之前会要求再次确认，并询问是否预览分区空间详细配置，可以完全按照默认推荐值安装，因此这里可以跳过，也可以进入到分区空间修改页面进行自定义的修改；

随后选择Boot Loader配置，选择Master Boot Record；

然后选择一个管理网络接口，手工输入IP和掩码，在下一个页面输入网关、DNS信息，接着是主机名信息；

配置服务器所在时区，配置中找不到北京，可以设置Asia/Shanghai代替；

分别输入Agent密码和root密码后，安装操作完成，这是会提示整个安装的日志文件的位置。

在重启界面选择REBOOT，完成整个安装过程。

启动后，进入Oracle VM Server 3.0控制台界面，可以通过Alt + F2进入linux的登录界面。至此VM Server安装完成。

posted @ 2012-09-03 17:10 chen11-1| 编辑 收藏

ORA-600(qersqCloseRem-2)错误

posted @ 2012-09-03 17:09 chen11-1 阅读(904) | 评论 (0) | 编辑 收藏

Oracle 11g R2的四个新增小特性总结

基于版本的重定义

Oracle 11g R2增加了一个强大的新工具，它可以检出应用程序数据库对象的任一版本，不是所有数据库对象都支持版本化管理，但私有的同义词，视图和几乎所有的PL/SQL对象，包括存储过程、函数、类型、类型主体、包、包主体和触发器，版本化管理的真正好处是简化了部署一个修改版本的应用程序代码到生产数据库，如果部署时遇到一系列的错误，可以很容易地将所有影响的对象回滚到上一个版本。

消除了闪回数据归档上的DDL限制

在前一篇文章中，我深入研究了Oracle 11g R1的新特性“闪回数据归档（Flashback Data Archive，FBDA）”，它也被称为“全部召回（Total Recall）”，它只捕获变化的数据，将这些数据放在一套特殊的对象中，它们构成了FBDA，当用户通过闪回版本查询（Flashback Versions query）查询表的历史记录时，Oracle将会直接从数据库的UNDO表空间返回最近变化的数据，从FBDA返回更旧的数据。

虽然这个特性很好，但在早期版本中也有很多限制，包括增加、修改、重命名、删除表的列、truncate表、修改表的约束、以及修改分区表的分区规范，在Oracle 11g R2中，这些限制全部没有了，对于更复杂的DDL操作，如使用DBMS_REDEFINITION包重定义已经存储到FBDA的基础表，Oracle 11g R2提供了新的DBMS_FLASHBACK_ARCHIVE包，存储过程DISASSOCIATE_FBA将会把基础表从FBDA中分离出来，一旦请求的改变完成，存储过程REASSOCIATE_FBA会被用来重新关联修改的表和基础表。

按需创建分段

在之前的版本中，使用CREATE TABLE语句创建表时，会同时自动创建表的初始段，从Oracle 11gR2开始，这个默认的行为有所变化，创建表时不会创建初始段，直到有数据插入到这个表。此外，任何依赖于该表的索引或LOB段也不会创建，直到有数据插入才会创建，表的SEGMENT CREATION DEFERRED存储属性指定了这个默认行为，但可以使用SEGMENT CREATION IMMEDIATE属性覆盖它。

不可用索引大小归零

在重新载入大表时，比如一个有上百万行的数据仓库事实表，要提高这种表的加载速度，最简单的办法是将该表上的所有索引置为不可用，在数据加载完毕后，在重建这些索引，Oracle 11g R2认可了这一做法，并采取了实质性的措施，tb当索引被标记为不可用时，它会自动删除所有索引段。

小结

Oracle 11g R2延续了自Oracle 10g以来令人称道的自我管理，自我调整，自我治愈的特性，这个新版本提供了太多的新特性，有些是迟来的功能，有些是革新，Oracle DBA可以借助这些新特性提高工作效率，成为一名真正的“信息工程师”。

posted @ 2012-08-31 08:10 chen11-1 阅读(284) | 评论 (0) | 编辑 收藏

Oracle 11g R2令人赞赏的五大新特性

2009年9月Oracle公司发布了期待已久的Oracle 11g R2，本系列文章将给读者一一揭开新版本中的新特性，并会介绍企业如何利用这些新特性将现有的Oracle 9i，10g，11g R1升级到Oracle 11g R2.

经历了难以忍受的长时间等待，Oracle公司突然在9月1发布了Oracle 11g R2，我不得不承认Oracle的保密工作做得多么好，我相信Oracle公司选择这个时候发布时为了刺激参加Oracle OpenWorld 2009大会的人兴奋和期待。

经过四处搜索Oracle 11g R2新特性文档，并体验了新的OUI(Oracle通用安装程序)，创建了我的第一个单实例RAC后，我总结一下Oracle 11g R2中我最喜欢的五大新特性。在后面的文章中我将陆续介绍其它新特性，请锁定本系列文章。

NO.1 随处可见的集群

在以前的版本中，Oracle Clusterware必须要独立地安装在它自己的ORACLE HOME中，并且也只能在RAC环境下使用，这一切在Oracle 11g R2得到彻底颠覆，因为在这个版本中支持安装Oracle网格基础架构，而且只需要一个独立的ORACLE HOME，它包括了Oracle Clusterware和Oracle自动存储管理(ASM)。通过升级后的Oracle通用安装程序安装了网格基础架构后，你将会看到一个全新的功能和服务矩阵，我简单地列举几个吧：

单实例RAC(Oracle重启)：听起来似乎自相矛盾，但Oracle 11g R2扩展了Oracle Clusterware的功能，为任何单实例提供了高可用特性，本质上是将数据库变成了单实例RAC数据库。Oracle 11g R2中的Oracle重启特性帮助Oracle网格基础架构的高可用服务控制服务器重启时哪一个监听器，ASM实例和数据库应该启动，它完全取代了过去DBA们经常用到的DBSTART脚本。同样，当单个数据库实例崩溃或其它异常终止时，Oracle重启功能会自动监测失效的实例，并自动重启它，就好像是在一个真实的RAC环境中一样。

SRVCTL升级：如果你管理过旧版本的RAC环境，你可能已经熟悉了RAC环境中的维护工具SRVCTL，在11g R2中，该工具被扩展了，现在可以管理单实例RAC，以及监听器和ASM实例。

集群时间同步服务：Oracle 11g R2现在需要在所有RAC节点上配置时间同步，如果你曾经经历过某个节点被驱逐出RAC集群配置，你一定知道其难度有多大，特别是两个服务器的时间不同步和日志文件的时间戳不同步时，Oracle之前的版本借助系统提供的网络时间协议(NTP)同步所有节点时间，但这需要连接到互联网上的标准时间服务器，作为NTP的替代者，Oracle 11g R2提供了一个新的集群时间同步服务，确保集群中的所有节点的时间都保持一致。

网格即插即用：在以前的版本中，配置RAC最复杂的部分是确定和设置所有节点都需要用到的公共ip地址，私有ip地址和虚拟ip地址。为了简化RAC的安装，Oracle 11g R2提供了一个全新的网格名称服务(GNS)，它和域名服务器协作，处理每个网格组件的ip地址分配，当集群环境跨越多个数据库时这个新特性极其有用。

干净地卸载RAC组件：如果你曾经尝试过删除多个节点上的所有RAC痕迹，那一定会钟情于这项新特性，在Oracle 11g R2中，所有安装和配置助手，特别是Oracle通用安装程序(OUI)，数据库配置助手(DBCA)和网络配置助手(NETCA)，都得到了增强，当需要卸载RAC组件时，可以保证卸得干干净净。

NO.2 ASM加入了集群

Oracle 11g R2 ASM充满了许多吸引人的新特性，对于初学者来说，ASM和Oracle 11g R2 Clusterware安装在同一个Oracle Home下，因此消除了之前推荐的冗余Oracle Home安装方法，并且ASM也从DBCA脱离出来了，有了专门的自动存储管理配置助手(ASMCA)。下面是我认为最有趣的ASM新特性：

智能化数据布局：在之前的版本中，要配置ASM磁盘可能需要存储管理员的参与，需要配置磁盘I/O子系统，Oracle 11g R2提供了ASM分配单元，可以直接受益于磁盘外缘柱面，获得更快的速度，可以将数据文件，重做日志文件和控制放在磁盘外缘获得更好的性能。

EM支持工作台扩展：在这个版本中对Oracle 11g R1引入到企业管理控制台中的自动诊断仓库(ADR)进行了扩展，包括支持ASM诊断，将所有诊断信息打包直接发送给Oracle技术支持，以便获得更快速的ASM性能问题解决方案。

ASMCMD增强：自动存储管理命令行实用工具(ASMCMD)也获得了不少增强，包括：

1)启动和停止ASM实例;

2)备份，恢复和维护ASM实例的服务器参数文件(spfile);

3)实用iostat监控ASM磁盘组的性能;

4)维护新的ASM集群文件系统(ACFS)中的磁盘卷，目录和文件存储，我的下一个话题就是它。

NO.3 ACFS – 一个强健的集群文件系统

Oracle之前也发布过集群文件系统(OCFS)，之后又发布了增强版OCFS2，它让Oracle RAC实例可以通过共享存储读写数据库文件，重做日志文件和控制文件。

此外，OCFS也允许RAC数据库的Oracle集群注册文件(OCR)和表决磁盘存储在集群文件系统中，在Oracle 10g R2中，这个需求被取消了，OCR文件和表决磁盘可以存储在裸设备或裸块设备中，如果你曾经在原始设备上丢失过这些文件的所有副本，你一定了解要恢复它们是多么繁琐，因此，在Oracle 11g R2中，将不再支持将这些文件存储在裸设备上。

为了提高这些关键文件的存活能力，Oracle 11g R2正式引入了一种新的集群文件系统，称之为ASM集群文件系统(ACFS)，在RAC环境中，ACFS可以为OCR文件和表决磁盘提供更好的保护，它允许创建五份OCR文件副本，tb之前的集群文件系统仅允许保存两份OCR文件，一个主OCR，一个镜像OCR，但ACFS不适合单独的RAC环境，除此之外，几乎所有与操作系统和数据相关的文件都可以从ACFS的安全性和文件共享特性受益。

动态卷管理器：Oracle 11g R2提供了一个新的ASM动态卷管理器(ADVM)来配置和维护存储在ACFS文件系统中的文件，使用ADVM可以在ASM磁盘组内构建一个ADVM卷设备，管理存储在ADVM卷设备中的文件，以及按需调整ADVM卷设备空间大小，最重要的是，因为ADVM是构建在ASM文件系统架构之上的，可以保证存储在这些卷中的文件受到良好的保护，不会出现意外丢失，因为ASM提供了类似RAID的磁盘阵列的功能。

文件访问控制：使用传统的Windows风格访问控制列表(ACL)或Unix/Linux下的用户/组/其它访问权限风格为ACFS目录和文件授予读，写和执行权限，可以通过图形化的企业管理控制台或命令行程序ASMCMD管理ACFS目录和文件安全。

文件系统快照(FSS)：Oracle 11g R2通过它的文件系统快照(FSS)功能可以对ACFS文件系统执行快照，一个快照是所选ACFS文件系统的一个只读副本，对相同的ACFS，它会自动保留63个独立的ACFS快照，当某个ACFS文件被不经意地更新，删除或其它危险操作时，这个特性非常有用，利用11g R2企业管理控制台或ACFS acfsutil命令行工具可以找出该文件合适的版本并执行恢复。

NO.4 改善的软件安装和打补丁过程

我发现作为一名DBA压力最大的活就是给Oracle数据库打补丁了，如果补丁可能会引入对数据库有害的行为，我不得不花费大量的时间和精力来确定和审核，因此我对Oracle 11g R2中提供的新功能感到很欢喜。

集群验证实用程序集成：从Oracle 10g开始引入了集群验证实用程序(CVU)，现在已经完全集成到Oracle通用安装程序(OUI)和其它配置助手(如DBCA，DBUA)中了。

零停机修补的集群：当为Oracle集群打补丁时，Oracle 11g R2在一个不合适的位置升级方式应用补丁，这意味着会有两个Oracle Home，其中一个专门用来存放补丁的，但一次只能激活一个Oracle Home，在Oracle 11g R2中不用再为升级全部关闭Oracle集群了，实现真正的零停机打补丁。

NO.5 DBMS_SCHEDULER升级

古老的DBMS_SCHEDULER包得到了彻底的更新，DBA经常使用这个包来调度作业。

文件监视器：以前的版本无法在批处理过程中检测大多数触发事件，如检测一个文件抵达某个目录，在Oracle 11g R2中，使用新的文件监视器可以缓解这个问题，一旦预期的文件抵达目录，DBMS_SCHEDULER现在就可以检测到了，并在新的对象类型SCHEDULER_FILEWATCHER_RESULT中注册它的到来，它通过新的CREATE_FILE_WATCHER存储过程向DBMS_SCHEDULER发送一个信号触发作业。

内置的email通知：无论何时，DBMS_SCHEDULER调度任务启动、失败或完成时，任务的状态可以立即通过email发送出去，虽然在以前的版本中也能实现这个功能，但要么调用DBMS_MAIL存储过程，要么调用DBMS_SMTP存储过程，现在这个功能合并到DBMS_SCHEDULER中了。

远程作业：DBMS_SCHEDULER现在允许DBA在远程数据库上创建和调度作业，现在我终于可以在生产库PROD03上通过DBMS_SCHEDULER调用生产库DBMS_SCHEDULER上的存储过程执行任务了，这意味着我现在可以在一台数据库上集中tb创建和维护调度任务了。

多作业目标：最后，现在可以在多个数据库实例上同时调度DBMS_SCHEDULER任务了，在RAC环境中，这个特性非常有用，因为我可以利用多个数据库实例将长时间运行任务分成几部分，分别在不同的数据库实例上执行更小的任务。

posted @ 2012-08-31 08:09 chen11-1| 编辑 收藏

详解DB2中自定义XML存储及其使用环境

为了形象地说明，我将使用一个XML文档，内容如下：

<order OrderID="9001" OrderDate="2009-10-18">> 
 <customerID>26914</customerID> 
 <item id="LK-486"> 
  <name>Magictb Potion</name> 
  <size>300ml</size> 
  <price>19.99</price> 
 </item> 
 <item id="VF-145"> 
  <name>Crystal Ball, Deluxe</name> 
  <color>crystal clear</color> 
  <price>295.00</price> 
 </item> 
</order> 

它展示了一个包括订单ID，日期，客户ID和其它条目的订单XML文档，注意有些条目的描述方式有所不同，如size和color。我们假设需要在DB2中管理许多与此类似的XML文档。

如何拆分和重组XML

我在另一篇文章“15个DB2 pureXML性能最佳实践”中谈到了你应该明智地选择文档的粒度，实际上就是要将存储在DB2中的XML文档与应用程序的业务逻辑对象和主要的访问粒度匹配。

在我们的例子中，假设订单变化非常频繁，订单内的条目读取，添加或删除是最关键的操作，需要最佳的性能，在这种情况下，你可以考虑将订单文档拆分，将每一个条目作为一个独立的文档存储到DB2表的每一行中，这个存储方法（与原来的完整存储订单文档的方法相比）的好处是它使得操作所存储的数据更容易，更快速：

可以使用单行读取检索一个条目，不用从一个完整的订单文档中抽取条目了；

可以通过删除表中的行简单地从订单中删除一个条目，不再需要操作完整的订单文档；

可以迅速插入一个新条目到订单中，这时也不需要操作完整的订单文档。

这种轻松添加和移除订单条目的功能在DB2 9 for z/OS中尤其有价值，因为这个版本不支持在现有XML文档中添加或删除元素。
下面的代码显示了一个表的定义，以及拆分一个订单文档的INSERT语句，相关的列分别存储订单ID，客户ID，订单日期和一个条目流水号。

CREATE TABLE items(ordID INTEGER, custID INTEGER,  
                                   odate DATE, seqNo INTEGER, item XML);  
INSERT INTO items(ordID, custID, odate, seqno, item)  
 SELECT T.ordID, T.custID, T.odate, T.seqno, XMLDOCUMENT( T.item)  
 FROM 
  XMLTABLE('$d/order/item' PASSING cast(? AS XML) "d" 
   COLUMNS  
    ordID        INTEGER    PATH      '../@OrderID',  
    custID       INTEGER    PATH      '../customerID' 
    odate        DATE       PATH      '../@OrderDate',  
    seqNo        FOR ORDINALITY,  
    item         XML        PATH      '.') AS T; 

条目信息是以XML格式存储的，因为条目可能有不同的元素和属性，如：

ORDID     CUSTID     ODATE     SEQNO     ITEM  
-----     -----     ------     -----     -----  
9001     26914     10/18/2009     1   <item id="LK-486">  
                                        <name>Magic Potion</name>  
                                        <size>300ml</size>  
                                        <price>19.99</price>  
                                      </item>  
9001     26914     10/18/2009     2   <item id="VF-145">  
                                        <name>Crystal Ball, Deluxe</name>  
                                        <color>crystaltb clear</color>  
                                        <price>295.00</price>  
                                      </item>  
2 record(s) selected. 

INSERT语句包括一个XMLTABLE函数，这个函数从输入XML文档抽取插入items表中的值，它将会拆分输入XML文档，生成独立条目的文档。XMLTABLE函数包括一个参数，通过它，应用程序可以传递一个订单文档，使用XPath表达式$d/order/item，XMLTABLE函数为输入文档的每一个条目生成一行数据，然后抽取订单ID，客户ID和订单日期，特殊的列定义FOR ORDINALITY为产生的每一行打上编号。XMLDOCUMENT函数确保每一个条目片段可以作为一个独立的XML文档插入。

上面的代码显示了使用INSERT语句插入XML文档后items表中的数据，下面的代码显示了如何重建原始的订单文档，XMLELEMENT和XMLATTRIBUTES函数使用items表中相关列的值构建的顶部文档，XMLAGG函数组合所有条目，最后形成一个完整的订单文档。注意，XMLAGG在seqno列上包括一个可选的ORDER BY子句，这样可以确保还原后的订单文档和原始文档中的条目显示顺序是一致的。

SELECT XMLELEMENT(name "order",  
         XMLATTRIBUTES(ordID AS "OrderID", odate as "OrderDate"),  
         XMLELEMENT(name "customerID", custID)  
         XMLAGG(item ORDER BY seqno) )  
FROM items  
WHERE ordID = 9001  
GROUP BY ordID, odate, custID; 

使用生成列

DB2 9.7 for LUW中新的IBM DB2 pureXML特性允许你与数据库分区功能（Database Partitioning Feature，DPF），范围分区表和多维集群（MDC）表一起使用XML列，但分区或集群键必须由相关的列组成。前面你已经看到了如何使用INSERT和XMLTABLE从XML文档抽取值到相关的列中，你可以使用这些关联列对表进行分区或集群。如果你更喜欢在程序中使用简单的INSERT语句，并且不知道如何抽取数据时，那你可以考虑使用一个生成的列。

DB2 9.7在用户定义函数（UDF）中支持XML参数，允许你定义生成的列，使用插入的XML文档中的值自动填充。下面的代码显示了一个UDF，它接受一个XML文档作为输入，如前面例子中的订单文档，这个UDF使用XMLCAST和XMLQUERY函数抽取输入文档的OrderDate属性：

CREATE FUNCTION extractDate(doc XML)  
  RETURNS DATE 
  LANGUAGE SQL CONTAINS SQL  
  NO EXTERNAL ACTION DETERMINISTIC  
  RETURN XMLCAST(XMLQUERY('$d/order/@OrderDate' 
         PASSING doc AS "d") AS DATE); 

你可以在SELECT查询和其它SQL语句中使用这个UDF，但也要定义一个生成列，对于下面的示例，假设检索和插入完整的订单是最关键的操作，在这种情况下，完整地存储订单文档是最好的选择。下面的代码定义了一个使用XML列存储订单的表，并自动抽取订单日期填充到关联的列（odate）中。一条INSERT语句现在可以简单地插入一个XML文档到order列中，不需要考虑抽取值到关联列中：

CREATE TABLE orders(  
  order XML,  
  odate DATE GENERATED ALWAYS AS (extractDate(order))); 

如果你连续不断地存储许多订单，可能需要对旧订单进行归档，这个时候使用范围分区是最好的选择，下面的代码显示了表order2是通过按odate列的值进行分区的，odate列则产生自XML列，同样，你可以使用生成的列作为分区数据库的分配键，也可以作为MDC表的集群键：

CREATE TABLE order2(  
  order XML,  
  odate DATE GENERATED ALWAYS AS (extractDate(order)) NOT NULL)  
 PARTITION BY RANGE (odate)  
 (PART q109 STARTING('01-01-2009') ENDING ('03-31-2009') INCLUSIVE,  
 PART q209 ENDING ('06-30-2009') INCLUSIVE,  
 PART q309 ENDING ('09-30-2009') INCLUSIVE,  
 PART q409 ENDING ('12-31-2009') INCLUSIVE); 

控制XML存储

自定义XML存储有许多好处，将大型XML文档拆分成多个小文档，将会使操作XML数据变得更加容易和高效，使用UDF定义生成列可以简化XML值抽取到关联列，使用生成列还可以帮助你管理分区数据库，范围分区表，或MDC表中的XML。

原文出处：http://www.ibm.com/developerworks/data/library/dmmag/DMMag_2009_Issue3/Tips/index.html

原文名：Customizing XML storage in DB2

作者：Matthias Nicola

posted @ 2012-08-31 08:08 chen11-1 阅读(1859) | 评论 (0) | 编辑 收藏

ORA-1595和ORA-1594错误

posted @ 2012-08-30 13:10 chen11-1 阅读(874) | 评论 (0) | 编辑 收藏

ORA-600(1265)错误

客户的数据库出现ORA-600错误，错误函数为1265。

数据库版本为10.2.0.4 for Linux，错误信息为：

Fri Aug 26 22:00:11 2011
Errors in file /opt/app/oracle/admin/orcl/udump/orcl1_ora_16655.trc:
ORA-00600: internal error code, arguments: [1265], [0x42180EA78], [], [], [], [], [], []
Fri Aug 26 22:00:13 2011
Errors in file /opt/app/oracletb/admin/orcl/udump/orcl1_ora_16655.trc:
ORA-00600: internal error code, arguments: [1265], [0x42180EA78], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [1265], [0x42180EA78], [], [], [], [], [], []
Fri Aug 26 22:00:13 2011
Trace dumping is performing id=[cdmp_20110826220013]
Fri Aug 26 22:00:14 2011
Errors in file /opt/app/oracle/admin/orcl/udump/orcl1_ora_16655.trc:
ORA-00600: internal error code, arguments: [1265], [0x42180EA78], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [1265], [0x42180EA78], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [1265], [0x42180EA78], [], [], [], [], [], []
ORA-06512: at "USER1.P_PRO", line 5
ORA-04088: error during execution of trigger 'USER1.P_PRO'
Fri Aug 26 22:00:15 2011
Errors in file /opt/app/oracle/admin/orcl/udump/orcl1_ora_16655.trc:
ORA-00600: internal error code, arguments: [1265], [0x42180EA78], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [1265], [0x42180EA78], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [1265], [0x42180EA78], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [1265], [0x42180EA78], [], [], [], [], [], []
ORA-06512: at "USER1.P_PRO ", line 5
ORA-04088: error during execution of trigger 'USER1.P_PRO'
ORA-06512: at "USER1.U_PRO ", line 25
Fri Aug 26 22:00:17 2011
Errors in file /opt/app/oracle/admin/orcl/udump/orcl1_ora_16655.trc:
ORA-00600: internal error code, arguments: [1265], [0x42180EA78], [], [], [], [], [], []
ORA-02067: transaction or savepoint rollback required
Fri Aug 26 22:00:18 2011
Errors in file /opt/app/oracle/admin/orcl/udump/orcl1_ora_16655.trc:
ORA-00600: internal error code, arguments: [17281], [600], [0x2E134EEC0], [], [], [], [], []
ORA-00600: internal error code, arguments: [1265], [0x42180EA78], [], [], [], [], [], []
ORA-02067: transaction or savepoint rollback required

这个错误是ORA-600[1265]错误引发的，随后还出现了ORA-600[17281]、ORA-4088和ORA-2067错误。其中ORA-2067的描述为：

$ oerr ora 2067
02067, 00000, "transaction or savepoint rollback required"
// *Cause: A failure (typically a trigger or stored procedure with multiple
// remote updates) occurred such that the all-or-nothing execution
// of a previous Oracle call cannot be guaranteed.
// *Action: rollback to a previous savepoint or rollback the transaction
// and resubmit.

从这个描述和Oracle的报错信息不难判断，Oracle在通过触发器更新远端表时引发了这个600错误。

根据Oracle的MOS文档Bug 5655419 Distributed transaction hits ORA-600:[1265] or ORA-600:[k2gget: downgrade] in 10.2的描述，这个错误和分布式事务有关，确认影响的版本就是当前环境的10.2.0.4。这个错误的产生一般与窗口维护有关，可以看到问题的发生时刻恰好是22点，从这个时刻开始，Oracle进入维护窗口，进行空间回收统计信息收集等后台工作，显然就是因为窗口的变化导致了这个错误的产生。

Oracle在11.1.0.6中FIXED了这个bug。除了版本升级外，可以考虑将包含分布式事务修改的程序放到远离时间窗口改变时间。

posted @ 2012-08-30 13:09 chen11-1 阅读(1344) | 评论 (0) | 编辑 收藏

ORA-600(kccida_kccsgfsz)错误

posted @ 2012-08-30 13:08 chen11-1 阅读(219) | 评论 (0) | 编辑 收藏

分区表UNUSED列后的EXCHANGE PARTITION操作

碰到一个有意思的问题，如果分区表执行过SET UNUSED操作，那么是否还可以进行分区的EXCHANGE操作。

一个简单的测试就可以说明这个问题：

SQL> create table t_part_unused
 2 (id number, name varchar2(30), other varchar2(30))
 3 partition by range (id)
 4 (partition p1 values less than (10),
 5 partition pmax values less than (maxvalue));

Table created.

SQL> insert into t_part_unused
 2 select rownum, table_name, 'abc'
 3 from user_tables;

48 rows created.

SQL> commit;

Commit complete.

SQL> alter table t_part_unused set unused (other);

Table altered.

SQL> desc t_part_unused
 Name                                    Null?   Type
 ---------------------------------------- -------- ------------------------
 ID                                               NUMBER
 NAME                                             VARCHAR2(30)

SQL> create table t_temp_unused as
 2 select *
 3 from t_part_unused
 4 where 1 = 2;

Table created.

SQL> desc t_temp_unused
 Name                                    Null?   Type
 ---------------------------------------- -------- ------------------------
 ID                                               NUMBER
 NAME                                             VARCHAR2(30)

SQL> alter table t_part_unused
 2 exchange partition p1
 3 with table t_temp_unused;
with table t_temp_unused
          *
ERROR at line 3:
ORA-14097: column type or size mismatch in ALTER tb TABLE EXCHANGE PARTITION

SQL> alter table t_temp_unused add (other varchar2(30));

Table altered.

SQL> alter table t_part_unused
 2 exchange partition p1
 3 with table t_temp_unused;
with table t_temp_unused
          *
ERROR at line 3:
ORA-14096: tables in ALTER TABLE EXCHANGE PARTITION must have the same number of columns

SQL> alter table t_temp_unused set unused (other);

Table altered.

SQL> alter table t_part_unused
 2 exchange partition p1
 3 with table t_temp_unused;

Table altered.

很明显执行了SET UNUSED操作后的表，和普通的表是存在区别的，这种区别导致要求进行EXCHANGE的表必须同样执行SET UNUSED操作，否则就无法执行EXCHANGE的操作。

当目标表中不包含SETE UNUSED的列时，EXCHANGE操作会出现ORA-14097的错误，而如果把列添加到目标表，则会报错ORA-14096，必须在目标表同样对列执行SET UNUSED操作，才能通过EXCHANGE之前的检查。

其实这也不难理解，执行SET UNUSED命令后，数据字典虽然发生了改变，但是tb表上的数据并没有删除，而EXCHANGE操作只是将两个段的数据字典进行互换，因此如果目标表上缺少SET UNUSED列，是无法执行EXCHANGE操作的。

解决问题的方法有两个，第一个就是例子中展示的可以在目标表上建立列然后同样的执行SET UNUSED操作；另外的一个方法就是对于SET UNUSED列执行DROP COLUMN操作，彻底删除该列。

posted @ 2012-08-30 13:07 chen11-1 阅读(822) | 评论 (0) | 编辑 收藏