dbm_configurator.xls is needed to generate databasemachine.xml file which is needed by OEM 12c to discover an exadata cluster.

Following is a step  by step process as how to generate databasemachine.xml file to be used with OEM 12c:

1) Get the dbm_configurator70.xls file from /opt/oracle.SupportTools/onecommand directory from the first compute node of Exadata cluster.

2) Also get config.dat and dbmachine.params file from /opt/oracle.SupportTools/onecommand directory.

3) Open dbm_configurator70.xls file in Microsoft Excel and enabled the ActiveX content and Macros.

4) Make sure that all three files are in one directory and then click import button in the dbm_configurator excel file.

5) Select the dbmachine.params file and click ok, and it should populate the fields in your Excel sheet.

6) Verify that all the values are ok and if they are not change them and then click on Generate button.

7) This should generate a configuration on the bottom part of your Excel sheet.

8) Review that information and if its fine, then click on Create Config Button and it should generate mutliple files in your C drive and you will get a pop up telling you location of generated files.

9) databasemachine.xml is one of those generated files and you can use it with your OEM12c.

HTH.
 

Short, sweet and very useful.

Was running a shell script in Linux to execute some SQL, and got the following error during start of script:

^M: bad interpreter

Yes, received the script from the windows.

Now to rectify this, open the script file in VI editor and give following command:

:set fileformat=unix

save it with :wq

and run it again.

Should Run like a beaut. 

While applying BP14 in half rack of Exadata V2, got following error from node 2:

The opatch Component check failed. This patch is not applicable for /u01/app/oracle/product/11.2.0.2/dbhome_1

The opatch Applicable check failed for /u01/app/oracle/product/11.2.0.2/dbhome_1.

The patch is not applicable for /u01/app/oracle/product/11.2.0.2/dbhome_1

The patch ran successfully at the node 1.

After a little poking found out that the OPatch directory in the grid home had its owner set to root, while at the node 1 the owner was oracle.

So I ran chown -R OPatch/ in grid home and ran the patch again, and it worked like a charm.

If you have done Exadata patching few times, you are likely to know the dreaded situation when during the patching, especially the cell nodes refuse to come back.

You wait and wait, and know that all the cells have restarted successfully, except one or may be sometimes two. The patching completes and the imageinfo command shows that the Active image version has been updated at all the cells, and now only if that down cell could come up....

Eventually you either restart the cell through ILOM or ask SA or you yourself hard reboot it. It comes back and you find out that the Active image version is still pointing towards the older version. You sift through logs, check the usb version and all that stuff.

This situation likely happens due to the lock on udev. So its a very good idea to check for such kind of locking before cell patching with the following command:

/opt/oracle.cellos/validations/init.d/checkdeveachboot

If you find any locks, reboot the cell, and then proceed with the patching. If it happens during middle of patching, and you find that a cell which was brought up through hard reboot has older image version, then check for these locks and reboot the cell, and apply the patch.

From the MOS document ID 1274318.1:

To verify the hardware and firmware configuration for a storage server, execute the following "cellcli" command as the "cellmonitor" userid:

CellCLI> alter cell validate configuration

The output will be similar to:

Cell RanDomcel08 successfully altered

If any result other than "successfully altered" is returned, investigate and correct the condition.

Ok, After a disk replacement in the cell, ran the above command on cell from cellcli, and to my horror got the following error:

[WARNING] All drives are not identical
[FATAL] Can not continue. See exceptions above

But from SR, it was relieving to know that as the firmware of the newly replaced disk was the latest one, and it could be ignored.

Exachk is a fine utility to perform health check on the Exadata systems. Though its one limitation is to provide a root password for the compute nodes, cell nodes and IB switches, and obviously that is not much liked by the sysadmins.

That should be changed and is likely to be changed with the next version, I guess.

To verify the database server physical drive configuration, use the following command:

