ITPub博客

这问题是由最近一个数据库AYSAUX使用空间过多引出来的.SM/OPTSTAT是用于存储老的统计信息，10G之前，当对表/字段/索引做了相应的统计信息之后，新的统计信息就会覆盖老的统计信息，也就是说的无法直接找回统计信息，要找回，只能事先通过dbms_stats导出来。10G就不必了，它会自动的存到相应的表里，而这些表是存在sysaux的，但这也引出了一个问题：如果这些表的数据不断的增长，而不把老的数据删除的话，sysaux迟早会暴了的。默认的情况下,系统会为SM/OPTSTAT保留31天的记录，可以通过dbms_stats.get_stats_history_retention来确定。这里

自上次的文件系统owner变成数字200，数据库启动不了的问题后，这两天还碰到类似的问题。症状：以自己的ID试图连接数据库，出现如下错误：SQL*Plus: Release 10.2.0.2.0 - Production on Mon Apr 19 22:20:37 2010Copyright (c) 1982, 2005, Oracle. All Rights Reserved.Enter password:ERROR:ORA-12541: TNS:no listenertnsping没问题，到server那端查一下listener的trace:19-APR-2010 22:00:42 * (CONNECT_DATA=(SID=<SID>)(CID=(PROGRAM=sqlplus)(HOST=hostname)(USER=***))) * (ADDRESS=(PROTOCOL=tcp)(HOST=123.123.123.123)(

今天导数据碰到如下错误：Processing object type SCHEMA_EXPORT/SEQUENCE/GRANT/OWNER_GRANT/OBJECT_GRANTORA-39014: One or more workers have prematurely exited.ORA-39029: worker 1 with process name "DW01" prematurely terminatedORA-31671: Worker process DW01 had an unhandled exception.ORA-00600: internal error code, arguments: [unable to load XDB library], [], [], [], [], [], [], []ORA-06512: at "SYS.KUPW$WORKER", line 1397ORA-06512: at line 2Job "SYS"."SYS_EXPORT_S

昨天碰到一个比较怪异的事，启动数据库时，报这样的错误：SQL> startupORACLE instance started.Total System Global Area 557842432 bytesFixed Size 2085328 bytesVariable Size 415239728 bytesDatabase Buffers 104857600 bytesRedo Buffers 35659776 bytesORA-00221: error on write to control fileORA-00206: error in writing (block 1, # blocks 1) of control fileORA-00202: control file: 'PATH/control01.<SID>'ORA-27041: unable to open fileIBM AIX RISC

上星期参加了IBM ITIL培训，简单记录一下主要的内容，ITIL是Information Technology Infrastructure Library的缩写。个人理解就是IT服务的流程理论。总体上分为两大块:Service Support和Service Delivery. 前者是操作流程，后者是战术流程。在notepad画好的图形不能正常显示,晕死..[@more@]Service Support的大略构架如下：------------------------------------------------------------------------| Customers & Users |------------------------------------------------------------------------Difficlities | ^Workaround |RFC

事情起因，今天看到一条非常”稀奇古怪“的SQL，select语句中，在表后面跟了一大窜以model开头的东东，后来查一下资料，原来model在数据仓库中是比较有地位的.列一下几个简单的测试：[@more@]1,测试表中数据：SQL> select * from test1;COUNTRY PRODUCT YEAR SALES---------- ---------- ---------- ----------USA Stock1 2008 100USA Stock1 2009 200USA Stock2 2008 300USA Stock2 2009 500CHINA Stock1

问题的起因：最近发现一张分区表：从dba_table得到的统计信息跟dba_tab_stats/dba_tab_partitions查得的信息出入很大,后来查得的原因是: 脚本里调用dbms_ddl来收集统计信息，而dbms_ddl实际上是调用analyze命令，analyze基本上不会用来收集统计信息了。我们通常是调用dbms_stats来统计的。下面是实验证明：num_rows和last_analyzed来自dba_tables/dba_tab_stats/dba_tab_partitions[@more@]SQL> create table test( a number, b varchar2(30)) partition by hash(a) partitions 8;Table created.SQL> insert into test select objec

环境：OS: SunOS Hostname 5.10 Generic_127111-11 sun4u sparc SUNW,Sun-Fire-V890DB VERSION: Oracle9i Enterprise Edition Release 9.2.0.8.0 – Production改动: 安装了CPUJul2009 这里有点要说明的：操作系统是64位的，而数据库是32位的。这个从理论上讲不会造成什么问题的，因为这个系统已经跑了几年了。症状：执行如下SQL，碰到ORA-4030.SQL> declaresr sys_refcursor;beginsr:=Pkg_rpt_BillVsAccrual.FN_RPT_BILLVSACCRUAL('DE5','BILL-030',to_date('01/02/2006','MM/DD/YYYY'),to_date('02/28/2006', 'MM/DD/YYYY'));end; 2

通常情况下，一条SQL语句经过parse,bind variables,execution和fetch,但对于DDL是不经过后面两个阶段的，这个现象是同事刚刚发现，查一下文档上面也确实提到了DDL经过parse就执行了：PARSE ProcedureThis procedure parses the given statement in the given cursor. All statements are parsed immediately. In addition, DDL statements are run immediately when parsed.There are two versions of the PARSE procedure: one uses a VARCHAR2 statement as an argument, and the other uses a VARCHAR2S (table of VARCHAR2) as an arg

环境OS： SunOS HOSTNAME 5.10 Generic_127111-11 sun4u sparc SUNW,Sun-Fire-V890DB：Oracle9i Enterprise Edition Release 9.2.0.8.0 - Production问题：一个包处于无效状态，通常直接用命令编译一下，就行了，但这个简单的操作，却碰到:SQL> alter package SCHEMA.PACKAGENAME compile;alter package SCHEMA.PACKAGENAME compile*ERROR at line 1:ORA-04043: object SYS_PLSQL_6459_DUMMY_2 does not exist[@more@]这个错误，其实在9i里这是比较常见的错误，在SP里定义：TYPE和TABLE OF TYPE的数据对象时.Oracle就会自动的在系统内生

环境OS：SunOS hostname 5.10 Generic_127111-11 sun4u sparc SUNW,Sun-Fire-V490DB: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production一个JOB做MVIEW refresh做了十多个小时，还没做完，这个JOB定义：每隔20分钟去涮新一次，发现现在JOB状态为broken了，显然上次refresh完全在20分钟内完成；先查一下alert，发现日志切换太频繁了，2到3分钟就切换一下，online redo才50M(也不知道那个家伙这么设置的),这个显示太小了，把它扩展到500M,性能并没有什么好转.[@more@] 查下JOB的具体名为内容： dbms_refr

启动一个数据库时，碰到这个错误： [oracle]$ sqlplus "/ as sysdba" SQL*Plus: Release 10.2.0.4.0 - Production on Mon Jan 4 10:40:36 2010 Copyright (c) 1982, 2007, Oracle. All Rights Reserved. ERROR: ORA-09925: Unable to create audit trail file Linux Error: 30: Read-only file system Additional information: 9925 ORA-09925: Unable to create audit trail file Linux Error: 30: Read-only file system Additional information: 9925[@more@] 从上面输出的错误来看，第一个判断是不能创建审计跟踪文件，可能