oracle restart deprecated in 12c
The short summary here is: there is nothing new to see. There is just a not in the 12c docs that creates a bit of confusion. But let’s go back one step. This blog post started with (what looked like) a simple question by Christian Antognini:
Without much thinking, I shot from the hip and answered “clusterware / grid infrastructure” but I had to realize later that I really don’t know much about Oracle Restart. First of all, to me Oracle Restart has been just a stripped down installation of the clusterware. You download and install grid infrastructure to use it and in the end you use srvctl to manage your oracle items (listener, asm, databases and services) like in a RAC or RAC one node environment. Just without a real cluster. It may be more complicated than that but that’s how I see it. And that really may not be the whole truth.
My second answer was “it is still there, still works, is even documented. Had I just scrolled up a tiny bit I would have seen a note similar to this one in the 12c database upgrade guide:
Oracle Restart is deprecated in Oracle Database 12c. Oracle Restart is currently restricted to manage single-instance Oracle databases and Oracle ASM instances only, and is subject to desupport in future releases.
And there was my second mistake. I confused deprecated with desupported. I first thought they simply abondoned the name and are now calling it clusterware light or something like that. I really had to google for the word “deprecated” to understand what it really means. I now interpret the note as saying: “Don’t be surprised if a future version of Oracle does not have the Restart feature”. There is no replacement that I know of from Oracle today but I would hope and assume that they would provide an alternative if and when that happens. And if not, we’ll just recycle those good old start/stop scripts that we have relied on before 11.2 came along.
So I guess the real answer to Chris should have been: “Excellent question. There is no alternative for single instances as of today. We may have to go back to our own or 3rd party scripts at some point”. Think more before you tweet. Lesson learned.
Since all this was so confusing (and still is), I decided to clear my head by checking it out and installing Oracle Restart on my lab machine that I had just set up. Just to verify that Restart is still fine. I had already installed the database software and set up a database and listener. Usually, you would install Restart first and the database after that because then DBCA would register with it for you. The process is documented very well in the 12c admin guide.
Download the clusterware from OTN, unzip, and start with runInstaller. I opted to install the grid infrastructure software only and went with the defaults on all other pages, ignoring some warnings. With RAC installs, I prefer to run the grid stuff as a seperate grid user but with this setup, I was lazy and installed and ran as the oracle user.
I ignored this warning I received because I did not set up an extra group for asmadmin which would make sense if you have seperate accounts for grid and database.
Yury Velikanov mentioned in his 12c gi install blog that the installer now offers an option asking for your root password so it could run the root.sh scripts for you. I was a bit disappointed to learn that for some reason I still had to log in as root and run it the old fashioned way. I guess it has to do with me just doing the “Install Grid Infrastructure Software Only” option.
The output of the root.sh script was nice enough to point me to the script I needed to run to turn this into a true standalone clusterware install for Restart.
[root@ora12c ~]# /u01/app/12.1.0/grid/root.sh
Performing root user operation for Oracle 12c
The following environment variables are set as:
ORACLE_OWNER= oracle
ORACLE_HOME= /u01/app/12.1.0/grid
Enter the full pathname of the local bin directory: [/usr/local/bin]:
The contents of "dbhome" have not changed. No need to overwrite.
The contents of "oraenv" have not changed. No need to overwrite.
The contents of "coraenv" have not changed. No need to overwrite.
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
To configure Grid Infrastructure for a Stand-Alone Server run the following command as the root user:
/u01/app/12.1.0/grid/perl/bin/perl -I/u01/app/12.1.0/grid/perl/lib -I/u01/app/12.1.0/grid/crs/install /u01/app/12.1.0/grid/crs/install/roothas.pl
To configure Grid Infrastructure for a Cluster execute the following command as oracle user:
/u01/app/12.1.0/grid/crs/config/config.sh
This command launches the Grid Infrastructure Configuration Wizard. The wizard also supports silent operation, and the parameters can be passed through the response file that is available in the installation media.
And so I executed that script.
[root@ora12c ~]# /u01/app/12.1.0/grid/perl/bin/perl -I/u01/app/12.1.0/grid/perl/lib -I/u01/app/12.1.0/grid/crs/install /u01/app/12.1.0/grid/crs/install/roothas.pl Using configuration parameter file: /u01/app/12.1.0/grid/crs/install/crsconfig_params LOCAL ADD MODE Creating OCR keys for user 'oracle', privgrp 'oinstall'.. Operation successful. LOCAL ONLY MODE Successfully accumulated necessary OCR keys. Creating OCR keys for user 'root', privgrp 'root'.. Operation successful. CRS-4664: Node ora12c successfully pinned. 2013/07/02 13:41:04 CLSRSC-330: Adding Clusterware entries to file 'oracle-ohasd.conf' ora12c 2013/07/02 13:41:26 /u01/app/12.1.0/grid/cdata/ora12c/backup_20130702_134126.olr 2013/07/02 13:42:33 CLSRSC-327: Successfully configured Oracle Grid Infrastructure for a Standalone Server
And if I had done this before creating my database with dbca it would have picked it up automatically and registered for me. But it was too late for that and so I had to add the database and listener manually like this:
[oracle@ora12c ~]$ srvctl add database -db ORCL12 -oraclehome /u01/app/oracle/product/12.1.0/dbhome_1 [oracle@ora12c ~]$ srvctl status database -db ORCL12 Database is not running.
In fact it was running from an earlier manual STARTUP command which srvctl could not know about. So I shut it down manually first and started it again properly through srvctl.
[oracle@ora12c ~]$ sqlplus sys/ as sysdba SQL*Plus: Release 12.1.0.1.0 Production on Tue Jul 2 13:51:49 2013 Copyright (c) 1982, 2013, Oracle. All rights reserved. Enter password: Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. [oracle@ora12c ~]$ srvctl start database -db ORCL12
The listener was a similar story, it was already running and adding it generated an error. So I stopped it before adding it to gi. You could also start the listener from the grid home by setting the ORACLE_HOME environment variable to the grid home but I had already configured it in the other home so I just used that.
[oracle@ora12c ~]$ srvctl add listener PRCN-2061 : Failed to add listener ora.LISTENER.lsnr PRCN-2065 : Port(s) 1521 are not available on the nodes given PRCN-2067 : Port 1521 is not available across node(s) "ora12c" [oracle@ora12c ~]$ lsnrctl stop LSNRCTL for Linux: Version 12.1.0.1.0 - Production on 02-JUL-2013 13:54:04 Copyright (c) 1991, 2013, Oracle. All rights reserved. Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=ora12c)(PORT=1521))) The command completed successfully [oracle@ora12c ~]$ srvctl add listener -listener LISTENER [oracle@ora12c ~]$ lsnrctl status [oracle@ora12c ~]$ srvctl start listener
I verified everything by rebooting the whole server and just as expected the listener and database instance were started automatically after the reboot.
No comments:
Post a Comment