如何解决 Oracle 数据库服务器错误？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/542340/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How to troubleshoot Oracle database server errors?
提问by Dema
My team inherited an Oracle-based web application and they are fairly inexperienced with Oracle database servers.
我的团队继承了一个基于 Oracle 的 Web 应用程序，他们对 Oracle 数据库服务器的经验相当缺乏。
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.
Oracle 10g 服务器运行在具有大量磁盘空间的 Windows 2003 Server 上，并且有时会丢失所有连接，应用程序停止工作，甚至 SQL Plus 都无法连接到数据库服务器。
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.
但是当我们检查 Windows 服务管理器时，它说该服务已启动并正在运行。重新启动通常可以解决问题，但我们需要对其进行适当的故障排除，以便我们知道是什么导致了它，从而避免它再次发生。
Where should we start looking for clues? What are the criticial log files we should be investigating?
我们应该从哪里开始寻找线索？我们应该调查哪些关键日志文件？
回答by Dave Costa
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.
在服务器上，您应该有一个名为 ORACLE_HOME 的环境变量，它指示 Oracle 安装的根目录。Oracle 跟踪/转储文件夹很可能在那里。搜索名为“bdump”（后台转储）的文件夹。这就是主日志文件（称为警报日志）以及后台进程生成的跟踪文件所在的位置。将有一个名为“udump”的相邻文件，其中包含用户进程生成的任何跟踪文件。
However, my real advice is that you should either hire someone who knows Oracle or get Oracle Support involved.
但是，我真正的建议是，您应该聘请了解 Oracle 的人或让 Oracle 支持人员参与其中。
回答by MichaelN
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.
我必须同意 cagcowboy。检查您的警报日志是否有错误。如果没有错误，则保持 sysdba 登录到数据库，当它挂起时，尝试进行挂起分析。请参阅有关 hanganalyze 的 metalink 说明 215858.1。
回答by cagcowboy
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
它可能在 $ORACLE_HOME/admin/bdump 中，并且（可能）称为 alert_DATABASE-SID.log
It contains most of the important actions that the database does, as well as any important errors that occur.
它包含数据库执行的大多数重要操作，以及发生的任何重要错误。
回答by Jon Ericson
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.
你试过tnsping吗？我们偶尔会遇到需要 DBA 协助的侦听器问题。 tnsping是我们用来进行分类的诊断工具。
I would recommend hiring an experienced Oracle DBA if at all possible.
如果可能的话，我建议聘请经验丰富的 Oracle DBA。
回答by amirjazz
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.
检查警报日志以了解 Db 的结构。有时参数设置不当会导致挂起或性能下降。或者您可以在挂载模式下关闭并启动，然后检查 v$ 参数值是否存在问题。设置总内存非常重要。
