Oracle Exadata: AIDE, Advanced Support Gateway and Exadata Image 19

Oracle Exadata: AIDE, Advanced Support Gateway and Exadata Image 19

Exadata Vineet Sachdeva   September 05, 2019

Oracle has released Image 19 and AIDE, however what they really missed is the platinum / advanced support gateway

the advanced support gateway is present as user orarom in directory /opt/OracleHomes

Now if you are getting daily alerts from AIDE complaining a lot of files have changed. 
Then look into the log file /var/log/aide/aide.log, you will find that the log files of agent are changed which are continously throwing the alerts 

What you need to do is add one line in the aide.conf file which is highlighted as below and then run exadataAIDE -u. 

This will ignore the directory and ensure no alerts are been sent. 


less aide.conf | grep opt
!/opt/OracleHomes

/opt/    CONTENT

Oracle Database: TFACTL Blackout ORA-600/7445/700

Oracle Database: TFACTL Blackout ORA-600/7445/700

Admin Vineet Sachdeva   August 21, 2019

tfactl or oracle's trace file analyzer utility can be really helpful sometimes, and also a lot of pain in many, when it sends a lot of alerts some of which you know and it's a known issue or you don't want to do anything about it. 

Fortunately, you can blackout such events from tfactl 

To supppress a specific string ORA-0600 this is what I would do. 

tfactl blackout add -targettype database -target mydb -c -event  "kewrspbr_2"  -timeout none -reason "skipping ORA-0600 Doc ID 2313603.1" 

where 

-target : dbname

-c : clusterwide

-event: String contained in the event (find it from the email you got)

-timeout : no timeout

Similarly, you can play around with the parameters and blackout a lot of unwanted emails.
You can find them documentation below. 


Reference - https://docs.oracle.com/en/engineered-systems/health-diagnostics/trace-file-analyzer/tfaug/running-administration-commands.html#GUID-56A03EC7-3324-48BD-9701-2411626D16CB

Oracle Exadata: DBM-02643: DROP ALERTHISTORY command did not include all members of the alert sequence for *_*

Oracle Exadata: DBM-02643: DROP ALERTHISTORY command did not include all members of the alert sequence for *_*

Exadata Vineet Sachdeva   August 16, 2019

In this blog I am going to discuss an error message which you might get when dropping individual alerts via dbmcli or cellcli in Exadata

if you try to drop your alert using a command like below 
drop alerthistory  2_1, 2_2, 2_3, 2_4, 2_5, 2_6, 2_7, 2_8, 2_9, 2_10, 2_11, 2_12, 2_13

and you get an error message which is something like 

DBM-02643: DROP ALERTHISTORY command did not include all members of the alert sequence for 2_1. All members of the sequence must be dropped together

That means you have not selected all the 2_* members, so, in order to proceed put all the 2_* members or the sequence you are trying to drop. 

This will clear the alert.

Oracle Database: Permissions to Execute Job Class

Oracle Database: Permissions to Execute Job Class

OracleScheduler Vineet Sachdeva   August 02, 2019

There is a great mis conception in DBA's who primarily work on OLTP about Job classes.

Job classes are one of the essentially used components in job definitions which people seldom use and seldom know about. 

This blog however is a small and nice one which talks about how to see permissions to execute a job class.

Yes you read that right. You need execute permission for a job class. 
Only if you have execute permission to job class, you will be able to add it to your create job. 

the way to grant is same 

Grant execute 'on job class' to <user>';

to verify you should use dba_tab_privs to know if your user has execute privilege on job class or not. 

select * from dba_tab_privs where grantee = '<your user>' and type = 'JOB CLASS';

Example output below (from TOAD)

By default permission to execute 'DEFAULT JOB CLASS' is granted to PUBLIC, so you if you do not specify any job class name, default job class will be taken and it will be okay. 

Oracle Database - 19c Important Documentation and Patch Information

Oracle Database - 19c Important Documentation and Patch Information

