EM 13c: ORA-06553: PLS-306: wrong number or types of arguments in call to 'REPORT_SQL_MONITOR_LIST'

[UPDATE: Bugfix Bundle Patch is out: OMS Patch 25197714 ]


Enterprise Manager 13c Installation... Check!
Agents pushed to target servers... Check!
Cluster and Database targets discovered and configured... Check!

Aaah! EM 13c looks and feels brilliant... 

Starting to carry out the usual daily health checks on the core-banking database...
Performance page looks great...
No Locking/Blocking either...
Heading on to the SQL Monitoring page.... WHAAAAT ??? 
ORA-06553: PLS-306: wrong number or types of arguments in call to 'REPORT_SQL_MONITOR_LIST'


After a successful deployment of Oracle Enterprise Manager 13.2, I've encountered a serious BUG in the 1st hour of my EM 13c experience! 

DBAs usually depend on the "SQL Monitoring" page of the OEM to communicate the long running active queries to the App Support Teams and take necessary actions. And, the graphs always make a better impact...

So naturally, on searching for a solution on Oracle Support, I came across the below document:

EM13c: Accessing SQL Monitoring Raises ORA-06553: PLS-306: wrong number or types of arguments in call to 'REPORT_SQL_MONITOR_LIST' (Doc ID 2199723.1)

Apparently, if you are accessing a database with a lower version that 12c, you are most likely to hit this bug!
I then raised a ticket with the support, and the assigned engineer informed me that the fix is expected in the next bundle patch releasing anytime between last week of Nov and 1st week of Dec 2016. 

Stay tuned for more...

EM 13c: What happens when you don't run root.sh after the Agent installation?

Admit it, there are times when you skip execution of the little "root.sh" script, especially when you don't have direct or indirect root access. Also, you may skip it when it was already executed for a previous installation on the same server.

Obviously, root.sh is "the most" important part of a RAC setup as it configures the CRS services and brings them up, but why in OEM 13c? Hmmm...

As a DBA, it's always a best practice to check what's different, or what's new in the root.sh files when installing a newer version of any Oracle based software. That's what I did when I implemented the OEM 13c's Oracle Management Server (OMS) and deployed agents across numerous Unix, Solaris and Windows servers that were hosting Oracle Databases.

We all know that the Enterprise Manager is no longer restricted to just monitoring databases. Especially from 12c, the Enterprise Manager has been Cloudified (oooo). It can monitor and manage almost any infrastructure hardware or software (if configured). It's a complete ENTERPRISE Cloud Management Solution! Why do I say this now? Wait for it...

So, after pushing Agents on the numerous servers, I skipped executing the root.sh, as I wanted to find out if there were any impact on any of the proceeding steps.

Everything was smooth, I discovered cluster and database targets, and added them to the EM. I was able to login into these targets and perform tasks as normal. I left for home, watched the Walking Dead, and when I returned in the morning, I noticed something interesting:

The Database Targets were stuck in "PENDING STATE"!

Initially, I thought maybe a network issue causing the Upload to pause. I then did the usual things to try and fix that problem:

/u01/app/oracle/agent13c/agent_inst/bin/emctl stop agent
/u01/app/oracle/agent13c/agent_inst/bin/emctl clearstate agent
/u01/app/oracle/agent13c/agent_inst/bin/emctl start agent
/u01/app/oracle/agent13c/agent_inst/bin/emctl upload agent
/u01/app/oracle/agent13c/agent_inst/bin/emctl status agent

But it didn't work. I put on my Oracle Support socks and Google hat, and started searching for an answer. Looked at similar problems and solutions provided by my favorite Oracle Blogs - Pythian and DBAKevlar

Nada! didn't solve my problem.

Last resort - I applied the root.sh on one of the servers, and voola! In a few minutes the database targets of that server started showing Up status!

Ohhh ! I always wanted to know what happens if I don't run the root.sh!

Later, I checked if I can get the same information from somewhere else. So I headed to on of the Agent's page and guess what I found?

ERROR: NMO not setuid-root (Unix-only). What does that mean? And why does it require root.sh to be executed?

NMO is an executable file in the sbin folder of the Agent's Home. Some of the executables in this folder need to be owned by root in order for the "Enterprise" manager to be able to work for the whole "Enterprise". Clearly, the "oracle" user ownership and permissions are nearly not enough.

Before root.sh:

