During last couple weeks, I have been involved in various ODA activities from patching of an existing ODA to latest version to setting up new environments on ODA X5-2
I thought to share some lesson learnt :
1) Patch failure
If you encounter in a situation which ODA patch fails and reports the following error
Unable to get the nodenumber in the chassis
The resolution is to create /opt/oracle/oak/conf/node_num.conf on each compute node and add NODENUM=0 or NODENUM=1.
2) Network issue
If you setup new ODA and in the first boot, it should ask for fiber or copper connection. Per answer, ODA will keep the appropriate driver. If you do not have it in any new ODA x3-2 onwards when it is booted for the first time, you may see issue with setting up network later.
To fix the issue, before further progress with deployment and setting up environment, run /opt/oracle/oak/lib/SetupX4Network.pl
3) Some oakcli commands fail
You may notice that some oakcli commands fail with the following error:
OAKERR:6000 Exception encountered in Module getMasterNode
OAKERR:6002 No master node was found
This cause usually could be that the process cannot connect to oakd daemon on ODA.
You could confirm this with running
oakcli show ismaster
If this command fails, it could be fixed by bouncing oakd using oakcli. As long as oakcli show ismaster does not work well, you may experience failure of some oakcli commands.
Starting 11.2, Oracle introduced Standby-First Patch Apply which provides support between different software releases in the primary and standby. In other words, for certified Oracle patches, it allows the customer to apply/validate the patch first on the standby software while the primary stays in the previous software release. Also it enabled the customer to switch over between primary and standby in the mixed software version.
Patch README should provide the details on whether or not the patch is certified for standby-first patch apply. According to Oracle doc or Oracle Patch Assurance - Data Guard Standby-First Patch Apply (Doc ID 1265700.1), the following patches are certified for standby-first patch apply.
- Exadata Database Bundle Patch
- Patch Set Update (PSU)
- Critical Patch Update (CPU)
- Interim (“one-off”) patches
Make sure to keep compatible between primary and standby the same during the patching. It is noted that mixed version cannot be run for more than 31 days (possibly support issue if it goes beyond) and it is only viable for the patches which are not more than 1 year apart. So to be enable to utilize this feature, the following conditions should meet :
- Software is 11.2 on-wards
- Patch is determined explicitly in readme to be Standby-First Patch apply
- Mixed version can only be run less than 31 days
- The qualified patch should not be more than 1 year apart from the current primary/standby run.
If you are starting with new RAC setup or you have a RAC environment and you are looking for performance tuning, stabilization of the environment or even upgrade, the following document comes very handy :
RAC and Oracle Clusterware Best Practices and Starter Kit (Platform Independent) (Doc ID 810394.1)
If you negotiate with Oracle on licensing or design/architect a solution for a customer, the following documents may come handy :
- Oracle process core factor : http://www.oracle.com/us/corporate/contracts/processor-core-factor-table-070634.pdf
- Oracle software technical support policies : http://www.oracle.com/us/support/library/057419.pdf
- Oracle partition policy : http://www.oracle.com/us/corporate/pricing/partitioning-070609.pdf
- Licensing Data Recovery environment : http://www.oracle.com/us/corporate/contracts/data-recovery-licensing-070587.pdf
- Software investment guide : http://www.oracle.com/us/corporate/pricing/software-investment-guide/index.html
- Oracle support/certification on Vmware : http://www.vmware.com/files/pdf/solutions/oracle/Understanding_Oracle_Certification_Support_Licensing_VMware_environments.pdf
- Oracle VM and hard partitioning : http://www.oracle.com/technetwork/server-storage/vm/ovm-hardpart-168217.pdf
Very often I login to a customer site and I end up to search in document for couple things :
To enable startup scripts and start Node Manager:
- How to setup NodeManager so the customer could use Admin console for Weblogic startup
- How to make username/password encrypted so the command line does not ask for username/password at time of startup
- Quick and easy guideline for patching
- How to check Weblogic version
To enable startup scripts and start Node Manager:
1. Navigate to the following directory
MW_HOME is the directory where Oracle Fusion Middleware is installed.
3. Run the setNMProps.sh script to set the StartScriptEnabled property to true before starting Node Manager:
This is a one-time action. After you run this script, you can skip this step before starting Node Manager again.
5. Start Node Manager with the startNodeManager script.
UNIX script: WL_HOME/server/bin/startNodeManager.sh
Windows script: WL_HOME\server\bin\startNodeManager.cmd
To avoid username/password at startup:
To avoid prompts for a user name and password on startup after you start a Managed Server the first time, you can create a boot.properties file in the domain-home/servers/server-name/security/ directory. This file would include the following lines:
password=PASSWORDThe boot.properties file will be encrypted the first time that the Managed Server is started.
Patching mechanism on Weblogic :
Basically bsu is the tool to apply the patches on Weblogic install. The following shows an example on how patch is applied and how it is verified.
copy patch to $MW_HOME/utils/bsu/cache_dir
remove patch zip file (rm p1......zip)
./bsu.sh -install -patch_download_dir=$MW_HOME/utils/bsu/cache_dir -patchlist=FCX7 -prod_dir=$WL_HOME
./bsu.sh -view -status=applied -prod_dir=$WL_HOME
Checking Weblogic version:
[oracle@oracle2qa bin]$ . ./setDomainEnv.sh
[oracle@oracle2qa APEXDomain]$ java weblogic.version