ITPub博客

ORA-00600: internal error code, arguments: [pfri.c: pfri8: plio mismatch ]错误[@more@]ORA-00600: internal error code, arguments: [pfri.c: pfri8: plio mismatch ]错误警告文件出现错误：Mon Sep 8 17:05:21 2008Errors in file ********life1_ora_557772.trc:ORA-00600: internal error code, arguments: [pfri.c: pfri8: plio mismatch ], [], [], [], [], [], [], []ORA-04061: existing state of package body "********" has been invalidatedORA-04065: not executed, altered or dropped package body "**

ORA-06512错误的一个原因[@more@]ORA-06512错误的一个原因在alert文件中出现错误信息Wed Sep 3 18:18:43 2008Errors in file ********_ora_627008.trc:ORA-03113: end-of-file on communication channelORA-03113: end-of-file on communication channelORA-06512: at "********.********E_PS_PUBLIC_LOG", line 557ORA-06512: at "********.********E_PS_PUBLIC_LOG", line 916ORA-06512: at "********.********E_PS_PUBLIC_LOG", line 975ORA-06512: at "********.********E_PS_CONFIRM_PS_INCOME&

ORA-1461 encountered when generating server alert SMG-3500[@more@]今天的警告文件上有错误产生：Fri Sep 5 00:18:19 2008ORA-1461 encountered when generating server alert SMG-3500但是这个错误在官方的文档上居然没有。查找Metalink发现：Subject: Ora-1461 Encountered When Generating Server Alert Smg-3500 Doc ID: Note:461911.1 Type: PROBLEM Last Revision Date: 09-JUL-2008 Status: MODERATED In this Document Symptoms Cause Solution References----------------------------------------------------

某几个磁盘消耗过多情况的调查[@more@]某几个磁盘消耗过多情况的调查在生产环境上如果使用AIX的命令topas来看的时候，老是看到磁盘2，3，9，10过多消耗，几乎都是80-90%，但是其他的磁盘确实很少。针对这种情况对系统的磁盘配置进行调查。说明：这里不考虑SAN的配置问题，其实现实情况底层的存储设备已经都会对磁盘进行分配。现象：Disk Busy% KBPS TPS KB-Read KB-Writ PgspIn 0 % Noncomp 18.8hdisk9 85.0 1.9K 238.0 1.8K 80.0 PgspOut 0 % Client 18.8hdisk2 80.0 1.7K 204.0

外键没有索引对性能的影响[@more@]建立一个索引create index tmp_ind_1 on tmp_f (num,id);exec dbms_stats.gather_table_stats('KB','tmp_f');exec dbms_stats.gather_table_stats('KB','tmp_p');SQL> delete from tmp_p where pk =100001;已删除 1 行。执行计划----------------------------------------------------------Plan hash value: 797653082-----------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |--

外键没有索引对性能的影响[@more@]2、在从表的外键没有索引的时候，update主表上的一个数据delete主表上的一个数据是一样的要求。SQL> update tmp_p set pk=100000 where pk=100001;已更新 1 行。执行计划----------------------------------------------------------Plan hash value: 3169732106--------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time-----------------------------------------------------------------

外键没有索引对性能的影响[@more@]外键没有索引对性能的影响大家都知道关于外键上没有索引会产生锁的出现，这里不再累述，本文只是就外键没有索引的情况下，Oracle在执行DML语句的时候，CBO为了保证数据的一致性而进行的隐形调用，而这些调用恰恰是反应在Oracle的DML语句执行的性能上，但是这些调用在你使用trace上是无法通过执行计划上看到的。建立环境：drop table tmp_f purge;drop table tmp_p purge;create table tmp_f as select rownum id,rownum num,a.* from all_objects a where 1=0;create table tmp_p(pk number primary key,

log_archive_dest_n 和log_archive_dest和 log_archive_duplex_dest[@more@]1、LOG_ARCHIVE_DEST_n这个参数应该是在9i之后引入的一个参数，Oracle之所以引入这个参数我认为是有以下几点：1、为了多引入一些归档日志的存放位置。其中n为1－10（10g）For Enterprise Edition users, this parameter has been deprecated in favor of the LOG_ARCHIVE_DEST_n parameters. If Oracle Enterprise Edition is not installed or it is installed, but you have not specified any LOG_ARCHIVE_DEST_n parameters, this parameter is valid.2、从上

FIRST_ROWS和FIRST_ROWS_n的区别[@more@]FIRST_ROWS和FIRST_ROWS_n的区别1、 FIRST_ROWS_n是在9i之后引入的，应该说FIRST_ROWS模式在9i之后就应该被废弃，之所以还使用主要是因为为了向下兼容的目的。2、 FIRST_ROWS是为了返回前几行，应该说是FIRST_ROWS_1相似。3、 FIRST_ROWS这种模式使用的过程中，CBO会使用一些约束，而这些约束将会限制CBO对表之间的连接模式的选择，其中就有一个是对hash连接的选择，而使用嵌套连接的方式，这样就需要对一个表进行全表扫描，或者使用索引。例如排序order by和group by的时候。这时候系统会使用索引