Database startup after reboot of RAC server

Question

Hello,
My config : 2 nodes w2k3 with 15 dbs . Oracle 10.2.0.3
I started to scheduled my rac server reboot so i follow the oracle doc to shutdown properly all db,asm,service,listener,etc...
Today one the server reboot, but some instance doesn't start (only five , and the last five in alphabetic order)
In the log :
db log : nothing just the shutdown
crs_log : the start of the 10 db but nothing for the last five !!
just a trace on one listener service :
StartResource error for ora.sqyora01.LISTENER_1522_SQYORA01.lsnr error code = 1
2010-08-11 02:56:08.000: [  CRSRES][3008]32Start of `ora.sqyora01.LISTENER_1522_SQYORA01.lsnr` on member `sqyora01` failed.
2010-08-11 02:56:08.125: [  CRSRES][3008]32Skip online resource: ora.sqyora01.LISTENER_SQYORA01.lsnr
On windows services : the OracleServiceSID service isn't started.
Any help is welcome to understand this problem.
Thanks.

Answer 1

user4511076 wrote:
IMO : (i am not a great oracle dba, because i have not enough time to spend with, and my collegue need really simple think to do, like startup/shutdown a database, no more investigation)Why startup/shutdown a database? I have databases that work 24x7 and uptimes of over a year. The record so far, has been over 24 months uptime (1st downtime were caused by a powerfailure to the rack cabinet). And for a database instance that runs a number of processes and deals with 100's to 1000's of inserts per second.
it's easier to view that an oracle process take more cpu and so investigate in that database what's appens. Rather than search in my v$sql table to find witch schema doing wrong thinksNot sure what you are trying to say here. Single or multiple database instances do not change how a session looks like, or how SQLs are executed.. and thus not how you troubleshoot problems. Nor does it change resource requirements, or how you address these. But multiple instances do impact resource availability and requires one to split resources amongst instances - the end result of this is less flexibility.
It's easier to affect cpu ressource to a process, rather than configuring it in oraclePlease explain.
It's easier to stop a database rather than "put offline a schema"This is a "silly" statement to make IMO. Why do you want to offline a schema? Availability of applications and data are a critical feature in today's information system landscape. So why argue the complete opposite and say it is now more complex to make something less available?
By the same token, why do you want to offline a database? A down database is even less useful than a downed server - at least you can use the downed server as a doorstop.. ;-)
And if a database crash it only affect one application.Yeah.. and these happens when? Every few minutes? Every hour? Once a day?
This is not a valid argument. Oracle instances very seldom crashes just for the heck of it. Most often it is due to incorrect o/s configuration, problematic hardware, uncertified components, old drivers, etc. Or plain old application abuse of Oracle.
There is the theorical approach and practical one : I'm not alone is that case :
http://oracledoug.com/serendipity/index.php?/archives/1339-The-Reality-Gap-3-A-Single-Instance-per-Server.html
http://www.dba-oracle.com/art_dbazine_server_consolidation.htm
I have never done RDBMS as a theoretical thing. The most dynamic table (ito SQLs against it) I have, grows by more than 450 million rows per day. This is as real world as real world gets. And that is what shapes my experience and opinion. And Burleson and I have never seen eye to eye on a number of subjects - so quoting his views on consolidation does little to persuade me to change my opinion.
have you any ideas where can i found an error message that explain why my database doesn't start ? (like not enough ressource ;-) )Troubleshooting a problem starts with a very basic principle - isolation. Isolate the layer or moving part where the problem occurs. As the other instances are running, it means that the CRS software layer is up and running, that the storage layer is up and running and so on. So the problem should be with the instance that for some reason refuses to start? Confirm this by using sqlplus to start a down instance and looking at what its alert log file says. It should have some kind of pointer to what dependency that has not been met.