ORA-00600: internal error code, arguments: [pfri.c: pfri8: plio mismatch ]错误
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错误的一个原因
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
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
外键没有索引对性能的影响(2)
外键没有索引对性能的影响[@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 |--
外键没有索引对性能的影响(3)
外键没有索引对性能的影响[@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-----------------------------------------------------------------
外键没有索引对性能的影响(1)
外键没有索引对性能的影响[@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
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的区别
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的时候。这时候系统会使用索引
I/O Calibration
I/O Calibration[@more@]I/O Calibration在Oracle11g中有一个比较有意思的引入,就是引入了一个过程来测量IO的基准。DBMS_RESOURCE_MANAGER.CALIBRATE_IO这个过程的功能是用于效准IO存储磁盘的性能,可以使用下面的工程来测试:SQL> SET SERVEROUTPUT ONSQL> DECLARE 2 lat INTEGER; 3 iops INTEGER; 4 mbps INTEGER; 5 BEGIN 6 -- DBMS_RESOURCE_MANAGER.CALIBRATE_IO (<DISKS>, <MAX_LATENCY>, iops, mbps,lat); 7 DBMS_RESOURCE_MANAGER.CALIBRATE_IO (1, 10, iops, mbps, lat); 8 9 DBM
大型数据库(T level)管理
大型数据库(T level)管理[@more@]大型数据库T管理谈谈自己的想法:在分析这个问题的时候,需要看这个数据库是OLTP,OLAP还是DSS,不同的类型管理的侧重应该是不一样的。数据库的规划:对于大多数数据库来说,之所以这个数据库能够上T,是因为一个或者多个表的数据量比较大,而数据量比较大的表的数量一般不是很多,这是因为在数据库开始规划的时候就应该考虑到这些问题。一般来说会根据功能,IO,或者表的大小等将数据库split。在数据库的规划阶段还需要注意的问题是有可能成为大表的两个或者几个大表之间的连接问题,一般来说系统出现性能
Redo wastage产生的原因
Redo wastage产生的原因[@more@]Redo wastage产生的原因在v$sysstat中有一个统计是redo wastage,这个究竟是什么意思,为什么汇产生这个问题哪?reod wastage会对系统的性能产生影响吗?1、为什么会产生redo wastage?我们都熟知产生的redo会先写入到redo buffer中,然后Oracle中的LGWR进程会根据某些触发条件将redo buffer中的redo写入到redo文件中。redo文件一般块是512,除去每个块有16字节的块头,真正能够使用的部分512-16。而redo文件在逻辑上是有redo record组成。LGWR写入redo的时候,会在redo文件中留下一些没有使用的空间,例如
10g中的新伪列ORA_ROWSCN总结
10g中的新伪列ORA_ROWSCN总结[@more@]10g中的新伪列ORA_ROWSCN总结这个伪列是10g中引进的,在oracle的官方文档上说的是:这个伪列是为了提供每一行最近修改的SCN的上限。For each row, ORA_ROWSCN returns the conservative upper bound system change number (SCN) of the most recent change to the row.不过oracle随后也说这是一行最新修改的大致SCN的确定。为什么是这样的哪?Oracle解释说是这个SCN的跟踪是对这个行驻留块的事务提交的SCN而得到的。This pseudocolumn is useful for determining approximately when a row was last u
Oracle 11g对AWR的扩展
Oracle 11g对AWR的扩展[@more@]Oracle 11g对AWR的扩展1、AWR数据的导入、导出在Oracle 11g中能够将AWR数据在系统之间传递,这个功能有利于使用分离的系统来处理、分析AWR数据。在传递AWR数据,需要两个过程:将AWR数据从源数据中导出,然后在将这些数据导入到目的数据库中。导出AWR数据使用的是$ORACLE_HOME/rdbms/admin/awrextr.sql这个脚本。导入AWR数据使用的是$ORACLE_HOME/rdbms/admin/awrload.sql这个脚本2、Baseline Templates在10g中只是有baseline这个,在11g中新添加了这个概念,按照Oracle官方的定义就是:这个所谓的Baseline
RMAN中检查脚本语法错误的命令
RMAN中检查脚本语法错误的命令[@more@]RMAN中检查脚本语法错误的命令在执行RMAN脚本或者命令之前,需要将这个脚本或者命令检查一遍,看看命令或者脚本上是否存在语法错误,这就可以使用Oracle提供的一个检查RMAN脚本,命令语法错误的命令checksyntax ,(检查命令文件中的语法错误)但是这个命令执行的时候是不实际运行的。例如:RMAN> run < backup database;>RMAN-00571: ===========================================================RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============RMAN-00571: ==
关于直接路径插入的工作原理
关于直接路径插入的工作原理[@more@]关于直接路径插入的工作原理关于直接路径插入的工作原理可以从三个形式的插入来说:1、串行直接路径插入到分区或者非分区表这个比较容易理解,就是一个单独的进程将数据直接插入到表数据段上每一个分区段的高水位之上的空间。这里说的直接路径是指不经过数据缓冲区。2、并行直接插入到分区表这个和第一中情况类似,每一个进程对应一个或者多个分区段,但是每一个分区段最多只能有一个进程对应,一个单独的进程将数据直接插入到表数据段上每一个分区段的高水位之上的空间。3、并行直接插入到非分区表这个
可恢复空间分配
可恢复空间分配[@more@]可恢复空间分配在平时我们做一个大的表的索引,或者插入大量数据的时候,临时表空间,undo表空间或者数据表空间都有可能会产生空间不足的错误,这时候就可以利用可恢复表空间来管理,将这个操作挂起,等错误排除之后再恢复。这个好用的功能是在Oracle 9i之后被引入的。这个功能在thomas的http://tomszrp.itpub.net/post/11835/264965已经介绍比较详细了。两种启动方式1、设置resumable_timeout。2、alter session enable resumable可恢复语句被挂起的发生状态:1、超出空间使用ORA-1653 unable to extend table ...
对临时表空间的SHRINK
对临时表空间的SHRINK[@more@]对临时表空间的SHRINK在11g中新添加一个新的功能就是对临时表空间的SHRINK,在使用临时表空间的时候,可能临时表空间被扩展的比较大,如何将临时表空间缩小到自己想要的大小,这是11g推出这个命令的目的。这个命令只能用于临时表空间。能够减少临时表空间的使用。有两种方式使用:1、将本地管理的临时表空间缩小为20M。SQL> select bytes/1024/1024 from v$tempfile;BYTES/1024/1024--------------- 28SQL> alter tablespace temp shrink space keep 20M;Tablespace alteredSQL> select
READ_ONLY_OPEN_DELAYED参数
READ_ONLY_OPEN_DELAYED参数一直没有在意这个参数,再一次看Oarcle文档的时候,看到这个参数。在一个很大的数据库上的比较大的一部分只读表空间是存储在低速访问的设备上。例如CDROM上的时候,需要将这个参数设置为true。[@more@]
数据库驻留连接池(Database Resident Connection Pooling)(4)
数据库驻留连接池(Database Resident Connection Pooling)(4)[@more@]配置连接池可以使用包dbms_connect_pool来配置连接池。在RAC环境下,配置参数针对的是每一个oracle RAC实例而言的。参数说明MINSIZE在pool中最小数量的pooled servers,缺省为4MAXSIZE在pool中最大数量的pooled servers,缺省为40INCRSIZE这个参数是在一个客户端应用需要连接的时候,当pooled servers不可用的状态时候,每次pool增加pooled servers的数目。SESSION_CACHED_CURSORS缓存在每个pooled servers上的会话游标的数目,缺省为20INACTIVITY_TIMEOUTpooled ser