Brief intro
As promised, in this article we will check the syntax on our
console. These commands are carried out against a working 4-node Oracle 10g R2
cluster. The OS is RHEL 4.2/Centos 4.2 running on Virtual machines, on an ESX
Server. Each server has 1200MB RAM, Dual CPU or better said as 2 vCPU (Virtual
CPUs).
In upcoming articles, we will discuss a 6 node 4vCPU RHEL4.2,
1600MB Oracle RAC, and will also keep in mind our plans for Solaris 10 with
Oracle 10gR2 cluster. I’m pretty confident we will also do 10.1 Oracle RAC on
MAC OSX, once VMware has support for the MACs on the ESX or VMware Servers.
Administering Clusterware
Let’s take a look at the details of the commands that we mentioned in the Administration
of our Clusterware articles.
General OCRCONFIG commands
[oracle@vm1rh4 ~]$ ocrconfig
Name:
ocrconfig - Configuration tool for Oracle Cluster Registry.
Synopsis:
ocrconfig [option]
option:
-export <filename> [-s online]
- Export cluster register contents to a file
-import <filename>
- Import cluster registry contents from a file
-upgrade [<user> [<group>]]
- Upgrade cluster registry from previous version
-downgrade [-version <version string>]
- Downgrade cluster registry to the specified version
-backuploc <dirname> - Configure periodic backup location
-showbackup - Show backup information
-restore <filename> - Restore from physical backup
-replace ocr|ocrmirror [<filename>] - Add/replace/remove a OCR device/file
-overwrite - Overwrite OCR configuration on disk
-repair ocr|ocrmirror <filename> - Repair local OCR configuration
-help - Print out this help information
Note:
A log file will be created in
$ORACLE_HOME/log/<hostname>/client/ocrconfig_<pid>.log. Please ensure
you have file creation privileges in the above directory before
running this tool.
Showing backups
[oracle@vm1rh4 ~]$ [oracle@vm1rh4 ~]$ ocrconfig -showbackup vm1rh4 2006/10/13 14:04:07 /u01/app/oracle/oracle/product/10.2.0/crs/cdata/crs vm1rh4 2006/10/13 09:52:00 /u01/app/oracle/oracle/product/10.2.0/crs/cdata/crs vm1rh4 2006/10/13 05:37:24 /u01/app/oracle/oracle/product/10.2.0/crs/cdata/crs vm1rh4 2006/10/12 04:14:46 /u01/app/oracle/oracle/product/10.2.0/crs/cdata/crs vm1rh4 2006/10/01 00:38:29 /u01/app/oracle/oracle/product/10.2.0/crs/cdata/crs [oracle@vm1rh4 ~]$
What is OCRDUMP anyways
[oracle@vm1rh4 ~]$ ocrdump -help
Name:
ocrdump - Dump contents of Oracle Cluster Registry to a file.
Synopsis:
ocrdump [<filename>|-stdout] [-backupfile <backupfilename>] [-keyname <keyname>] [-xml] [-noheader]
Description:
Default filename is OCRDUMPFILE. Examples are:
prompt> ocrdump
writes cluster registry contents to OCRDUMPFILE in the current directory
prompt> ocrdump MYFILE
writes cluster registry contents to MYFILE in the current directory
prompt> ocrdump -stdout -keyname SYSTEM
writes the subtree of SYSTEM in the cluster registry to stdout
prompt> ocrdump -stdout -xml
writes cluster registry contents to stdout in xml format
Notes:
The header information will be retrieved based on best effort basis.
A log file will be created in
ORACLE_HOME/log/<hostname>/client/ocrdump_<pid>.log.
Make sure you have file
creation privileges in the above directory before
running this tool.
Checking what the OCRDUMP did
Oracle Database 10g CRS Release 10.2.0.1.0 Production Copyright 1996, 2005 Oracle. All rights reserved.
2006-10-13 16:38:55.377: [ OCRDUMP][3086993088]ocrdump starts…
2006-10-13 16:39:04.063: [ OCRDUMP][3086993088]Failed to open key handle for key name [SYSTEM.evm.debug] [PROC-5:
User does not have permission to perform a cluster registry operation on this key. Authentication error
[User does not have permission to perform this operation] [0]]
2006-10-13 16:39:05.253: [ OCRDUMP][3086993088]Failed to open key handle for key name [SYSTEM.crs.versions] [PROC-5: User does not have
permission to perform a cluster registry operation on this key. Authentication error [User does not have permission to perform this operation] [0]]
2006-10-13 16:39:16.853: [ OCRDUMP][3086993088]Failed to open key handle for key name [CRS.CUR] [PROC-5: User does not have permission to
perform a cluster registry operation on this key. Authentication error [User does not have permission to perform this operation] [0]]
2006-10-13 16:39:16.908: [ OCRDUMP][3086993088]Failed to open key handle for key name [CRS.HIS] [PROC-5: User does not have permission to
perform a cluster registry operation on this key. Authentication error [User does not have permission to perform this operation] [0]]
2006-10-13 16:39:16.938: [ OCRDUMP][3086993088]Failed to open key handle for key name [CRS.SEC] [PROC-5: User does not have permission to
perform a cluster registry operation on this key. Authentication error [User does not have permission to perform this operation] [0]]
2006-10-13 16:39:16.939: [ OCRDUMP][3086993088]Exiting [status=success???]…
Well not exactly successful so we log in as root and do it again (Do
check with your Oracle support before you give your Oracle user the file
creation permissions in production!).
[root@vm1rh4 oracle]# ocrdump -backupfile my_file PROT-302: Failed to initialize ocrdump [root@vm1rh4 oracle]# ocrdump PROT-303: Dump file already exists [OCRDUMPFILE]
Viewing the contents of the OCRDUMPFILE
The contents of the OCRDUMP can be quite large, especially when dealing with
4 nodes. Clearly, you can see that permissions are crucial. On databases and
instance level users, Oracle exercises full control, whereas on CRS level we
see root as the one with permissions. I have highlighted the details on the
small excerpt of the OCRDUMPFILE.
###################################################################
10/13/2006 16:38:55
ocrdump
[SYSTEM]
UNDEF :
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}
[SYSTEM.css]
UNDEF :
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}
[SYSTEM.css.interfaces]
UNDEF :
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_CREATE_SUB_KEY, OTHER_PERMISSION : PROCR_READ, USER_NAME : oracle, GROUP_NAME : dba}
[SYSTEM.css.clustername]
ORATEXT : crs
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}
[SYSTEM.css.misscount]
UB4 (10) : 360
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}
[SYSTEM.css.diskfile]
ORATEXT : /u03/oradata/votingdisk/CSSFile
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}
[SYSTEM.css.diskfile1]
ORATEXT : /u03/oradata/votingdisk/CSSFile_mirror1
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}
[SYSTEM.css.diskfile2]
ORATEXT : /u03/oradata/votingdisk/CSSFile_mirror2
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}
[SYSTEM.css.configured_node_map]
BYTESTREAM (16) : 1e
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}
[SYSTEM.css.node_names]
UNDEF :
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}
[DATABASE.DATABASES.brianic.CONFIG_VERSION]
ORATEXT : 10.2.0.0.0
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_WRITE, OTHER_PERMISSION : PROCR_READ, USER_NAME : oracle, GROUP_NAME : dba}
[DATABASE.DATABASES.brianic.INSTANCE.brianic1]-Our First Node!
ORATEXT : brianic1
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_ALL_ACCESS, OTHER_PERMISSION : PROCR_ALL_ACCESS, USER_NAME : oracle, GROUP_NAME : dba}
[DATABASE.DATABASES.brianic.INSTANCE.brianic1.NODE]
ORATEXT : vm1rh4
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_ALL_ACCESS, OTHER_PERMISSION : PROCR_ALL_ACCESS, USER_NAME : oracle, GROUP_NAME : dba}
[DATABASE.DATABASES.brianic.INSTANCE.brianic1.ENABLED]
ORATEXT : true
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_ALL_ACCESS, OTHER_PERMISSION : PROCR_ALL_ACCESS, USER_NAME : oracle, GROUP_NAME : dba}
[DATABASE.DATABASES.brianic.INSTANCE.brianic1.ENVIRONMENT]
UNDEF :
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_ALL_ACCESS, OTHER_PERMISSION : PROCR_ALL_ACCESS, USER_NAME : oracle, GROUP_NAME : dba}
.
.
.
[DATABASE.DATABASES.brianic.INSTANCE.brianic4]-Our Last Node!
ORATEXT : brianic4
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_ALL_ACCESS, OTHER_PERMISSION : PROCR_ALL_ACCESS, USER_NAME : oracle, GROUP_NAME : dba}
[DATABASE.DATABASES.brianic.INSTANCE.brianic4.NODE]
ORATEXT : vm4rh4
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_ALL_ACCESS, OTHER_PERMISSION : PROCR_ALL_ACCESS, USER_NAME : oracle, GROUP_NAME : dba}
[DATABASE.DATABASES.brianic.INSTANCE.brianic4.ENABLED]
ORATEXT : true
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_ALL_ACCESS, OTHER_PERMISSION : PROCR_ALL_ACCESS, USER_NAME : oracle, GROUP_NAME : dba}
[DATABASE.DATABASES.brianic.INSTANCE.brianic4.ENVIRONMENT]
UNDEF :
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_ALL_ACCESS, OTHER_PERMISSION : PROCR_ALL_ACCESS, USER_NAME : oracle, GROUP_NAME : dba}
For a full copy of my dumpfile, see my blog. Please note that I have put it
up for my own use and will get into the nitty-gritty of every detail of it when
I have time. If you have the time, go ahead and explore
it!
Conclusion:
In upcoming
articles, we will conduct more command lines and will attempt to mend our
broken RAC with recovery commands. I will make full backup copies of my
development environment with the ESX Consolidated backup tool, and then we can
safely do the dirty job in our well-protected and fenced lab environment.
