Skip to content

Oracle - 68. page

BUG:shutdown immediate (hung住)

ora 10g 10201

BUG1:shutdown immediate 时系统hung住,经metalink查询:

Verify that temporary segments are decreasing
———————————————
To verify that the temporary segments are decreasing have an active session
available in Server Manager or SQLPLUS during the SHUTDOWN IMMEDIATE. Issue the following
query to ensure the database is not hanging, but is actually perform extent
cleanup:

SVRMGR/SQL> select count(block#) from fet$;
COUNT(BLOC
———-
7

SVRMGR/SQL> select count(block#) from uet$;
COUNT(BLOC
———-
402

After some time has elapsed, reissue the query and see that the values for fet$
have increased while the values or uet$ have decreased:

SVRMGR/SQL> select count(block#) from fet$;
COUNT(BLOC
———-
10

SVRMGR/SQL> select count(block#) from uet$;
COUNT(BLOC
———-
399

During shutdown the SMON process is cleaning up extents and updating the data
dictionary tables with the marked free extents. As the extents are marked as
freed, they are removed from the table for used extents, UET$ and placed on the
table for free extents, FET$.

How to Avoid creating many Temporary Extents
——————————————–
Once the database has shutdown cleanly, to avoid creating many temporary
extents change the initial and next extent sizes on temporary tablespaces
to a more appropriate size:

ALTER TABLESPACE DEFAULT STORAGE (INITIAL M/K NEXT M/K);

Note: If the temporary tablespace is of type TEMPORARY, then this change
will only affect temporary segments created after issuing the above
command. Any existing temporary segments already in the TEMPORARY tablespace
will not be affected till the instance is restarted. On shutdown, existing
temporary segments are dropped. If the TEMPORARY TABLESPACE is of type
PERMANENT, then cleanup is performed by SMON after completion of the process
using it.

Increasing the initial and next extent size will decrease the number of extents
that are allocated to temporary segments. Since there are fewer extents to
deallocate, the database should shutdown more speedily.

Take the following scenario:

A database was subject to large sorts with the following sort parameter in
the “init.ora” file:

– sort_area_size=1000000

The temporary tablespaces for this database were all created with initial and
next extents sized at 50k and the total database size was about 300mb.

Database sorts will utilize memory as much as possible based on the “init.ora”
parameter “sort_area_size”. Once this memory-based sort area is filled, the
database will utilize the temporary table space associated with the database
user to complete the sort operation. During a shutdown normal, the database
will attempt to clean up the temporary tablespaces.

If a small extent size is used, then a large number of extents will be created
for a large sort. The cleanup of the temporary tablespace takes much longer
with a large number of extents.

Note:
=====
You have to do a shutdown abort and then bring the database
back up to run the suggested queries.

For other reasons for slow/hung shutdown see also these notes:

Note 375935.1 – What To Do and Not To Do When ‘shutdown immediate’ Hangs
Note 428688.1 – Bug:5057695: Shutdown Immediate Very Slow To Close Database.

References:
===========Note:61997.1 SMON – Temporary Segment Cleanup and Free Space Coalescing

Search Words:
=============
hanging
shutdown

在安装完oracle后DBCA或者NETCA无法打开

确认这个错误我一共分三个步骤:

1:oracle正确安装了,但是建库时候dbca无法打开,提示没有这个命令。

那么就可以确认这个是环境变量的问题,

env | PATH

没有发现$ORACLE_HOME

cd $ORACLE_HOME | pwd

提示为: /home/oracle

我的oracle_home目录为:

/oracle/product/10.2.0/db_1

————————————————-

很显然问题出在这里,

vi .profile

修改

export PATH=$ORACLE_HOME/bin:.:$PATH:/usr/local/bin:/usr/ccs/bin

export PATH=$PATH:$ORACLE_HOME/bin:.:$PATH:/usr/local/bin:/usr/ccs/bin

经过发现这个错误一般在aix5.3下面产生。

AIX夏令时导致应用时间对比异常终端处理

前几天一个客户反应系统时间比现实晚一个小时,导致无法刷卡。因为oracle的时间是通过获取系统当前时间

11月6号。

当时我查了下发现是AIX系统开启夏令时导致的

echo $TZ

beist-8TD

————-

在aix 5.3补丁打齐下可以使用命令

chtz beist-8

修改。

或者直接修改/etc/environment

TZ=Beist-8

或者smit 里修改。

—————————————–

在aix6.1系统中推荐使用后面的2种方法修改,修改后建议重启AIX

ksvcreate: Process(m000) creation failed

10. 7. 2009, 12.09
Alert.log:
==========
Fri Jul 10 09:24:19 2009
WARNING: inbound connection timed out (ORA-3136)
Fri Jul 10 09:30:11 2009
Process m000 died, see its trace file
Fri Jul 10 09:30:11 2009
ksvcreate: Process(m000) creation failed
Fri Jul 10 09:31:12 2009
Process m000 died, see its trace file

Trace file:
===========
*** SERVICE NAME:(SYS$BACKGROUND) 2009-07-09 20:35:37.278
*** SESSION ID:(3295.1) 2009-07-09 20:35:37.278
ktsmgtur(): TUR was not tuned for 1644 secs
ktsmg_advance_slot(): MMNL advances slot after 1786 seconds
*** 2009-07-10 09:30:11.004
Process m000 is dead (pid=32562, state=3):
Unable to schedule a MMON slave at: Auto Flush Main 1
Attempt to create slave process failed.
Can happen for several reasons:
– No process state objects
– Reached OS set limits
– A shutdown was going on
Check alert log for more details.

CHECKS:
=======
SQL> show parameter process

NAME TYPE VALUE
———————————— ———– ——————————
processes integer 3000

SQL> show parameter session

NAME TYPE VALUE
———————————— ———– ——————————
sessions integer 3305

SQL> select count(*) from v$session;

COUNT(*)
———-
2994

SELECT COUNT(*) FROM v$process;

COUNT(*)
———-
2990

Solution
========
– kill processes which generates the processes ( usually from http)
– restart database
– this error coresponds with ORA-3136

ORA 600 [4000] 一则

aix p570,oracle 925

首先检查v$datafile_header,发现checkpoint_change#都是一致的。
于是按着一般的当前在线日志文件损坏步骤处理:
增加下列参数至Oracle启动文件:
_allow_resetlogs_corruption=TRUE
_corrupted_rollback_segments=(list of all your rollback segments)
注释掉启动文件中的rollback_segments参数或undo_tablespaces参数
startup mount
recover database until cancel
alter database open resetlogs;
一般情况下,open resetlogs后最容易出现的600号错误为ora-600 [2662]和ora-600 [2256]。这两个错误也相对来说好处理一些,只需要采用10015事件adjust scn号即可。
但是这次我却是碰到了ora-600 [4000]号错误。
Errors in file /home/oracle/app/oracle/admin/test/udump/test_ora_2838638.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [4000], [46], [], [], [], [], [], []
Mon Feb 13 04:01:22 2011
Error 704 happened during db open, shutting down database
USER: terminating instance due to error 704
Instance terminated by USER, pid = 2838638
metalink上对该错误的解释是:
DESCRIPTION:

This has the potential to be a very serious error.

It means that Oracle has tried to find an undo segment number in the
dictionary cache and failed.

ARGUMENTS:
Arg [a] Undo segment number

FUNCTIONALITY:
KERNEL TRANSACTION UNDO

IMPACT:
INSTANCE FAILURE – Instance will not restart
STATEMENT FAILURE
由于一开始_corrupted_rollback_segments里面只是列到_syssmu20$,于是将它列到_syssmu60$。重试后还是报这个错。
增加10513事件,禁止smon进程回滚,结果还是一样。
在600号的Trace文件中有:
ORA-00600: internal error code, arguments: [4000], [46], [], [], [], [], [], []
Current SQL statement for this session:
select ctime, mtime, stime from obj$ where obj# = :1
于是我怀疑会不会是undo$基表中没有46号回滚段的信息?
采用bbed检查undo$表格,发现里面是有这个回滚段的信息。
于是我想这个错误是出现在访问obj$基表上面,也就是说该表格的scn号与系统当前的scn号是不一致的。于是我想偿试修改该块的scn号。依然采用bbed,偿试修改该块的scn号。修改后,结果还是一样的。
于是我想应该是obj$基表上还有一个未提交的事务。于是继续查看trace文件,发现如下信息:
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x002e.025.00005b2c 0x00800f78.080c.01 –U- 1 fsc 0x0000.c5b527cf
data_block_dump,data header at 0x700000001f6e044
===============
tsiz: 0x1fb8
hsiz: 0xea
pbl: 0x700000001f6e044
bdba: 0x0040007a
76543210
flag=——–
很明显,是有一个未提交的事务,用bbed修改该事务的状态,将该事务改成提交状态。
首先找到itl信息:find /x 00005b2c,找到flag状态,现在其状态是20,也就是未提交,将之修改为80(提交状态),并修改checkval。
之后去掉所有隐含参数,正常启动数据库,发现后台报出了ora-600[2662]错误。哈哈,事情至此就好办了,采用10015 adjust scn号,正常启动数据库:
Mon Feb 14 15:47:23 2011
Completed: ALTER DATABASE OPEN
Mon Feb 14 15:47:23 2011
Fatal internal error happened while SMON was doing active transaction recovery.
Mon Feb 14 15:47:23 2011
Errors in file oracle/admin/test/bdump/test_smon_2293872.trc:
ORA-00600: internal error code, arguments: [ktpridestroy2], []
SMON: terminating instance due to error 600
Instance terminated by SMON, pid = 2293872
从这块日志可以看出数据库正常启动后,马上因为smon回滚又导致了实例宕下来。
增加10513事件,启动数据库,一切正常。
想drop tablespce undotbs1,但是报出59号回滚段还有active事务无法删除。
于是增加_corrupted_rollback_segments参数,将数据库启来,新建一个回滚表空间,将原来的回滚表空间重建后,一切正常。