Oranew
asked on
Start all the Listeners and databases on maintenance day
My server has more than 30 databases on One single server. It is Oracle 11g rel 2 ( Non-RAC)
Each database is having its own listener( Never seen such a client before).
The maintenance day is a nightmare as I have to stop all the listeners one by one and each database and bring that up one by one after the maintenance is over.
I need something so that I can bring up all the listeners and the databases in one setting or script.
What is the best approach to achieve this task.
Experts ! I need help on this.
Each database is having its own listener( Never seen such a client before).
The maintenance day is a nightmare as I have to stop all the listeners one by one and each database and bring that up one by one after the maintenance is over.
I need something so that I can bring up all the listeners and the databases in one setting or script.
What is the best approach to achieve this task.
Experts ! I need help on this.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Sorry for not updating with the os version. It is Solaris 10
Assuming that the oratab file is set up correctly, you could use that to determine the instances on the system and which ones to start up.
However, it would be almost impossible to detect the listener names.
Then what if you upgrade some and not all databases. You would be potentially running multiple ORACL_HOMEs, which the script would have to account for. I would think that a combination of the oratab file and the oraenv script would get you the right environments set up for each database, but the listeners would still present a problem.
However, it would be almost impossible to detect the listener names.
Then what if you upgrade some and not all databases. You would be potentially running multiple ORACL_HOMEs, which the script would have to account for. I would think that a combination of the oratab file and the oraenv script would get you the right environments set up for each database, but the listeners would still present a problem.
I'm just windows guy, but assuming, that like on windows listener binary can be identified by name in list of running processes and mapped back to daemon using it.
So - enumerate listeners this way, save list, stop and after maintenance start listeners according saved list can be functional aproach.
And similar can be used to identify DBs too. It will grant, that after maintenance you will be starting only those which were running prior it.
So - enumerate listeners this way, save list, stop and after maintenance start listeners according saved list can be functional aproach.
And similar can be used to identify DBs too. It will grant, that after maintenance you will be starting only those which were running prior it.
While it would be possible to identify running listeners from a process list, there is no way to determine which ORACLE_HOME they are running from on a UNIX type OS. I would assume that Windows is the same way. If you are running multiple homes, then you need to use the correct version of lsnrctl to shut it down.
Then what if there is a database or listener that isn't running when you collect the list at shutdown? How does that get restarted?
Then what if there is a database or listener that isn't running when you collect the list at shutdown? How does that get restarted?
@jonsone
a) no, on windows I can query running process for full path of binary and as well calling command including its parameters, so i.e. command:
Get-WmiObject win32_process -filter "name like 'oracle%'" |select commandline
will return
<full_path>\oracle.exe <SID>
b) If it was not running prior maintenance start, I expect it was intentional and starting it after maintenance can cause more harm then let if off like was prior system maintenance.
a) no, on windows I can query running process for full path of binary and as well calling command including its parameters, so i.e. command:
Get-WmiObject win32_process -filter "name like 'oracle%'" |select commandline
will return
<full_path>\oracle.exe <SID>
b) If it was not running prior maintenance start, I expect it was intentional and starting it after maintenance can cause more harm then let if off like was prior system maintenance.
This is a real scenario that we see all the time.
Database1, listener down, database up. Doing major structural changes and/or data migration before maintenance that affects all database on system.
Database2, running normally.
Now, when I go to do the full system maintenance, I don't want to have to bring the listener up for database1, just so it can be successfully upgraded. Since the database is listed as a database that should be up (the oratab file has a flag for that), the listener should be started as well.
Full path of executable running can usually be found on UNIX systems, but varies greatly between OS and OS version. Sometimes it is easy and sometimes nearly impossible. That only gets me the full path of the executable. I still need to set the rest of the environment.
Possibly use a script to hard code the start of the listeners and then use the dbstart script. That should get all the databases at once if you want to rely on Oracle's script.
Database1, listener down, database up. Doing major structural changes and/or data migration before maintenance that affects all database on system.
Database2, running normally.
Now, when I go to do the full system maintenance, I don't want to have to bring the listener up for database1, just so it can be successfully upgraded. Since the database is listed as a database that should be up (the oratab file has a flag for that), the listener should be started as well.
Full path of executable running can usually be found on UNIX systems, but varies greatly between OS and OS version. Sometimes it is easy and sometimes nearly impossible. That only gets me the full path of the executable. I still need to set the rest of the environment.
Possibly use a script to hard code the start of the listeners and then use the dbstart script. That should get all the databases at once if you want to rely on Oracle's script.
it is on Oranew to choose or specify his way. My initial entry was reffering to "hardcoded" list of DBs and their listeners, the autodetect part was just on the top of it.
I bet, some "for" with listener/databases in extra file would be more elegant , even better would be let the script autodetect all the instances.
@ Oranew - the script above asumes UX like OS. Can you tell us your OS type and version?