数据库常问的两个问题看看专家们怎么答

1。 如果用户告诉你，程序突然慢了，该如何着手……

A:  向问题提出者提出以下问题:

　　1 是否经做过数据库对象的分析 -->dba_tables(last_analyze)

　　2 是否经历过批量dml操作 -->(影响执行计划)

　　3 是否经历过数据库版本升级 -->(新的bug?)

　　4 用操作系统命令查看磁盘I/O是否异常,当然还有网络是否被其他资源占用 (硬件故障)

　　5 是不是有新的应用上线

　　6 有没有抱错信息 (如果有抱错信息可以缩小故障范围)

B:

        1、查看客户端进程，确认是否客户端本身有病毒或程序有问题

　　2、查看服务器进程/线程运行情况

　　3、如果服务器不正常，找到相应进程/线程，kill

C:

        首先要关注应用服务器&数据库服务器的性能。查看cpu IO等性能指标。

　　如果是应用服务器性能出现问题，那么可以尝试调整应用服务器。

　　如果是数据库服务器，那么在没有对数据库进行其他操作的前提下80%恐怕都是sql语句引起的性能上的问题，那么需要系统中通过相关命令(vmstat，top，topas等)那些进程占用大量的资源。在数据库中查看v$session_wait，v$process，v$sql_text等查看等待事件，然后获得sql语句，进行适当的调整(explain plan或者sql_trace)达到解决目的。

　　也可以通过得到一个15-30minutes的statpack判断数据库的情况。

D:

        (1)检查alter.log看有什么信息可以参考;

　　(2)在OS一级检查系统,如用vmstat,iostat,sar,top,ps等工具检查系统的性能,

　　特别注意CPU,IO,Memory的使用情况;

　　(3)查看v$session_wait看看系统在等待什么资源;

　　至此应该可以判断出是出了什么问题,然后对症下命令/SQL

E:

        OS top 一下 , 找到相应session , v$session_wait , SQL 等

　　如果 top 不明显，会看看 vmstat , swap , iostat , netstat 等……

　　如果还不行，找出变慢的session , 有必要的话trace 一下

　　不是太紧急的话，作statspack , 分析

F:

        登录服务器top一下，看系统压力大不， v$session_wait检查出现了什么等待。 跟踪程序看正在执行什么语句，执行计划是否发生变化。

2。 如果用户告诉你，程序突然无法连到database，该如何着手……

A:

        用sqlplus试试看能不能登录，如果能登录证明不是listen的问题， 检查alert_log，如果没有报错，检查是否是应用程序的问题。

　　dba应该都处理过这种情况，关键在于心态，要平和，不要乱

B:

        1:首先登陆数据库服务器，本地 IPC 是否登陆正常。

　　2:本地通过 listenner 登陆 是否正常,listener 状态 和 lsnrctl status 中 service 是否正常(这个一定要包含 远程 tnsname 设置的 service_name or SID)

　　3:自己找台服务器远程登陆是否正常

　　4:检查 v$session.logon_time 看看最后登陆的 session 是哪些服务器，时间是多少。 检查 process 设置以及 process数量。

　　5:简单 tail -f lisener log 看看是否有异常log，比如被人攻击不断地连接。

　　上面几步，几分钟就可完成，快速，不需要和 客户沟通。

　　若没发现任何问题，再和 客户沟通:

　　应用是新上的 还是 原来可以连接突然不能连接?是时候连接可以还是所有一直都不可以?

　　是否有人改过配置

　　错误信息是什么

　　tnsping 结果

　　tnsnames.ora 如何配置的(文件中是否有不可见字符、net service name 是否顶格都是可能原因)

　　ping 能否通

　　telnet 数据库ip 和 listener port 是否通

　　网络是否发生过变化

C:

        问问用户抱什么错，如果用户说不出来，自己尝试用sqlplus 连接看看，有了错误号，立刻可以把问题缩小到很小的范围……

　　其它就是看alert log找错误了……

D:

        查看$ORACLE_HOME/network/log/listener.log

　　如果是listner的问题，$ORACLE_HOME/network/log/listener.log 这个时候往往已经非常巨大了

E:

        1.循问最近做过什么事情，如果没做任何事，则很有可能是cbo统计量不准确，执行计划拙劣，做statspack查看top sql,然后查看其是否采用的cbo,如果是cbo，重新收集统计量。

　　2.(1)ping 主机,if ok then (2),else主机有可能出现故障

　　(2)tnsping 主机,if ok then(3),else监听有可能出现问题

　　(3)sqlplus连接试试,if ok then 程序有可能出现问题。

F:

        1 有报错信息最好 没有查看alert_xxx.log 和相关.trc

　　2 数据库有关连接的配置 show parameter process ,show parameter session

　　操作系统层看看: ps -ef|grep LOCAL |wc -l

　　ps -ef|grep ora |wc -l

　　3 v$session_wait

　　4 开始怀疑应用中没有做conn.close() 可以根据v$open_cusro(sid)做group by 找到有问题的session

　　5 有可能是应用没有commit 或者bitmap索引造成enqueue阻塞数据库对象访问 又没有ora--00060报错等等

　　6 是不是app server的Connect pool调整了min Capability参数 使得Oracle不支持这么多长连接

原文地址：http://www.cpcwedu.com/Document/databasedev/111543530.htm