下载文档原格式
ORACLE 数据库故障解决方案一、背景介绍ORACLE是一种常用的关系型数据库管理系统，广泛应用于企业级应用中。
然而，在使用ORACLE数据库的过程中，可能会遇到各种故障问题，如数据库无法启动、数据丢失、性能下降等。
为了保证数据库的稳定运行和高效性能，需要及时解决这些故障问题。
二、故障解决方案1. 数据库无法启动- 检查数据库实例是否正常运行，可以使用SQL*Plus连接到数据库实例并执行"SELECT INSTANCE_NAME, STATUS FROM V$INSTANCE;"命令来检查实例状态。
- 如果实例状态为"STARTED"，则说明实例正常运行，可以尝试重启数据库。
- 如果实例状态为"SHUTDOWN"，则需要尝试启动数据库实例。
可以使用SQL*Plus执行"STARTUP"命令来启动数据库实例。
- 如果启动失败，可以检查数据库日志文件中的错误信息，通常位于$ORACLE_HOME/rdbms/log目录下，根据错误信息进行故障排查和修复。
2. 数据丢失- 数据丢失可能是由于误删除、意外断电等原因导致的。
- 针对误删除数据的情况，可以使用RMAN（Recovery Manager）工具进行数据恢复。
RMAN可以从备份中恢复丢失的数据。
- 针对意外断电等原因导致的数据丢失，可以尝试使用闪回技术进行数据恢复。
闪回技术可以在不需要备份的情况下，将数据库恢复到指定的时间点。
- 如果以上方法无法解决数据丢失问题，可以考虑使用专业的数据恢复工具或者咨询ORACLE技术支持。
3. 性能下降- 数据库性能下降可能是由于查询语句优化不足、索引失效、硬件资源不足等原因导致的。
- 针对查询语句优化不足的情况，可以使用SQL调优工具（如SQL Tuning Advisor）来分析和优化查询语句，提高查询性能。
- 针对索引失效的情况，可以使用索引重建工具（如Index Rebuild）来重新构建索引，提高查询性能。
ORACLE 数据库故障解决方案一、引言在进行数据库管理和维护过程中，不可避免地会遇到各种故障和问题。
本文将介绍针对ORACLE数据库常见故障的解决方案，包括数据库无法启动、数据丢失、性能下降等问题的解决方法。
二、数据库无法启动的解决方案1. 检查数据库实例是否正常运行。
可以使用SQL*Plus或者Oracle Enterprise Manager来连接数据库实例，确认实例是否处于正常运行状态。
如果实例没有启动，可以使用启动命令来启动实例。
2. 检查数据库监听器是否正常运行。
监听器负责接收客户端的连接请求并将其转发给数据库实例。
如果监听器没有启动，可以使用监听器启动命令来启动监听器。
3. 检查数据库参数设置是否正确。
可以通过查看数据库参数文件或者使用SQL*Plus连接数据库实例并执行"show parameter"命令来查看数据库参数设置。
如果参数设置不正确，可以使用ALTER SYSTEM命令来修改参数设置。
4. 检查数据库日志文件。
数据库日志文件中记录了数据库的运行状态和错误信息。
可以通过查看数据库日志文件来了解数据库启动失败的原因，并根据错误信息采取相应的解决措施。
三、数据丢失的解决方案1. 恢复备份数据。
如果数据库存在备份，可以使用备份数据来恢复丢失的数据。
可以使用Oracle Recovery Manager（RMAN）工具来进行备份和恢复操作。
2. 使用闪回技术。
ORACLE数据库提供了闪回技术，可以将数据库恢复到指定的时间点或者指定的事务之前的状态。
可以使用闪回查询（Flashback Query）或者闪回表（Flashback Table）来恢复丢失的数据。
3. 使用日志文件进行恢复。
ORACLE数据库的日志文件中记录了数据库的所有操作，可以使用日志文件进行数据恢复。
可以使用日志文件恢复（Redo Log Recovery）或者逻辑恢复（Logical Recovery）来恢复丢失的数据。
HANGANALYZE EventHANGANALYZE事件在分析系统挂住的时候很有用，尤其是会话(session)因为锁的原因挂住的时候。
用法：SQL>alter session set events 'immediate trace name HANGANALYZE level 4';Trace File:Trace file位于udump目录下，文件名可根据文件的生成时间来确定，或者用下面的脚本。
SQL>select spid from v$processwhere addr=(select paddr from v$sessionwhere sid=(select sid from v$mystatwhere rownum<2));比如例子中的文件ut12sup1_ora_14862.trc，其中14682就是spid的值。
分析：Dump file /u40/UT12SUP1/db/tech_st/10.2.0/admin/UT12SUP1_uhddb01/udump/ut12sup1_ora_14862. trcOracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bit ProductionWith the Partitioning, OLAP and Data Mining optionsORACLE_HOME = /u40/UT12SUP1/db/tech_st/10.2.0System name: SunOSNode name: uhddb01Release: 5.10Version: Generic_118833-23Machine: sun4uInstance name: UT12SUP1Redo thread mounted by this instance: 1Oracle process number: 23Unix process pid: 14862, image: oracle@uhddb01 (TNS V1-V3)*** SERVICE NAME:(SYS$USERS) 2009-06-03 10:05:18.102*** SESSION ID:(373.3606) 2009-06-03 10:05:18.102*** 2009-06-03 10:05:18.102==============HANG ANALYSIS:==============Open chains found:会话SID=1185在等待1188Chain 1 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :<0/1188/1236/0xe100f590/14813/SQL*Net message from client>-- <0/1185/1177/0xe10134d0/14825/enq: TX - row lock contention>Other chains found:Chain 2 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :<0/336/4555/0x620134d0/14955/read by other session>Chain 3 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :<0/341/3637/0x62013cb8/14961/read by other session>……验证：SQL> select sid,username, status,event from v$session where sid in (1188,1185);SID USERNAME STATUS EVENT---------- ------------------------------ -------- ---------------------------------------------------------------- 1185 SYSTEM ACTIVE enq: TX - row lock contention1188 SYSTEM INACTIVE SQL*Net message from client关于HANGANALYZE Event：The level determines which processes are asked to dump an errorstack. The main levels are:10 => Dump all processes (voluminous data output, not a good idea)5 => Dump all processes involved in wait chains (can still produce a lot of output)4 => Dump leaf nodes in wait chains3 => Dump only processes thought to be in a hang situation2 => Minimal output1 => Very minimal output如果选择的level越高，除了更多的进程会包括近来外，trace的信息也会更多。
ORACLE 数据库故障解决方案故障解决方案是指在出现故障时，为了恢复系统正常运行，采取的一系列措施和方法。
针对ORACLE数据库故障，我们可以提供以下解决方案：1. 故障现象描述：描述故障的具体现象，如数据库无法启动、访问速度变慢等。
2. 故障排查：2.1 检查日志文件：查看ORACLE数据库的日志文件，如alert日志、trace文件，以了解故障的具体信息和错误提示。
2.2 检查数据库状态：使用SQL*Plus或其他管理工具连接到数据库，执行`SELECT STATUS FROM V$INSTANCE;`命令，检查数据库的状态是否正常。
2.3 检查系统资源：查看服务器的CPU、内存、磁盘等资源使用情况，确认是否存在资源瓶颈导致数据库故障。
2.4 检查网络连接：检查数据库服务器与客户端之间的网络连接是否正常，确认是否存在网络故障导致数据库无法访问。
3. 故障解决：3.1 数据库无法启动：3.1.1 检查数据库参数文件是否正确配置。
3.1.2 检查数据库控制文件是否损坏，如损坏则恢复备份的控制文件。
3.1.3 检查数据库日志文件是否损坏，如损坏则恢复备份的日志文件。
3.1.4 检查数据库是否处于ARCHIVELOG模式，如果是，则尝试进行日志应用恢复。
3.2 数据库访问速度变慢：3.2.1 检查数据库的索引是否正常，如有需要，重新构建索引。
3.2.2 检查数据库的统计信息是否准确，如有需要，重新收集统计信息。
3.2.3 检查数据库的SQL语句性能，如有需要，进行SQL调优。
3.2.4 检查数据库的表空间是否过度使用，如有需要，进行表空间的优化和扩容。
4. 故障预防：4.1 定期备份数据库：按照业务需求和数据变更频率，制定合理的数据库备份策略，并定期执行数据库备份操作。
4.2 监控数据库性能：使用数据库性能监控工具，实时监测数据库的性能指标，如CPU、内存、磁盘、网络等，及时发现潜在的故障风险。
4.3 定期维护数据库：定期执行数据库的维护操作，如索引重建、统计信息收集、日志清理等，保持数据库的良好状态。
Oracle数据库常见异常的诊断方法对于系统级异常，可以采取以下诊断方法：1. 检查日志文件：Oracle数据库记录了大量的日志信息，包括错误日志（alert log）、故障诊断日志（trace files）等。
通过查看这些日志文件，可以了解系统执行过程中的异常情况，定位问题发生的时间和位置。
2. 查看系统表和视图：Oracle数据库提供了一系列用于监控系统的表和视图，包括v$session、v$session_event、v$session_wait等。
通过查询这些系统表和视图，可以获取当前会话的状态和等待事件，从而确定系统出现异常的原因。
3. 检查系统资源使用情况：Oracle数据库提供了一系列用于监控系统资源使用情况的视图，包括v$sysstat、v$sesstat、v$system_event 等。
通过查询这些视图，可以了解数据库的活动会话数、CPU利用率、I/O等待等情况，从而评估系统资源的使用情况。
对于SQL级异常，可以采取以下诊断方法：1. 分析执行计划：Oracle数据库可以生成SQL执行计划，用于指导优化器选择最优的执行方案。
通过分析执行计划，可以了解SQL查询的执行顺序、操作方式和数据访问路径等信息，进而确定是否存在性能问题。
2. 使用SQL Trace：Oracle数据库提供了SQL Trace功能，可以详细记录SQL语句的执行过程，包括SQL的执行时间、CPU消耗、I/O操作等。
通过分析SQL Trace文件，可以找到SQL执行过程中的异常情况，如高CPU使用率、大量的物理读写等。
3. 检查索引使用情况：索引是提高SQL查询性能的重要手段，但是过多或者过少的索引都可能引起性能问题。
通过查询v$segment_statistics视图，可以了解各个表和索引的物理I/O操作次数和等待次数，从而判断是否存在索引使用不当的问题。
4. 检查锁定和等待：Oracle数据库提供了一系列用于监控数据库锁定和等待的视图，包括v$lock、v$lock_wait、v$session等。
ORACLE 数据库故障解决方案一、引言在使用ORACLE数据库过程中，可能会遇到各种故障问题，如数据库无法启动、数据损坏、性能下降等。
本文将针对这些常见的故障问题提供解决方案，帮助用户快速恢复数据库的正常运行。
二、数据库无法启动的解决方案1. 检查数据库参数设置：确认数据库参数是否正确配置，包括SGA大小、日志文件大小、内存分配等。
2. 检查数据库文件完整性：使用DBVERIFY工具检查数据库文件的完整性，如果发现文件损坏，可以使用RMAN工具进行恢复。
3. 检查数据库监听器状态：确认数据库监听器是否正常运行，可以使用lsnrctl命令查看监听器状态，并进行必要的重启操作。
4. 检查数据库日志文件：查看数据库日志文件，寻找可能导致数据库无法启动的错误信息，并根据错误信息进行相应的处理。
三、数据损坏的解决方案1. 使用RMAN工具进行数据恢复：RMAN是ORACLE提供的备份和恢复工具，可以使用RMAN进行数据恢复操作。
首先需要创建一个可用的备份，然后使用RMAN进行数据恢复。
2. 使用数据泵进行数据导出和导入：如果无法使用RMAN进行数据恢复，可以考虑使用数据泵工具进行数据导出和导入操作。
首先将损坏的数据库导出为一个可用的数据文件，然后再将数据导入到新的数据库中。
3. 使用逻辑备份进行数据恢复：如果没有可用的物理备份，可以考虑使用逻辑备份进行数据恢复。
逻辑备份是指将数据库的逻辑结构导出为SQL语句，并通过执行这些SQL语句来恢复数据库。
四、性能下降的解决方案1. 优化SQL语句：通过分析数据库的执行计划，找出影响性能的SQL语句，并进行优化。
可以使用ORACLE提供的SQL调优工具，如SQL Tuning Advisor和SQL Access Advisor。
2. 增加硬件资源：如果数据库负载过高，可以考虑增加硬件资源，如增加CPU、内存或存储空间等，以提高数据库的性能。
3. 重新设计数据库结构：如果数据库的表结构设计不合理，可能会导致性能下降。
ORACLE 数据库故障解决方案故障解决方案是指在出现故障时，通过一系列的步骤和方法来解决问题，恢复系统的正常运行。
针对ORACLE数据库故障，下面将提供一种标准的解决方案，希望对您有所帮助。
1. 故障描述：在使用ORACLE数据库时，出现了无法连接数据库的故障，无法进行正常的数据操作和查询。
2. 故障原因分析：（根据实际情况进行分析，以下为示例）可能的原因有：- 数据库服务未启动- 数据库实例崩溃- 数据库表空间不足- 数据库连接配置错误3. 解决方案：以下是一种解决ORACLE数据库故障的标准方案，您可以根据具体情况进行调整和执行。
步骤一：检查数据库服务状态1. 打开命令行窗口，输入命令`lsnrctl status`，查看数据库监听器的状态。
2. 如果监听器状态正常，继续执行下一步；如果监听器未启动，使用命令`lsnrctl start`启动监听器。
步骤二：检查数据库实例状态1. 打开命令行窗口，输入命令`sqlplus / as sysdba`，以管理员身份登录数据库。
2. 输入命令`select status from v$instance;`，查看数据库实例的状态。
3. 如果数据库实例状态正常，继续执行下一步；如果数据库实例未启动，使用命令`startup`启动数据库实例。
步骤三：检查数据库表空间1. 打开命令行窗口，输入命令`sqlplus / as sysdba`，以管理员身份登录数据库。
2. 输入命令`select tablespace_name, sum(bytes)/1024/1024 as total_size,sum(bytes)/1024/1024 - sum(bytes_free)/1024/1024 as used_size from dba_data_files group by tablespace_name;`，查看数据库表空间的使用情况。
3. 如果表空间使用率过高，可以考虑进行表空间的扩容或清理操作。
ORACLE数据库常见问题诊断方法（分布式事务篇）对于数据库服务端到服务端的访问（如DBLINK、复制、快照等），由于网络等原因可能会产生一个节点的事务无法恢复，与之相关的另一个节点的数据库事务挂起，因而产生分布式数据库事务问题。
一、诊断分布式事务1）检查alert<sid>.log文件，发现相应的错误确保网络正常，并检查DBLINK是”valid”和可操作的2）SELECT * FROM V$DBLINK 或GV$DBLINGK3）查找悬挂的事务（ DBA_2PC_PENDING）SELECT LOCAL_TRAN_ID, GLOBAL_TRAN_ID, STATE, MIXED, HOST, COMMIT#FROM DBA_2PC_PENDINGLOCAL_TRAN_ID 是本机的事务号（报告错误的机器），如果 LOCAL_TRAN_ID = GLOBAL_TRAN_ID, 即分布式事务来源于本机，也可以从本机的alert<sid>.log中得到 LOCAL_TRAN_ID 。
二、检查其它节点的事务（DBA_2PC_NEIGHBORS）1）执行下列命令：SELECT LOCAL_TRAN_ID, IN_OUT, DATABASE, INTERFACEFROM DBA_2PC_NEIGHBORS2）在init<sid>.ora中检查参数COMMIT_POINT_STRENGTH该参数应有较大值（最好最大值）三、通过DBA_2PC_PENDING字典表检查事务的状态1）如果状态是 commit，则本地数据库提交成功，即不必在本数据库实施COMMIT FORCE或ROLLBACK FORCE。
如果状态是 not commited（prepared），则必需在本数据库实施COMMIT FORCE或ROLLBACK FORCE，SCN号可在DBA_2PC_PENDING字典表中找到。
ORACLE 数据库故障解决方案一、概述ORACLE 数据库是一种关系型数据库管理系统，广泛应用于企业级应用中。
然而，在使用过程中，可能会遇到各种故障情况，例如数据库无法启动、数据丢失、性能下降等。
为了保证数据库的稳定运行，需要及时解决这些故障。
本文将介绍一些常见的 ORACLE 数据库故障解决方案。
二、数据库无法启动1. 检查数据库实例是否正常启动。
使用命令 `ps -ef | grep pmon` 查看数据库实例进程是否存在。
如果不存在，可能是由于数据库实例未正常启动导致的故障。
解决方案：使用 `sqlplus / as sysdba` 命令登录到数据库，执行 `startup` 命令启动数据库实例。
2. 检查数据库控制文件是否损坏。
控制文件是 ORACLE 数据库的重要组成部份，记录了数据库的结构信息。
如果控制文件损坏，数据库将无法启动。
解决方案：使用 `ls -l` 命令检查控制文件的状态。
如果控制文件状态为`MISSING` 或者 `OFFLINE`，则需要恢复控制文件。
可以使用备份的控制文件替换损坏的控制文件，并执行 `startup` 命令启动数据库。
三、数据丢失1. 检查数据库备份情况。
数据库备份是防止数据丢失的重要手段。
如果数据库备份完备，可以通过备份文件进行数据恢复。
解决方案：使用 `rman` 工具进行数据库恢复。
首先，使用 `list backup` 命令查看备份文件的信息。
然后，使用 `restore database` 命令恢复数据库。
2. 检查数据文件是否损坏。
数据文件是 ORACLE 数据库中存储数据的文件。
如果数据文件损坏，可能导致数据丢失。
解决方案：使用 `select file#, name, status from v$datafile;` 命令检查数据文件的状态。
如果数据文件状态为 `RECOVER`，则需要进行数据恢复。
可以使用备份的数据文件替换损坏的数据文件，并执行 `recover datafile <file#>` 命令进行数据恢复。
Oracle 10.2.0.1 数据库hang住Bug 4612267分类：Oracle 故障解决案例2011-07-08 11:28 132人阅读评论(0) 收藏举报一. Bug问题表现CPU使用率100%，vmstat 显示有大量等待运行的进程，有大量的上下文切换。
sqlplus 和lsnrctl 命令无效。
数据基本是hang住了。
啥都不能用。
该bug 存在与Oracle 10.2.0.1.1.1 Top 显示top - 04:46:06 up198 days, 22:05, 5 users, load average: 16.20, 16.63, 21.22tasks: 112 total, 19 running, 93 sleeping, 0 stopped, 0 zombiecpu(s): 26.3%us, 73.0%sy, 0.0%ni, 0.6%id, 0.0%wa, 0.0%hi, 0.1%si, 0.0%stmem: 4026344k total, 3255488kused, 770856k free, 279252k buffersswap: 4192924k total, 369088kused, 3823836k free, 2835992k cached结合网上google的结果，该bug 对cpu 表现是。
用户使用30%左右，系统使用70%。
系统启动198天，会触发这个bug。
解决这个问题一是升级数据库，二是定期重启操作系统。
Linux Top 命令详解/tianlesoftware/article/details/61977831.2 vmstat 命令[root@localhost ~]# vmstat 2procs -----------memory---------- ---swap-------io---- --system-- -----cpu------r b swpd free buff cache si so bi bo in cs us sy id wa st36 0 369092 503308 2481042815564 1 1 31 5 0 0 1 1 97 1 036 0 369092 503308 2481042815600 0 0 0 10 1047 237 26 74 0 0 038 0 369092 503308 2481042815600 0 0 0 0 1045 232 25 75 0 0 0...--这里r 表示等待运行的进行，一般小于cpu的个数。
确定当前数据库是否是真的hanging还是处于活动状态但是运行的非常慢?检查下在Alert文件中是否还有日志切换，检查当前的CPU，I/O，内存的利用率。
将讨论如下的诊断步骤：1) 描述清楚出现的现象问题2) 寻找具体错误3) 收集操作系统级别上的数据4) 获取systemstate和hanganalyze的dump5) 获取STATPACK的输出报告6) 获取PROCESSSTATE的dump注：可能很多时候没有必要关闭数据库来停止hanging，建议如果要关闭数据库之前获取这些诊断信息以便找出错误的原因所在。
下面就来具体讨论如何诊断数据库Hanging问题。
描述清楚出现的现象问题：先弄清楚运行的数据库版本，需要完整的版本号，例如9.2.0.4。
确定当前数据库是否是真的hanging还是处于活动状态但是运行的非常慢?检查下在Alert文件中是否还有日志切换，检查当前的CPU，I/O，内存的利用率。
查看数据库hanging的开始时间，持续了多长时间?数据库hanging是否是突然发生还是由于增加的活动事务导致性能的逐步降低?当前有多少的连接用户?最近的系统负载是否是在上升?是否在初始化参数文件中设置了任何event?数据库当前正在做什么类型的事务?数据库的数据量多大?数据库是运行在集群环境吗?如果是集群数据库，那么关闭其他实例就留下一个实例，问题是否还持续存在?这里讨论的某些解决方法适用于集群数据库，但是大部分的方法不适合。
例如，一个不大的buffer cache通常对于集群数据库来说意味着较好的性能。
关于集群数据库的大部分hanging的问题这里不做讨论，其中包括PCM锁问题，pinging，空间管理问题，节点间并行查询调优，共享磁盘或者虚拟共享磁盘问题，网络问题，DLM问题等。
数据库是运行在MTS环境下吗?如果取消MTS，是否问题持续存在?是否使用了Oracle的应用或者工具?最近是否升级了数据库，应用，工具或者操作系统，硬件?问题发生的频率?是否能够重现问题?是否整个数据库都被hanging?所有的实例?所有的连接?所有的操作?所有的节点?首先确认是否能够执行查询select * from dual?日志文件多久切换一次?如果在Alert日志中有归档相关的错误信息，那么可以着手解决归档错误问题，因为归档问题经常会挂起数据库。
例如：归档目的地空间满了，或者数据库处于归档模式下但是ARCH进程被停止了。
一般可以先以sysdba权限连接到数据库中，执行ARCHIVE LOG LIST，查看数据库是否归档模式，是否启用了自动归档，一般如果没有启用自动归档，就很容易挂起数据库了，这个时候通常的做法就是把数据库改成自动归档模式或者是非归档模式一个指定的SQL语句操作?1) 如果是由于指定的SQL语句导致数据库挂起，先执行带有timed_statistics参数的TKPROF输出报告以及SQL语句的执行计划，然后就需要分SQL语句类型来分析了：2) 如果是select语句，那么这个SQL语句应该是需要被调整，如果是一个非常复杂的SQL语句，那么尝试是否可以中断。
3) 如果是一个并行查询语句，可以参考监控当前并行查询运行状况脚本获得并行查询的执行计划。
可能是空间事务竞争，如果在Alert日志文件中出现ORA-1575错误，那么请将临时表空间的参数pct_increase 设置为0以便禁止SMON进程接合连续的extents，因此减少查询slaves的竞争。
同时将数据文件尽量分散到不同的磁盘上去，减少磁盘I/O的竞争，适当增加sort_area_size的大小可能会‘减少’并行度。
4) 如果是DML语句，那么可能是由于锁导致的，需要去获取v$lock的输出信息，关于锁的信息可以参考返回锁信息脚本。
查看DML语句的对象上是否有限制或者触发器，有可能产生级联锁问题。
把索引建立在相关的外键列上，这样会改变在父表上的锁行为。
5) 如果是DDL语句，可能是一个数据字典的相关问题。
如果是create index语句则可能是一个空间事务竞争问题。
调整I/O是一个比较好的方法，分布式I/O，分开索引和数据的存放空间，并行执行都是比较有用的方法，还可以设置初始化参数pre_page_sga为true。
指定的数据库对象?在指定对象能是否能做任何操作?做一个select count(*)是否有问题?如果只是update该对象存在问题，那么可能锁了，可以从上面3)、4)中的脚本获取锁的信息。
是否预先分配好了空间给这个对象?如果是，那么将提高HWM并且导致全表扫描，以至于让数据库看起来像是“挂起”了。
全表扫描总是会扫描HWM，即使表只存在很少的数据。
解决方案就是尽量避免预分配extents除非马上要执行一个大的并行插入或者常规的装载。
千万不要在直接装载的时候预分配extents。
如果对象是一个表，那么可以尝试ANALYZE TABLE VALIDATE STRUCTURE CASCADE;是否有报错，如果有报错，意味着表或者表上的索引存在坏块了。
如果没有报错，那么继续尝试下面的SQL语句得到相应的的信息：块级上的空间信息，一个高的chain out，也可能是问题的一部分。
SELECT *FROM sys.dba dba_tablesWHERE table_name = '<TABLENAME>';如果你有很多的更新和删除操作，那么一个不适合的索引也会造成问题，下面的SQL语句能帮你得到相关的索引信息：SELECT i.*FROM sys.index_stats i, sys.dba_indexes dWHERE = d.index_nameAND d.table_name = '<TABLENAME>';SELECT i.*FROM sys.index_stats i, sys.dba_indexes dWHERE = d.index_nameAND d.table_name = '<TABLENAME>';如果是一个视图，那么需要查看视图建立在的表的信息：SELECT textFROM sys.dba_viewsWHERE view_name = '<VIEWNAME>';大规模的更新操作(例如使用SQLLDR，IMPORT或者批处理操作)?这些操作上的表上存在有哪些索引?是否这些更新操作是在数据库高峰时期运行的?是否在Alert文件中存在有"checkpoint not complete"的错误信息?如果有表明重做日志文件太小了，需要调整它们。
是否表空间被置于在热备模式下?(v$backup)如果表空间处于热备模式，那么产生日志”records”而不是“vectors”,在一个大的更新操作中，就可能导致相当多的竞争和性能下降。
如果是一个SQLLDR操作，是否使用了传统路径方式?是否使用了REPLACE选项?(推荐使用TRUNCATE 选项)在SQLLDR的控制文件中是否有sql functions?是否采用了readbuffers，bindsize，rows，parallele方式?如果是一个IMPORT操作，是否使用了commit=y，indexes=y，constraints=y这些参数?是否增大了buffer?如果在update期间，有很多的用户在操作，那么容易造成资源竞争，导致系统变慢。
回滚段，redo latches, i/o和数据缓冲区都可能成为竞争的区域。
我们可以从V$session_wait以及statpack中获取更多关于具体竞争的相关信息。
指定的包，存储过程或者PRO*C应用?首先需要查看这些包，存储过程或者PRO*C的具体内容，其中的哪个语句一直在执行?去掉这个语句后相应的程序是否能运行正常?如果是存储过程，那么可以利用DBMS_ALERT查看那里开始挂起了。
如果是PRO*C程序，那么可以使用tkprof来识别”parsing”是否是瓶颈?如果是，那么可以使用预编译参数hold_cursor和release_cursor来调整。
如果是一个包，那么尝试是否能单独执行每个存储过程?查看是否包和存储过程被刷新出了共享池，如果是，可以尝试把这些包和存储过程pin在共享池中。
SELECT *FROM v$db_object_cacheWHERE name = '<NAME>';仅仅是远程访问?是否可以执行select * from dual@db_link?是否能够连接到远程的机器上执行本地的操作?是否是在做一个分布式的更新操作?初始化参数distributed_lock_timeout设置了多少?是否正在刷新快照?是否使用了对称复制?尝试做一个tkprof输出得到相应的执行计划，执行计划中如果标明是REMOTE的，那么就是远程执行的操作。
如果在一个远程的机器上join两张表，那么请尝试在本地节点上生成join视图之后，查询这个视图。
在sql操作中设置ARRAYSIZE，多使用pl/sql而不是单独的sql语句，使用显性游标这些都可以减少网络的负载。
使用第三方应用软件的操作是否能在sqlplus中重现问题?如果不可以重现，那么就需要联系第三方应用软件供应商寻求帮助数据关闭/启动过程中出现挂起关闭使用的什么参数?数据库是否crash了?如果是数据库启动挂起并且非正常关闭，但是在Alert日志文件中没有任何的错误，那么可能只是一个正常的实例恢复，如果在Alert文件中出现内部错误，系统错误，那么请尝试正常的关闭数据库然后启动。
下面是一个正常实例恢复的时候在Alert日志文件中列出的相关信息：Starting ORACLE instance (normal)…………………Starting up ORACLE RDBMS Version: 10.2.0.1.0.System parameters with non-default values:……………………Beginning crash recovery of 1 threadsStarted redo scanCompleted redo scan120 redo blocks read, 46 data blocks need recoveryRecovery of Online Redo Log: Thread 1 Group 2 Seq 143 Reading mem 0Completed redo applicationCompleted crash recovery atThread 1: logseq 143, block 4358, scn 51269946 data blocks read, 46 data blocks written, 120 redo blocks readSMON: enabling cache recoverySMON: enabling tx recoveryCompleted: ALTER DATABASE OPEN如果正常的关闭或者immediate关闭挂起，那么意味着Oracle正在等待激活的会话退出。