oracle@xxxxx /u01/app/oracle/agent13c/agent_13.2.0.0.0/sbin> ls -l
total 68594
-rwx--x--x   1 oracle   dba        22840 Sep 30 23:29 nmb.0
-rwx--x--x   1 oracle   dba       114768 Sep 30 23:29 nmgsshe.0
-rwx--x--x   1 oracle   dba       100528 Sep 30 23:31 nmhs.0
-rwx--x--x   1 oracle   dba      8695880 Sep 30 23:29 nmo.0
-rwx--x--x   1 oracle   dba      8608224 Sep 30 23:29 nmoconf
-rwx--x--x   1 oracle   dba      8617024 Sep 30 23:31 nmopdpx.0
-rwx--x--x   1 oracle   dba      8617024 Sep 30 23:31 nmosudo.0
-rwx------   1 oracle   dba        87776 Sep 30 23:31 nmr.0
-rw-r-----   1 oracle   dba         9615 Aug  1 15:37 nmr_macro_list
-rwx------   1 oracle   dba        14976 Sep 30 23:31 nmrconf

After root.sh:

oracle@xxxxx /u01/app/oracle/agent13c/agent_13.2.0.0.0/sbin> ls -l
total 203890
-rwsr-x---   1 root       dba          87224 Nov 14 10:30 nmb
-rwx--x--x   1 oracle     dba          87224 Oct  1 06:53 nmb.0
-rwxr-xr-x   1 root       dba          78656 Nov 14 10:30 nmgsshe
-rwx--x--x   1 oracle     dba          78656 Oct  1 06:53 nmgsshe.0
-rwsr-x---   1 root       dba          99680 Nov 14 10:30 nmhs
-rwx--x--x   1 oracle     dba          99680 Oct  1 06:59 nmhs.0
-rwsr-x---   1 root       dba        13002232 Nov 14 10:30 nmo
-rwx--x--x   1 oracle     dba        13002232 Oct  1 06:53 nmo.0
-rwx------   1 root       sys        13002232 Nov 14 10:30 nmo.new.bak
-rw-r-----   1 root       dba            188 Nov 14 10:30 nmo_public_key.txt
-rwx--x--x   1 oracle     dba        12857336 Oct  1 06:53 nmoconf
-rwxr-xr-x   1 root       dba        12862728 Nov 14 10:30 nmopdpx
-rwx--x--x   1 oracle     dba        12862728 Oct  1 06:59 nmopdpx.0
-rwxr-xr-x   1 root       dba        12862728 Nov 14 10:30 nmosudo
-rwx--x--x   1 oracle     dba        12862728 Oct  1 06:59 nmosudo.0
-rwsr-x---   1 root       dba         148312 Nov 14 10:30 nmr
-rwx------   1 oracle     dba         148312 Oct  1 06:59 nmr.0
-rwx------   1 root       sys         148312 Nov 14 10:30 nmr.new.bak
-rw-r-----   1 root       dba           9615 Aug  1 22:37 nmr_macro_list
-rwx------   1 oracle     dba          80648 Oct  1 06:59 nmrconf

I hope you see the difference in permissions and ownership of the files.

Once I applied the root.sh on the remaining servers, all the cluster and database targets were up and running.

Let me know if you have any questions or a conflict of thoughts :) !

Cheers,

Getting started in Oracle Cloud - Database as a Service

Cloud - the recent talk of the tech-town. We all know Oracle has fired up the sales teams all over the world across all spheres of Businesses with a single goal - convince the customer to move to Cloud now !

Well, as technical beasts - we are more interested in how we can transition into this wave of Cloud computing, especially if you are an Oracle DBA.

