TIP 119 - Why some ODA commands hang?

If you are an ODA customer and you see that "oakcli show version -detail" hangs or some patch command does run forever with no output, I think you might need to make sure .bash_profile is not customized for user input...

Please see below :

Oakcli Commands All Hang, Do Not Complete (Doc ID 1981186.1)

Lesson learned - Do not change .bash_profile in ODA

TIP 118# : Virtualized Exadata-Adding new local disk to DomU

I have seen more Oracle customer adopting virtualized platform in Oracle Exadata. At the same time, I hear concerns regarding virtualization on Exa would be new and it could be buggy, could not be well documented and well tested compare with Bate-Metal install. All these provide me a motivation  to publish some posts regarding real experience in this platform.

Here is the first post :

If you are one of the Oracle customer with a virtualized Exadata, you may notice that the available local space in each DomU may not be sufficient to for various things which you may do such as Grid software, multiple Oracle software, 3rd party monitoring, backup agents and etc.
Also you may notice that there is no full step by step document on how to add more space to local space in DomU.

This post is to share my experience with performing this task and walk you through step by step :

Step 1 :  List existing disks and find out available disk

lsblk -id
xvda 202:0    0   25G  0 disk
xvdb 202:16   0   50G  0 disk /u01/app/
xvdc 202:32   0   50G  0 disk /u01/app/oracle/product/
xvdd 202:48   0   58G  0 disk
sda    8:0    0  128M  0 disk
sdb    8:16   0  128M  0 disk
sdc    8:32   0  128M  0 disk

I will use xvde (the next available) as new disk

Step 2 : Prepare new 20GB file

All VM guest physical files are in Dom0 under /EXAVMIMAGES/GuestImages. The new file is named db12.

qemu-img create /EXAVMIMAGES/GuestImages/exavmadm01vm01.newco.local/db12. 20G

Step 3 : Attach the newly generated file to VM

Use the xm block-attach command to dynamically attach the new generated file to the existing VM.

xm block-attach exavmadm01vm01.newco.local  file:/EXAVMIMAGES/GuestImages/exavmadm01vm01.newco.local/db12. /dev/xvde w

exavmadm01vm01.newco.local  is the VM and the file which is created in step3 is attached as xvde. 
The new disk should be visible in VM now.

lsblk -id
xvda 202:0    0   25G  0 disk
xvdb 202:16   0   50G  0 disk /u01/app/
xvdc 202:32   0   50G  0 disk /u01/app/oracle/product/
xvdd 202:48   0   58G  0 disk
sda    8:0    0  128M  0 disk
sdb    8:16   0  128M  0 disk
sdc    8:32   0  128M  0 disk
xvde 202:64   0   20G  0 disk


Step 4 : Find VM uuid and generate a new uuid for the new disk

VM uuid is set in vm.cfg and a new uuid has to be generated for the new disk.

grep -i uuid vm.cfg
uuid = 'b0c2dd2ee4b14f6cabe0b546b930b6e8'  

uuidgen | tr -d '-'

b0c2dd2ee4b14f6cabe0b546b930b6e8 is uuid for VM and 666a1ab9604e4e3d95bbdfce30d0b739 is uuid for the new disk.
These two uuids establish the new disk location. In my example, it would be such as below :


ln -s /EXAVMIMAGES/GuestImages/exavmadm01vm01.newco.local/db12. /OVS/Repositories/b0c2dd2ee4b14f6cabe0b546b930b6e8/VirtualDisks/666a1ab9604e4e3d95bbdfce30d0b739.img

Step 5 - Add the new disk to vm configuration file

vm configuration file (vm.cfg) has disk setting which the new disk needs to be added

disk = [...,

Step6 - Bounce VM and format the new disk

This is mainly the last step - It would be safe to bounce VM and when it backs up, the new disk should be visible.

xm reboot exavmadm01vm01.newco.local

The new disk needs to be formatted and then it is mounted (in this case, it is mounted as /u01/app/oracle/product/ and the mount point needs to be added to /etc/fstab

mkfs -t ext4 /dev/xvde
mkdir -p /u01/app/oracle/product/
mount -t ext4 /dev/xvde /u01/app/oracle/product/

/dev/xvde               /u01/app/oracle/product/       ext4    defaults        1 1

Now the new disk is ready for use.
Hope it helps.

TIP 117#: Access to ODA ILOM is challenging ?

New ODA is configured with ILOM IPs and network cable is plugged to Netmgt port. Everything is ready for connecting to the server via ILOM and bummer!, you may see the whole connection or at least the connection to remote console does not work as it is expected.

The following item could come handy to troubleshoot and fix the issue:

ILOM client requirements:

Per the following link, the client access should meet certain requirement.


I found that having right Java and registering it in browser are the key.
For new ODA (X5-2), per 888888.1, consider upgrading Java to 7 to avoid bug 20420055

After you make all necessary changes per above requirement, you may still have some problem connecting to remote console.
The following two issues are reported on several customers which we have :

Issue : ILOM remote console is blocked by rule set

Solution : The simplest solution is to remove rule set file - The file is C:\Windows\Sun\Java\Deployment\DeploymentRuleSet.jar and it is not dependent on where Java is installed.
If the issue still stays, consider setting Java security level to medium in Java control panel (in windows in Windows control panel)

Issue : ILOM remote console errors out with "Video redirection error - no appropriate protocol found"

Solution: Comment out jdk.tls.disabledAlgorithms=SSLv3 in JAVA_folder/lib/security/java.security and restart the browser

TIP 116# : Oracle Database Appliance - 3 Observations and 3 Resolutions

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 and after providing the right option, ODA will keep the appropriate driver and will remove unnecessary drivers. If you do not see 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. 

TIP 115# : DataGuard and Patch

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.