Upgrade Vineet Sachdeva   June 13, 2019

In this blog I discuss important documentation on Database 19c. 
It lists the important links which you require when thinking of Database 19c. 


This list is quite handy for Database Administrators of 19c when planning new installation, upgrade or finding about new features of 19c.

The Patch information in the end (point 5) is a quick link to find and download the Patches for this release. 

1. Oracle Database 19c Documentation 
2. Oracle Database 19c tutorials
3. Oracle 19c - Complete Checklist for Manual Upgrades to Non-CDB Oracle Database 19c - DocID 2539778.1
4. Oracle 19c - Complete Checklist for upgrading Oracle 12c, 18c Container Database (CDB) to Oracle 19c Release using DBUA - Doc ID 2543981.1
5. Oracle 19c - Complete Checklist for Upgrading to Oracle Database 19c (19.x) using DBUA - Doc ID 2545064.1
6. 18c & 19c Physical Standby Switchover Best Practices using SQL*Plus -  Doc ID 2485237.1
7. DBCA Silent Mode New features in Database 19C - Doc ID 2477805.1
8. Assistant: Download Reference for Oracle Database/GI Update, Revision, PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases Doc ID 2118136.2
9. Desupport of Oracle Real Application Clusters (RAC) with Oracle Database Standard Edition 19c - Doc ID 2504078.1

Oracle Database: Flashback RAC Primary and Standby

Oracle Database: Flashback RAC Primary and Standby

DGBroker Vineet Sachdeva   June 11, 2019

In this blog I am going to discuss on how to flashback a RAC Primary and RAC Standby both and ensure Standby is in sync. 
These are for some maintenance activities you might want to perform on Primary and to have a rollback plan. 
You can re-order few steps if you ant


My primary Database name is PRIM and Standby is STDBY.

Step 1 and 2 are setup for the flashback. 

Step 1  - Stop the apply on STDBY
dgmgrl /
edit datbase 'STDBY' set state 'APPLY-OFF'

Step 2 - Create GRP (Guranteed Restore Point)
i. Switch logfile on Primary (alter system archive log current) 
ii. Create GRP on Standby (Create Restore  Point BEFORE_RELOAD GUARANTEE FLASHBACK DATABASE)
iii. Create GRP on Primary  (Create Restore  Point BEFORE_RELOAD GUARANTEE FLASHBACK DATABASE)
iv. take output of select * from v$restore_point and note the scn


Now do your changes (patching etc), assuming your changes were not successful and you want to rollback.  

Step 3 - Do the Flashback
i. Stop Database Primary (srvctl stop database -d PRIM)
ii. Start one instance in mount (startup mount exclusive)
iii. Flashback Database (flashback database to restore point BEFORE_RELOAD);
iv. alter database open reset logs

Step 4 - Start Primary (all nodes)
i. srvctl start database -d PRIM


Step 5 - Flashback Standby 
i. Check the current_scn (select current_scn from V$database)
ii. if current_scn of Standby is less than 2.iv, i.e scn of GRP on primary then you need not to do any flashback and can skip
iii. If current_scn is greater then you have 2 options
First - srvctl stop database -d STDBY and then startup mount exclusive for 1 instance
Then - 
    a. Flashback to scn of the GRP of primary (flashback database to scn <> )
    b. Flashback to scn of the GRP of standby (flashback database to restore point BEFORE_RELOAD). This assumes the scn of standby GRP is less than scn of primary GRP
iv. start DB (srvctl stop database -d CHMSTDBY, and srvctl start database -d CHMSTDBY)
v. Ensure apply is working fine. (edit database 'STDBY' set state='APPLY-ON')

Step 6 - Finally Drop Restore Points
i. Primary - Drop restore point BEFORE_RELOAD
ii. Standby - for this you will have to have database is mount mode (in case your standby was read only) and then 'drop restore point BEFORE_RELOAD'

References: How To Flashback Primary Database In Standby Configuration (Doc ID 728374.1)