9.2杀死僵死连接
有时候由于客户端的异常退出，会出现一些连接的进程一直在运行，从而不能释放资源，影响系统的性能。可用以下方法实现把僵死的连接清除。
查询数据库死锁 selectdistinct * from (select t2.username,t2.sid, t2.serial#, t2.logon_time from v$locked_object t1,v$session t2 where t1.session_id =t2.sid) orderby logon_time;
查询出来的结果就是有死锁的session了， altersystemkillsession'sid,serial#';
一般情况可以解决数据库存在的死锁了，或通过session> SELECT a.username, c.spid ASos_process_id, c.pid AS oracle_process_id FROM v$session a, v$process c WHERE c.addr = a.paddr and a.sid = m and a.serial# = n;
采用kill （unix/linux） 或 orakill（windows ）
kill -9 os_process_id 9.3AIX内存溢出
环境: AIX平台，任何版本的Oracle
现象： 第一次：小机内核的CPU利用率达到40%，有一个进程占用内存不释放，Paging Space达到100%。重启AS、迪斯杰备份及小机后利用率及Paging Space下降至正常。 第二次：闭市后用SQLPlus连接到RAC1上，做了一些三方存管帐户的批量修改。晚上在清算处理时，在文件标志复位时发现很慢，查看Paging Space利用率为40%,但小机利用率正常。重开AS及迪斯杰备份后，利用率下降到30%，文件标志复位也很快了，在清算过程中利用率也一直在下降，一直到19%点多。清算结束后又重开AS及迪斯杰备份，Paging Space利用率为18.9% ，后将RAC1和rac2的ORACLE数据库重开（shut dowm及start）后，下降到5.6%。
原因： 当Sga，Pga设置过小时，数据库会把不能置于内存中的数据放到交换区去，磁盘的IO速度比内存慢很多，所以会对性能产生较大影响。在极端情况下，如果交换分区全部耗尽，那对系统性能的影响就更大了。 在AIX系统中，内存可以分为两类：计算型内存和文件型内存。类似大量文件类操作，如文件复制、压缩、数据库的dump/load等操作会大量占用文件型内存。如果按照系统缺省的配置，文件型内存最多会占用到内存总量的80%，由于文件型内存占用并不主动释放，从而可能造成内存资源的短缺及Paging Space使用率过高。特别是，由于数据库存储使用的是裸设备，允许文件缓存占用大量的内存是没有必要的。 命令topas可以用来查看文件型内存占用内存情况，在MEMORY一栏中的%Noncomp显示的是文件型内存的占用百分比。 如果文件型内存所占比例很高，而Paging Space使用率居高不下时，可以通过降低minperm、maxperm的参数值来进行调优，减少文件型内存可占用的份额。
解决方法： 在进行调整前，首先通过命令vmo -a来查看目前的参数值；minperm及maxperm的缺省值分别是20%和80%。注意：在调小maxperm%前，请产生同时降低maxclient%的值（即maxclient%的值不得大于maxperm%的参数值）。谨慎起见，可以通过小量多次调整来达到性能优化的目的。如maxperm% 可以依次调整了60，40，20，同时查看性能的性能。 最终可能可以调整为：
vmo -o minperm%=10
vmo -o maxclient%=20
vmo -o maxperm%=20 因为参数maxperm充当的是软限制，所以文件型内存的占用率依旧可以超过maxperm的设定值。如果需要进行强制限制，则需要将参数strict_maxperm的值设为1，该参数的缺省值为0，但此方法需谨慎使用。
其它
交换分区设置过小也可能引起交换分区利用率过高的问题。交换分区的大小与物理内存的大小有关。一般情况下，交换分区可以参照下表设置。 物理内存(RAM) 交换分区(Swap Space)
Between 1024 MB and 2048 MB
2 倍 RAM
Between 2049 MB and 8192 MB
1.5倍RAM
More than 8192 MB
1 倍RAM 9.4某一功能特别慢
取故障生产间的两个快照，然后做一个AWR报靠。同时，也可以用第7部分Troubleshooting提供的语句对数据库进行分析。对抓出来的语句进行分析，如果怀疑是统计信息不正确引起的全表扫瞄，可以先进行统计信息的收集，方法如下。否则则可能需要测试索引。具体联系开发人员。 9.5统计信息失效导致执行计划走全表扫瞄
基于Schema的统计信息收集 begin
dbms_stats.gather_schema_stats(ownname => 'HS_FUTURES',
estimate_percent => 20,
method_opt => 'for all indexed columns> cascade => true, degree => 7); end;
基于表的统计信息收集 Analyzetable hs_secu.entrust computestatistics; 9.6关于DRM
环境: 10g，至少HP-UN
现象： 在2007-05-21 14:42:00 左右，管理员发现报盘系统hang住，AS队列上有大量积压，但未登陆到oracle系统查看等待事件，也未作其他的数据库方面的诊断处理。sqlplus正常登陆但比较缓慢。在操作系统层面，节点1的cpu利用率为0，节点2的cpu利用率为20。管理员在反复关闭并重开报盘系统3分钟左右后，系统正常运行。 事后，HP工程师在主机层面查看了相关的日志信息，并未发现什么异常的情况，同时表示无法在现有资源下监控数据库数据线网络的流量。查看了oracle 的相关日志，发现里面有大量的关于DRM 的信息，根据里面的信息，我猜测可能是由于数据库的对象资源动态管理过于频繁，在两个实例之间来回“震荡”时出现异常的缘故。
原因： 由于在oracle的日志和跟踪文件里未能找到与DRM 相关的以外的其他有用信息。根据Oracle 工程师的反馈，可以对DRM 做一些处理。并表示对系统性能并无什么影响。再者，从Oracle的trace文件里可以看出在两次交易故障发生时，oracle rac的DRM 正在做大量的数据同步信息，可查看pdcrac1_lmon_18807.trc。因此，综合以上的各种信息，有必要现在针对DRM方面做一些处理，修改以下初始化参数。
_gc_affinity_time=0 # defines the frequency in minutes tocheck if remastering is needed.
_gc_undo_affinity=FALSE # defines thenumber of times a node must access an object for it to be a DRM candidate
解决方法： 1．备份当前的数据库服务器参数
SQL> Create pfile=’home/oracle/initsid.ora’from spfile;
2．修改备份出来的数据库参数文件，在文件末尾添加
*._gc_affinity_time=0
*._gc_undo_affinity=false 3．shutdown 当前数据库，已刚才备份修改后的数据库参数文件启动到nomount
SQL> Shutdown immediate (两台机)
SQL> Startuppfile=’/home/oracle/initsid.ora’ nomount;
SQL> Create spfile=’/dev/raw/rspfile’ frompfile=’/home/oracle/initsid.ora’; 4．shutdown 当前数据库并重起数据库
SQL> Startup
其它 下面内容是trace文件的部分内容。
kjfcrfg: DRM windowsize = 0->4096 (min lognb = 15)
*** 2007-05-1915:28:08.141
Reconfigurationstarted (old inc 0, new inc 16)
Synchronization timeoutinterval: 900 sec
List of nodes:
0 1
*** 2007-05-1915:28:08.141
Global Resource Directory frozen
node 0
release 10 2 0 2
node 1
release 10 2 0 2
number of mastership buckets = 128
domain attach calledfor domid 0
* kjbdomalc: domain0 invalid = TRUE
* kjbdomatt: firstattach for domain 0
asby init, 0/0/x1
asby returns, 0/0/x1/false
* Domain maps beforereconfiguration:
* DOMAIN 0 (valid 0): 0
* End of domainmappings
* Domain maps afterrecomputation:
* DOMAIN 0 (valid 0): 0 1
* End of domainmappings
Dead inst
Join inst 0 1
Exist inst
Active Sendback Threshold = 50 %
Communication channels reestablished
sent syncr inc 16 lvl 1 to 0 (16,5/0/0)
sent synca inc 16 lvl 1 (16,5/0/0)
received all domreplay (16.6)
sent master 1 (16.6)
sent syncr inc 16 lvl 2 to 0 (16,7/0/0)
sent synca inc 16 lvl 2 (16,7/0/0)
Master broadcasted resource hash value bitmaps
* kjfcrfg: domain 0valid, valid_ver = 16
Non-local Process blocks cleaned out
Set master node info
sent syncr inc 16 lvl 3 to 0 (16,13/0/0)
sent synca inc 16 lvl 3 (16,13/0/0)
Submitted all remote-enqueue requests
kjfcrfg: Number ofmesgs sent to node 1 = 0
sent syncr inc 16 lvl 4 to 0 (16,15/0/0)
sent synca inc 16 lvl 4 (16,15/0/0)
Dwn-cvts replayed, VALBLKs dubious
sent syncr inc 16 lvl 5 to 0 (16,18/0/0)
sent synca inc 16 lvl 5 (16,18/0/0)
All grantable enqueues granted
sent syncr inc 16 lvl 6 to 0 (16,20/0/0)
sent synca inc 16 lvl 6 (16,20/0/0)
*** 2007-05-1915:28:09.638
Submitted all GCS cache requests
sent syncr inc 16 lvl 7 to 0 (16,22/0/0)
sent synca inc 16 lvl 7 (16,22/0/0)
Post SMON to start 1st pass IR
Fix write in gcs resources
sent syncr inc 16 lvl 8 to 0 (16,24/0/0)
sent synca inc 16 lvl 8 (16,24/0/0)
*** 2007-05-19 15:28:12.962
Reconfigurationcomplete
* domain 0 valid?: 1
*** 2007-05-1915:28:18.377
kjxgrtmc2: mountingmember 0 thread 1
Begin DRM(32)
sent syncr inc 16 lvl 9 to 0 (16,0/31/0)
sent synca inc 16 lvl 9 (16,0/31/0)
...
sent syncr inc 16 lvl 39 to 0 (16,0/36/0)
sent synca inc 16 lvl 39 (16,0/36/0)
*** 2007-05-1915:28:28.459
sent syncr inc 16 lvl 40 to 0 (16,0/38/0)
sent synca inc 16 lvl 40 (16,0/38/0)
End DRM(32) 9.7日志文件太小引起的切换过于频繁
假设现有三个日志组，每个组内有一个成员，每个成员的大小为512MB，现在想把此三个日志组的成员大小都改为1G。
创建2个新的日志组 alter database add logfile group 4 ('/oracle/oradata/redo04_1.log')size 1024M;
alter database add logfile group 5 ('/oracle/oradata/redo05_1.log')> 切换当前日志到新的日志组 alter system switch logfile; alter system switch logfile;
删除旧的日志组 alter database drop logfile group 1; alter database drop logfile group 2; alter database drop logfile group 3;
操作系统下删除原日志组1、2、3中的文件
重建日志组1、2、3
alter database add logfile group 1 ('/oracle/oradata/redo01_1.log')>
alter database add logfile group 2 ('/oracle/oradata/redo02_1.log')>
alter database add logfile group 3 ('/oracle/oradata/redo03_1.log')>
切换日志组 alter system switch logfile; alter system switch logfile; alter system switch logfile;
删除中间过渡用的日志组4、5 alter database drop logfile group 4; alter database drop logfile group 5;
到操作系统下删除原日志组4、5中的文件
备份当前的最新的控制文件 SQL> connect internal
SQL>> 9.8Oracle连接中断问题
环境: 10201，AIX53(据ORACLE称，在任何操作系统版本都有此问题)
现象： 监听器启动后，隔一段时间（长短不定），就会出现无法连接： 若是用10201版本的SQLPLUS，则会出现NO LISTENER。 若是用9207 版本的SQLPLUS，则会出现：没反应，HANG住。
原因： 10201 版本上的一个BUG：4518443。其会自动创建一个子监听器，当出现此情况时，监听器将会挂起。 检查是否真因为此BUG造成此现象： $ ps -ef | grep tnslsnr ora10g8909 1 0 Sep 15 ? 902:44 /u05/10GHOME/DBHOME/bin/tnslsnr sales -inherit ora10g22685 8909 0 14:19:23 ? 0:00 /u05/10GHOME/DBHOME/bin/tnslsnr sales -inherit 正常情况只有一个监听器，而此BUG则会出现两个监听器。
解决方法： 打补丁4518443 或者在listener.ora 文件里加入： SUBSCRIBE_FOR_NODE_DOWN_EVENT_=OFF 其中，是数据库的监听器的名称。如： 默认情况下，监听器名为：LISTENER 。则语句就是： SUBSCRIBE_FOR_NODE_DOWN_EVENT_LISTENER=OFF 9.9查询委托返回记录不对
环境: 10g，任何平台
现象： 查询语句结果集返回不全，只返回一条或其中几条。
原因： 未知，怀疑为Oracle Bug
解决方法： 收集相关表的统计信息，如： SQL> Analyze table hs_secu.entrust compute statistics; 如问题仍然存在，使用下面语句： SQL> Analyze table hs_secu.entrust compute statisticsfor all indexes;
其它
这个问题已经多次出现，与很多Oracle售前人员交流过，没有定论。目前怀疑与下面这个Bug相关。具体内容参见metalink：Wrong Results Possibleon 10.2 When New "HASH GROUP BY" Feature is Used（DocID:Note:387958.1）
lCause
Bug4604970 Wrong Results With 'Hash Group By 'Aggregation Enabled
Any query that displays "HASH GROUP BY" in theexecution plan could hit this bug.
The "HASH GROUP BY" feature is enabled by defaultin 10.2.
lSolution
Patch 4604970 can be downloaded from Metalink for mostplatforms .
Problem is resolved in latest Patchset> Workaround:
Increase the memory used by hash group by
Or
Disable the use of hash group by
eg: set optimizer_features_enable to "10.1.0"
or
set "_gby_hash_aggregation_enabled" to FALSE. 9.10Linux + Oracle 10gRAC的平台上，发生节点重启故障
环境:
l服务器硬件平台： - HP DL580 G4 4CPU（双核）16G内存 - IBM 3950 4CPU（双核）16G内存
l操作系统平台： - Redhat Linux AS 4 Update4 64bit
l数据库系统： - Oracle 10g R2(10.2.0.1)RAC (有2节点的，4节点的)
现象： 其中某一结点操作系统重启。经典场景：前一日清算到资金清算汇总时rac节点2自动重启，次日9:10 rac节点1死机，冷启动后恢复正常。
lALERT.LOG日志
Mon Jun 11 16:54:38 2007
Error: unexpected error (6) from the Cluster Service (LCK0)
Mon Jun 11 16:54:38 2007
Errors in file/u01/app/oracle/admin/rac/bdump/rac1_lck0_9207.trc:
ORA-29702: error occurred in Cluster Group Service operation
Mon Jun 11 16:54:38 2007
Errors in file/u01/app/oracle/admin/rac/bdump/rac1_lms3_9100.trc:
ORA-29702: error occurred in Cluster Group Service operation
Mon Jun 11 16:54:38 2007
Errors in file /u01/app/oracle/admin/rac/bdump/rac1_lms0_9088.trc:
ORA-29702: error occurred in Cluster Group Service operation
Mon Jun 11 16:54:38 2007
Errors in file/u01/app/oracle/admin/rac/bdump/rac1_lmd0_9086.trc:
ORA-29702: error occurred in Cluster Group Service operation
Mon Jun 11 16:54:38 2007
Errors in file/u01/app/oracle/admin/rac/bdump/rac1_psp0_9082.trc:
ORA-29702: error occurred in Cluster Group Service operation
Mon Jun 11 16:54:38 2007
System state dump is made for local instance
Mon Jun 11 16:54:38 2007
Errors in file /u01/app/oracle/admin/rac/bdump/rac1_j000_12310.trc:
ORA-29702: error occurred in Cluster Group Service operation
Mon Jun 11 16:54:38 2007
Errors in file/u01/app/oracle/admin/rac/bdump/rac1_pmon_9078.trc:
ORA-29702: error occurred in Cluster Group Service operation
Mon Jun 11 16:54:38 2007
Errors in file/u01/app/oracle/admin/rac/bdump/rac1_lms2_9096.trc:
ORA-29702: error occurred in Cluster Group Service operation
Mon Jun 11 16:54:38 2007
Errors in file/u01/app/oracle/admin/rac/bdump/rac1_lms1_9092.trc:
ORA-29702: error occurred in Cluster Group Service operation
Mon Jun 11 16:54:38 2007
Errors in file/u01/app/oracle/admin/rac/bdump/rac1_arc1_9345.trc:
ORA-29702: error occurred in Cluster Group Service operation
Mon Jun 11 16:54:38 2007
Errors in file /u01/app/oracle/admin/rac/bdump/rac1_arc1_9345.trc:
ORA-29702: error occurred in Cluster Group Service operation
SystemState dumped to tracefile /u01/app/oracle/admin/rac/bdump/rac1_diag_9080.trc
Mon Jun 11 16:54:38 2007
LCK0: terminating instance due to error 29702
lOCSSD.LOG
[CSSD]2007-06-11 16:54:35.377 [1147169120] >ERROR: clssnmDiskPMT: 3 of 3 voting disksunavailable (0/0/3)
[CSSD]2007-06-11 16:54:35.380 [1157658976] >TRACE: clssnmHandleSync: Acknowledging sync: src[2]srcName[tdb12] seq[13] sync[29]
[CSSD]2007-06-11 16:54:35.380 [1157658976] >TRACE: clscsendx: (0x2a97c1df40)Physical connection (0x2a97c35080) not active
[CSSD]2007-06-11 16:54:35.381 [1157658976] >WARNING:clssnmsendmsg: send failed, node 2, type 11, rc 10
原因： 未知，怀疑为Oracle Bug，但是把SGA调小可使此问题消失。
解决方法： 问题原因还在追踪，METALINK上并没有找到针对性的BUG或解决方案，怀疑是linux平台下Oracle对SGA管理的问题，很可能是个Bug，应该说SGA调小只是针对故障的临时解决方案。最终原因，将会在下一阶段测试新的版本10.2.0.3来确认。目前如果发生此问题，需要把SGA调到6G以下，下面为修改方法：
l调整linux内核参数，编辑/etc/sysctl.conf文件修改以下内容 kernel.threads-max = 131072 fs.file-max = 131072 编辑上面内容保存退出后，执行sysctl –p使参数生效。
l调整sga大小
SQL>>
SQL>> 然后按正常方式重启数据库。 9.11联机日志损坏
非当前日志损坏(已归档) Alter database clear logfile group n来创建一个新的日志文件
非当前日志损坏(未归档) Alter database clear unarchived logfile group n
如果是当前日志损坏，一般不能clear，否则可能意味着丢失数据 如果有备份，可以采用备份进行不完全恢复 如果没有备份，可能只能用_allow_resetlogs_corruption=true来进行强制恢复了，但是，这样的方法是不建议的，容易导致数据字典不一致，一般这样打开以后要进行全库备份，再重新建库导数据 9.12控制文件损坏
1、损坏单个控制文件 关闭数据库，拷贝一个好的文件覆盖掉即可；或者是修改init.ora文件的相关部分
2、损失全部控制文件， 创建控制文件或从备份恢复创建控制文件的脚本可以通过alter database backup controlfile to trace获取。 9.13ORA-01555错误
环境: 任何平台
现象： 报ORA-01555错。
发生地点：
原因： 读一致性引起，一般是由于以下原因造成： 1、UNDO太小 2、9i 里的UNDO_RETENTION参数设置太小，导致已经提交事务在UNDO里快速被覆盖 3、查询语句效率太低
解决方法： 1、适当加大UNDO表空间 2、加大UNDO_RETENTION参数 3、调整应用程序，提交查询的效率
其它 9.14HP Proliant DL585G2机器安装
HP Proliant DL585G2 机器安装RHEL AS4时可能出现的操作系统检测不到网卡，还有插在PCI1和PCI2槽上的两块FCA2214 HBA卡也没有被检测出的情况的处理
解决方法： Linux 安装完成后，在/etc/grub.conf文件中，修改启动系统的引导项，增加参数"pci=nommconf"，如： kernel /vmlinuz-2.6.9-55.0.0.0.2.ELsmpro root=LABEL=/ rhgb "pci=nommconf" quiet 用网络图形配置工具“New”一个新的设备。
QQ群⑧：
窥视卡
雷达卡
发表于 2018-9-12 09:10:08
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