Oracle is currently giving you 1 month free trial of the Cloud Services - so please make hay while the sun shines (that's lame :P)... 

To begin with, register HERE

Under Platform --> Data --> Database --> Try it --> Database as a Service --> Star Trial

P.S. - I had some difficulty to register myself as the Request Code that is sent through SMS didn't arrive at all. For any difficulty - please click the "Chat" icon to get immediate support from Oracle. They are pretty helpful.

You will receive an email with the subject "Oracle Cloud Access Details" which will give you direct access links to the dashboard.

A great place to start with following the instructions here - DBaaS Quick Start Guide

This is a simple guide that will guide you through the simple task of creating your 1st Database Instance as a Cloud Service.

This exercise will also give you an insight as to how easy it is to provision either a standalone database or a 2-node RAC database.

Happy Clouding!

Unable to empty RECYCLEBIN even after PURGE DBA_RECYCLEBIN

Recently, while upgrading a database from 11g to 12c, I faced an issue where the RECYCLEBIN just wouldn't empty even after multiple attempts at PURGE DBA_RECYCLEBIN command. Obviously, as you may have already guessed - this is a Bug! 

As usual the 1st line of solution is the Oracle Support documentation, and this is what saved the day.

Unable To Empty or delete rows from Sys.recyclebin$ which is causing dbua (upgrade) stopped and purge dba_recyclebin not helping (Doc ID 1910945.1)

Solution is to manually truncate the recyclebin$.
This can be done by following the simple below steps.

spool truncate_recyclebin.txt

alter system set recyclebin=off scope=spfile;
shutdown immediate
startup
purge recyclebin;
purge dba_recyclebin;
show recyclebin
show dba_recyclebin
select count(*) from sys.RECYCLEBIN$;
select OBJ#,OWNER#,SPACE,ORIGINAL_NAME,PURGEOBJ from sys.RECYCLEBIN$;
truncate table sys.RECYCLEBIN$;
execute dbms_stats.gather_table_stats('SYS','RECYCLEBIN$');
show recyclebin
show dba_recyclebin
select count(*) from sys.RECYCLEBIN$;
select OBJ#,OWNER#,SPACE,ORIGINAL_NAME,PURGEOBJ from sys.RECYCLEBIN$;
purge recyclebin;
purge dba_recyclebin;
show recyclebin
show dba_recyclebin
select count(*) from sys.RECYCLEBIN$;
select OBJ#,OWNER#,SPACE,ORIGINAL_NAME,PURGEOBJ from sys.RECYCLEBIN$;
alter system set recyclebin=on scope=spfile;
shutdown immediate
startup

spool off

I was then able to proceed with my database upgrade, and it's running fine in Oracle 12c as of now.

After 12c Upgrade: ORA-28040: No matching authentication protocol

An application could not connect to the Oracle Database that was upgraded to 12c (12.1.0.2). Whenever it tried connecting, the database would return the error ORA-28040: No matching authentication protocol back to the application.

Bug 14575666 states:
In 12.1, the default value for the SQLNET.ALLOWED_LOGON_VERSION parameter (deprecated now) has been updated to 11. This means that database clients using pre-11g JDBC thin drivers cannot authenticate to 12.1 database servers unless the SQLNET.ALLOWED_LOGON_VERSION parameter is set to the old default of 8.

Solution:
As the SQLNET.ALLOWED_LOGON_VERSION is a deprecated parameter, although it will work but will keep flooding your ALERT LOG file, it's best to use the updated parameter(s):

Add the below line(s) in the SQLNET.ORA file on the database server:

SQLNET.ALLOWED_LOGON_VERSION_SERVER=8
SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8

Hope this helps...

Oracle Linux 7.1 Installation on VMWARE for Oracle Databases

Required Software:

1. VMWARE Workstation
2. Linux 7.1 Installation ISO (V74844-01.iso) from edelivery.com.oracle

Let's get started:

Step 1: Create a new Virtual Machine on VMWARE.

This is something very usual so I wont be getting into details.

Use Bridged Networking if you want to assign the VM it's own IP Address

Choose your location accordingly.

Add the ISO image of Linux Installation to the CD ROM. Then start the Virtual Machine.

Step 2: Start the Virtual Machine

Let's start with the OS Installation:

Next screen is where most of the Installation Configuration will take place. Let's take it one-by-one.

Date and Time - change the settings as per your wish/requirement

Installation Destination: 
You can let the installation to Automatically partition the disk (recommended), else Configure it as per your requirement. 

Software Selection:

Choose Server with GUI on the left, and the following Add-Ons on the right:

 - Java Platform

 - Compatibility Libraries

 - Development Tools

Network and Host name:
If you miss this step, you may have a tough time to configure your VM later on. This is where the installation is a bit different from Linux 7 - for which there are many guides already available on the Internet.

Swipe the ON/OFF button to show ON.
Also, change the host name as per your preference.

This will take the IP address from the DHCP server of the router your laptop/PC is connected to. So, we will set it manually. 

Click Configure, and add the IP Address, Netmask (255.255.255.0) and Gateway as per your network preferences.

KDump - can stay enabled or disabled as per your wish.

So finally the Installation Summary should look like the below. Click 'Begin Installation'.

While the OS starts installing, you can set the root password, and any User Creations if required.

After the reboot, accept the license to proceed. 

Voola... Your Linux 7.1 Virtual Machine is ready for use! 

Feel free to drop in any queries you may have.

RMAN BACKUP AS COPY failing with ORA-00600 [kfioTranslateIO03] [17090]

Recently, I migrating a standalone database 'rnwphoto' from file system to ASM. I decided to go with the BACKUP AS COPY strategy, to save on downtime. But I was stuck for a long time trying to make the copy, but was being haunted by its failure.

Let's get to the background information. 

Database Standalone Home: /u01/app/oracle/product/11.2.0/dbhome_1 --> This is the Oracle Home used by rnwphoto database.

To convert the database to ASM based RAC, we installed GI in the GRID_HOME (/u01/app/11.2.0/grid) and RAC DB Home (/u01/app/oracle/product/11.2.0/dbhome_2)

Issue:

RMAN> BACKUP AS COPY DATABASE FORMAT '+DATA_DG'; 

Starting backup at 09-SEP-15 
allocated channel: ORA_DISK_1 
channel ORA_DISK_1: SID=8 device type=DISK 
allocated channel: ORA_DISK_2 
channel ORA_DISK_2: SID=69 device type=DISK 
allocated channel: ORA_DISK_3 
channel ORA_DISK_3: SID=132 device type=DISK 
allocated channel: ORA_DISK_4 
channel ORA_DISK_4: SID=72 device type=DISK 
channel ORA_DISK_1: starting datafile copy 
input datafile file number=00001 name=/u01/app/oracle/rnwphoto/system01.dbf 
channel ORA_DISK_2: starting datafile copy 
input datafile file number=00002 name=/u01/app/oracle/rnwphoto/sysaux01.dbf 
channel ORA_DISK_3: starting datafile copy 
input datafile file number=00005 name=/u01/app/oracle/rnwphoto/example01.dbf 
channel ORA_DISK_4: starting datafile copy 
input datafile file number=00003 name=/u01/app/oracle/rnwphoto/undotbs01.dbf 
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 09/09/2015 11:12:22 
RMAN-10038: database session for channel ORA_DISK_1 terminated unexpectedly 
channel ORA_DISK_1 disabled, job failed on it will be run on another channel 
RMAN-03009: failure of backup command on ORA_DISK_2 channel at 09/09/2015 11:12:22 
RMAN-10038: database session for channel ORA_DISK_2 terminated unexpectedly 
channel ORA_DISK_2 disabled, job failed on it will be run on another channel 
RMAN-03009: failure of backup command on ORA_DISK_3 channel at 09/09/2015 11:12:22 
RMAN-10038: database session for channel ORA_DISK_3 terminated unexpectedly 
channel ORA_DISK_3 disabled, job failed on it will be run on another channel 
RMAN-00571: =========================================================== 
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== 
RMAN-00571: =========================================================== 
RMAN-03009: failure of backup command on ORA_DISK_4 channel at 09/09/2015 11:12:22 
RMAN-10038: database session for channel ORA_DISK_4 terminated unexpectedly 

ASM alertlog didnt show any errors or warnings.
In the database alertlog you will see that each time the RMAN command fails with  --> ORA-00600 [kfioTranslateIO03] [17090] 

A similar issue and it's resolution is shown in the Doc ID 1336846.1 
As per this document, this issue occurs due to multiple reasons and one of them is a permission issue... 

1. Check the group owner required on 'oracle' binary file to access ASM successfully:

[grid@node1-riz lib]$ cat $ORACLE_HOME/lib/config.c | grep ASM 
#define SS_ASM_GRP "asmadmin"     >>>> 
char *ss_dba_grp[] = {SS_DBA_GRP, SS_OPER_GRP, SS_ASM_GRP}; 

2. Let's check the group owner of all ORACLE_HOME/bin/oracle binary:

Grid Home:
[grid@node1-riz ~]$ ls -latr $GRID_HOME/bin/oracle 
-rwsr-s--x 1 grid oinstall 169802036 Sep 3 12:22 /u01/app/11.2.0/grid/bin/oracle 

RAC Database Home:
[oracle@node1-riz ~]$ ls -lart /u01/app/oracle/product/11.2.0/dbhome_2/bin/oracle -rwsr-s--x 1 oracle asmadmin 192296439 Sep 3 13:30 /u01/app/oracle/product/11.2.0/dbhome_2/bin/oracle

rnwphoto Standalone Database Home: 
[oracle@node1-riz ~]$ ls -lart $ORACLE_HOME/bin/oracle 
-rwsr-s--x 1 oracle oinstall 192296337 Sep 2 19:41 /u01/app/oracle/product/11.2.0/dbhome_1/bin/oracle 
>>>>> *****************************************************  <<<<<

Do you see it? If not, read ahead...

Point #1 states that 'asmadmin' should be the group owner of the $ORACLE_HOME/bin/oracle

Let's ignore the Grid Home findings - as that's not a part of the problem. It's just for your information.

RAC Database Home works fine with the ASM -- as the group owner of the 'oracle' binary is 'asmadmin'

Standalone Database Home was created much before there was a Grid Home, so it still has 'oinstall' as the group owner of the 'oracle' binary file. 

Solution:
In the Standalone Oracle Home, change the ownership of the 'oracle' binary from oracle:oinstall to oracle:asmadmin --- and WOOOLA !!! 

WARNING: You need a downtime to make this change. If you change the ownership without shutting the database(s), then expect all the databases running on that ORACLE_HOME to CRASH!!!