我们最宝贵的金融资产

我们最宝贵的金融资产就是赚钱的能力。如不能持续投资以增进自己的产能,眼光就会受到局限,只能在现有的职位上踏步,每天忙忙碌碌,就怕老板对自己印象不佳,既在经济上受制于人,又担心职位不保。

ORA-27091: skgfqio: unable to queue I/O 

今天一早刚刚醒,接到单位电话,有个刚刚迁移的数据库做批量报错。开发人员跟我说手工执行批量里面的脚本没问题,寻思着不会又碰到oracle的bug了吧。由于不是特别影响,让他把报错发给我。
开电脑,连vpn,开notes,收邮件。

以下部分2011年1月8日更新:

ORA-01115: IO error reading block from file <file id> (block # <block number>
ORA-01110: data file <file id>: <file name>
ORA-27091: skgfqio: unable to queue I/O
ORA-27072: skgfdisp: I/O error
IBM AIX RISC System/6000 Error: 5: I/O error

- The errors are not reported in the alert log file.
- Running dbv against datafiles from the error messages shows no errors.
- All the mandatory OS patches are applied.
- Oracle patch for Bug 5496862 – IO READING PROBLEMS AFTER INSTALLING IBM
TECHNOLOGY LEVEL 5 (5300-05) was installed before patching the OS.

Changes
Patch IBM Technology Level 6 (5300-06) or higher was applied to the OS.

Cause
The value of maxreqs (4096) was too low. This asynchronous I/O parameter
specifies the maximum number of asynchronous I/O requests that can be
outstanding at any one time and has as default value 4096.

Solution
Increase maxreqs to a value greater than or equal to 8192.

Steps:
1. run aioo -a command to double check current setting for aio0 device
2. run aioo -o maxreqs=<value> to set maxreqs dynamically
3. chdev -l aio0 -a maxreqs=<value> -P to set the value of maxreqs
permanently for next reboot
4. run aioo -a to confirm change
5. restart oracle

NOTE: Values that fixed the errors: 8192, 16384 or 32768.

smitty aio 修改maxreqs参数到8192 同时修改minservers 到10 、maxservers到80 重启系统及操作系统后 至今为止正常。

ORACLE 性能分析指引—–Hand/Locking(一)发现问题

一、识别到底是Hang 还是 Locking

1.Hang的表现:用户不能登陆、数据库不能操作、select 1 from dual; 无返回、无法创建表。

2.Locking的表现:一个或者多个session无响应。

3.可能导致问题的原因:schema 的变更、数据库参数的修改、应用的修改、数据库的升级等。

4.理清本次问题:受影响的用户、可能导致该问题的事件的顺序、何时以及如何被发现的、明显的问题、什么还在正常工作、可接受的结果、可以尝试解决问题的方案。

点击查看更多

oracle 字符集相关信息

1.oracle 字符集的命名规则:<language><bit size><encoding>

2.NSL_LANG参数组成

NLS_LANG=<language>_<torritory><client characte rset>

language :o racle 消息使用的语言

torritory:指定货币、数字格式、地方和计算星期及日期的习惯

character set:控制客户端应用程序使用的字符集

3.相关试图:

nls_database_parameters

AIX An error occurred during bosboot verification processing

碰到一个比较妖的问题,解决后给大家一个参考.
安装软件包时报0503-497,报
0503-409 installp: bosboot verification starting…
0503-497 installp: An error occurred during bosboot verification processing.
不得其解.
手工执行bosboot正常.

lppchk -v检查正确
bosboot正常
hd5正常
发现/dev下没有ipldevice,问题在此
ln /dev/rhdisk0 /dev/ipldevice
解决问题,安装正常.

esource busy and acquire with NOWAIT specified 解决方法

1. 通过dba_objects 查到锁掉的对象的object_id.
select object_nameobject_id from dba_objects
where object_name like ‘*****’;
2.在v$_locked_object中找到锁掉的session_id
select session_id,object_id from v$locked_object
where object_id=***;
3.在v$_session 找到锁掉的session的sid及serial#
select username,sid,serial# frin v$session
where sid=****;
4.根据SID查找对应的sql
select sql_text from v$session a,v$sql_text_with_newlines b
where DECODE(a.sql_hash_value,0,prev_hash_value,sql_hash_value)=b.hash_value
and a.sid=***;
5.如果确认了sid是sql是不重要的,则kill对应的session即可
alter system kill session ‘SID,SERIAL#’;

1. 通过dba_objects 查到锁掉的对象的object_id.     select object_nameobject_id from dba_objects where object_name like ‘*****’;2.在v$_locked_object中找到锁掉的session_id select session_id,object_id from v$locked_object where object_id=***;3.在v$_session 找到锁掉的session的sid及serial# select username,sid,serial# frin v$session where sid=****;4.根据SID查找对应的sql select sql_text from v$session a,v$sql_text_with_newlines b where DECODE(a.sql_hash_value,0,prev_hash_value,sql_hash_value)=b.hash_valueand a.sid=***;5.如果确认了sid是sql是不重要的,则kill对应的session即可alter system kill session ‘SID,SERIAL#’;

oracle datagurad 日志切换频率

修改参数ARCHIVE_LAG_TARGET = seconds,单位秒;

默认为0,disable该功能
修改范围是60-7200
oracle 推荐1800 即30分钟
如果该参数设置过低,会导致oracle日志频繁切换。
修改方式:alter system
在RAC中,所有instance 该参数需要设置为相同。

oracle recyclebin 管理

管理回收站

如果在该过程中没有实际删除表因而没有释放表空间那么当被删除的对象占用了所有空间时,会发生什么事?

答案很简单:这种情况根本不会出现。当表空间被回收站数据完全占满,以至于必须扩展数据文件来容纳更多数据时,可以说表空间处于“空间压力”情况下。此时,对象以先进先出的方式从回收站中自动清除。在删除表之前,相关对象(如索引)被删除。

同样,空间压力可能由特定表空间定义的用户限额而引起。表空间可能有足够的空余空间,但用户可能将其在该表空间中所分配的部分用完了。在这种情况下,Oracle 自动清除该表空间中属于该用户的对象。

此外,有几种方法可以手动控制回收站。如果在删除名为 TEST 的特定表之后需要从回收站中清除它,可以执行

PURGE TABLE TEST;

或者使用其回收站中的名称:

PURGE TABLE "BIN$04LhcpndanfgMAAAAAANPw==$0";

此命令将从回收站中删除表 TEST 及所有相关对象,如索引、约束等,从而节省了空间。但是,如果要从回收站中永久删除索引,则可以使用以下命令来完成工作:

purge index in_test1_01;

此命令将仅仅删除索引,而将表的拷贝留在回收站中。

有时在更高级别上进行清除可能会有用。例如,您可能希望清除表空间 USERS 的回收站中的所有对象。可以执行:

PURGE TABLESPACE USERS;

您也许希望只为该表空间中特定用户清空回收站。在数据仓库类型的环境中,用户创建和删除许多临时表,此时这种方法可能会有用。您可以更改上述命令,限定只清除特定的用户:

PURGE TABLESPACE USERS USER SCOTT;

诸如 SCOTT 等用户可以使用以下命令来清空自己的回收站

PURGE RECYCLEBIN;

DBA 可以使用以下命令清除任何表空间中的所有对象

PURGE DBA_RECYCLEBIN;

可以看到,可以通过多种不同方法来管理回收站,以满足特定的需要。

oracle expdp 报错 ORA-39014

oracle expdp 报错 ORA-39014

报错信息如下:

ORA-39014: One or more workers have prematurely exited.
ORA-39029: worker 1 with process name “DW01″ prematurely terminated
ORA-31671: Worker process DW01 had an unhandled exception.
ORA-00600: internal error code, arguments: [qmtInit1], [], [], [], [], [], [], []
ORA-06512: at “SYS.KUPW$WORKER”, line 1345
ORA-06512: at line 2

解决办法:修改LD_LIBRARY_PATH 把绝对路径修改为:$ORACLE_HOME/lib:$ORACLE_HOME/lib32

重启数据库

使用RMAN方式建立ORACLE DATAGUARD

1.      备用库数据软件安装相关目录的准备

(adump、bdump、cdump、udump;、/oradata;/arch、/arch/standby等)

2.      备份数据库standby controlfile

rman target / (主机上)

backup full database format=‘/oradata/standby/fulldatabase_%U.dbf‘ include current controlfile for standby;

把备份的数据全部拷贝到备机的相同目录

点击查看更多