/opt/MegaRAID/MegaCli/MegaCli64 PDList -aALL | grep "Firmware state"

The output should be similar to for the disks:

Firmware state: Online, Spun Up


To verify the database server virtual drive configuration, use the following command:

/opt/MegaRAID/MegaCli/MegaCli64 CfgDsply -aALL | grep "Virtual Drive:";/opt/MegaRAID/MegaCli/MegaCli64 CfgDsply -aALL | grep "Number Of Drives";/opt/MegaRAID/MegaCli/MegaCli64 CfgDsply -aALL | grep "^State"

The output should be similar to:

Virtual Drive: 0 (Target Id: 0)
Number Of Drives    :
State               : Optimal

During the application of BP12 on Exadata half rack V2, during the phase of application of db minimal patch, one compute node refused to get patched.

As the ./install.sh script was run, it failed with :

[WARNING] This update is not applicable for Not Available.

Of course it wasn't of much help, so we fished around and then found that because dmidecode command was not returning the system product name at that node, whereas the same command was working at the other nodes, where the patching was successful.

[root@exanode db_minimal_patch]# dmidecode -s system-product-name
Not Available

This was resolved with not that much fanfare. We merely had to reset iLOM from an SSH terminal.Though it took several hours to get there. So instrumentation is the key for debugging.

What to do when you are applying PSU 11.2.0.2.4 on your Oracle 11g 11.2.0.2.0 database, and you get following error while running the opatch apply:

Make failed to invoke "/usr/bin/make -f ins_net_client.mk

client_sharedlib ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1

"....'genclntsh: genclntsh: Could not locate 

/u01/app/oracle/product/11.2.0/db_1/network/admin/shrept.lst
make: *** [client_sharedlib] Error 1
'
Make failed to invoke "/usr/bin/make -f ins_rdbms.mk

client_sharedlib ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1

"....'genclntsh: genclntsh: Could not locate 

/u01/app/oracle/product/11.2.0/db_1/network/admin/shrept.lst
make: *** [client_sharedlib] Error 1
'

The following make actions have failed :

Re-link fails on target "client_sharedlib".
Re-link fails on target "client_sharedlib".

Solution:

Just proceed with the patch installation, it is likely to get completed

successfully with warnings.

After that, go to $ORACLE_HOME/network/admin and see if there is a file shrept.lst?

If there exists a file, make sure that it's permission are set to 644.

If shrept.lst doesn't exist, then create a new file like this:

cd $ORACLE_HOME/network/admin

touch shrept.lst

chmod 644 shrept.lst

Then open the file shrept.lst in text editor, and paste the following lines:

network : snaumihi_inithostinfo
network : snaumbg_gmt
network : naedpwd_encrypt
network : naumbsb_bld_singlebyte
network : ztapis
network : nlgh 

Save and exit the file.

Now you have to run the relink all command, but before that no oracle process

is running out of that ORACLE_HOME:

cd $ORACLE_HOME/bin

./relink all

Now you should be good to go.

Cheers.

Reference: MOS Note ID 340978.1 

With the announcement of the Oracle Big Data Appliance, Oracle also comes up with some really cool technology stack which is being termed as Oracle Big Data Connectors (OBDC). This piece of software can be used with both Oracle Big Data Appliance and other Apache Hadoop-based systems.

Among other things in OBDC, There is this Oracle Loader for Hadoop which uses MapReduce processing to load data efficiently into Oracle Database 11g and speeds up the loading by using the Oracle’s internal formats. This should be the big incentive and relief and a very solid business rationale for the decision makers to try out No SQL technology with their existing infrastructure.

The main reason of fast adoption of Exadata (Medium data)  in the businesses is it’s ease and speed by which it gets connected to the OLTP (Small Data). Both of them run the same Oracle 11g. Now with these connectors, its’ easy to integrate the NoSQL (Big Data) with these small and medium data sources.

Integration with scalability and interoperability are the keywords here.