如何排除Oracle数据库服务器错误？
我的团队继承了基于 Oracle 的 Web 应用程序，但他们对 Oracle 数据库服务器相当缺乏经验。
Oracle 10g 服务器在具有充足磁盘空间的 Windows 2003 Server 上运行，有时所有连接都会丢失，应用程序停止工作，甚至 SQL Plus 也无法连接到数据库服务器。
但是当我们检查Windows服务管理器时，它说该服务已启动并正在运行。 重新启动通常可以解决问题，但我们需要对其进行正确的故障排除，以便我们知道导致问题的原因，从而可以避免它再次发生。
我们应该从哪里开始寻找线索呢？ 我们应该调查哪些关键日志文件？
My team inherited an Oracle-based web application and they are fairly inexperienced with Oracle database servers.
The Oracle 10g server is running on a Windows 2003 Server with plenty of disk space and from time to time, all connectivity is lost, the application stops working, not even SQL Plus is able to connect to the database server.
But when we check the Windows Service manager, it says that the service is up and running. A restart usually fixes the problem, but we need to properly troubleshoot it so we know what's causing it and so we can avoid it to happen anymore.
Where should we start looking for clues? What are the criticial log files we should be investigating?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
在服务器上，您应该有一个名为 ORACLE_HOME 的环境变量，它指示 Oracle 安装的根目录。 Oracle 跟踪/转储文件夹很可能位于该文件夹下。 搜索名为“bdump”（后台转储）的文件夹。 这就是主日志文件（称为警报日志）以及后台进程生成的跟踪文件的位置。 将有一个名为“udump”的相邻文件，其中包含用户进程生成的所有跟踪文件。
然而，我真正的建议是，您应该聘请了解 Oracle 的人，或者让 Oracle 支持人员参与其中。
On the server you should have an environment variable called ORACLE_HOME which indicate the root of the Oracle install. Most likely the Oracle trace/dump folders will be under there. Search for a folder called "bdump" (background dump). That's where the main log file, knows as the alert log, will be, as well as trace files generated by background processes. There will be an adjacent file called "udump" which will contain any trace files generated by user processes.
However, my real advice is that you should either hire someone who knows Oracle or get Oracle Support involved.
警报日志将是第一个要检查的文件。
它可能位于 $ORACLE_HOME/admin/bdump 中并且（可能）称为alert_DATABASE-SID.log
它包含数据库执行的大部分重要操作以及发生的任何重要错误。
The alert log would be the first file to check.
It will probably be in $ORACLE_HOME/admin/bdump and (probably) called alert_DATABASE-SID.log
It contains most of the important actions that the database does, as well as any important errors that occur.
我必须同意 cagcowboy 的观点。 检查警报日志中是否有错误。 如果没有错误，则保持 sysdba 登录数据库，当数据库挂起时，尝试进行挂起分析。 请参阅hanganalyze 上的metalink 注释215858.1。
I have to agree with cagcowboy. Check your alert logs for errors. If no errors then maintain a sysdba login into the database and when it hangs, attempt to do a hang analysis. See metalink note 215858.1 on hanganalyze.
您是否尝试过
tnsping？ 我们偶尔会遇到需要 DBA 协助的侦听器问题。tnsping是我们用来进行分类的诊断工具。如果可能的话，我建议聘请一位经验丰富的 Oracle DBA。
Have you tried
tnsping? We've occasionally run into problems with the listener that requires an assist from our DBA.tnspingis the diagnostic tool we use to do triage.I would recommend hiring an experienced Oracle DBA if at all possible.
检查警报日志以了解数据库的结构。 有时，参数设置不当会导致挂起或性能下降。 或者您可以关闭并以装载模式启动，然后检查 v$ 参数值是否有问题。 设置总内存非常重要。
check the alert log to see how the Db is structured. sometimes badly set parameters make hangs or slow performance. or you can shutdown and start in mount mode, then check the v$parameter values for problems. setting total memory is very important.