ORA-01031: insufficient privileges

Error: ORA-01031: insufficient privileges

Details: Occurred when attempting to shutdown the database using SHUTDOWN ABORT while logged in as oracle user.

Solution:
The solution was quite simple: exit sqlplus and login again as sysdba

ORA-12537: TNS:connection closed - standby error in DGMGRL

Error: ORA-12537: TNS:connection closed

Details: Occurred on a standby database after switchover from primary to standby. Error came up when checking DataGuard broker configuration.

Cause: The mrp process not running on standby
Solution:
Checked if MRP process was running on standby by executing:

ps -ef | grep mrp

Nothing was running.
Performing regular maintenance on standby database fixed the issue

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP NOMOUNT;
SQL> ALTER DATABASE MOUNT STANDBY DATABASE;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; 

Warning: ORA-16826: apply service state is inconsistent with the DelayMins property

Error: Warning: ORA-16826: apply service state is inconsistent with the DelayMins property

Details: Gotten this warning after switching over from primary to standby. All redo logs were applied and no errors showed up in alert log, but DataGuard shown the warning in standby

Cause:
Solution:
When I executed:

SELECT DEST_NAME,DATABASE_MODE,RECOVERY_MODE,PROTECTION_MODE,STATUS FROM V$ARCHIVE_DEST_STATUS
WHERE DATABASE_MODE='MOUNTED-STANDBY';

I'd get:

--------------------------------------------------------------------------
DEST_NAME           DATABASE_MODE   RECOVERY_MODE           PROTECTION_MODE      STATUS
--------------- ----------------------- -------------------- --------------
LOG_ARCHIVE_DEST_3  MOUNTED-STANDBY    MANAGED               MAXIMUM AVAILABILITY VALID

So RECOVERY_MODE came up as "MANAGED", meanwhile it should have been "MANAGED REAL TIME APPLY". Restarting MRP, as it was suggested by every source I could find, did not help and the next solution was to do that with NODELAY keyword:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;

That did not help either. I waited until next logfile switch but the warning was still there. Finally I decided to remove the standby database and then re-add and re-enable it but gotten an error on the attempt to remove it:

DGMGRL> remove database 'Stby';

Error: ORA-16627: operation disallowed since no standby databases would remain to support protection mode So my last resort was to disable and re-enable Data Broker configuration:

DGMGRL>disable configuration;

DGMDRL>enable configuration;

Then

DGMGRL>show configuration;

finally returned SUCCESS.

How to fix a DataGuard issue - logs do not ship from primary to standby

One way to check if logs get shipped and applied from primary to standby is by running the following query on both primary and standby databases:

select al.thrd "Thread",
almax "Last Seq Received",
lhmax "Last Seq Applied"
from (select thread# thrd, max(sequence#) almax
from v$archived_log
where resetlogs_change#=(select resetlogs_change# from v$database)
group by thread#) al,
(select thread# thrd, max(sequence#) lhmax
from v$log_history
where first_time=(select max(first_time) from v$log_history)
group by thread#) lh
where al.thrd = lh.thrd;

If there is a discrepancy between primary and standby, one way to fix it is by rolling forward the physical standby using RMAN incremental backups of the primary. Here is a document on how to do that.
On Standby:

1. Retrieve the current SCN number to be used for backing up database later on

   
   SQL> SELECT to_char(current_scn, '999999999999999999') FROM V$DATABASE;
   
   TO_CHAR(CURRENT_SCN
   -------------------
          XXXXXXXXXXX
   

2. Cancel the managed recovery on standby

   SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
   

Primary:
Connect to RMAN

rman

RMAN> connect target /

RMAN> BACKUP DEVICE TYPE DISK INCREMENTAL FROM SCN XXXXXXXX DATABASE FORMAT '/tmp/DBNameStandby_%U' tag 'DBNAMESTANDBY';

Standby:
Connect standby via RMAN and then connect to the catalog:

rman 

RMAN>connect target /

RMAN>connect catalog username/pwd@catalogname

RMAN>catalog start with '/tmp/DBNameStandby';

RMAN>REPORT SCHEMA;


RMAN>STARTUP FORCE NOMOUNT;
RMAN>RESTORE STANDBY CONTROLFILE FROM TAG 'DBNAMESTANDBY';
RMAN>ALTER DATABASE MOUNT;
RMAN>RECOVER DATABASE NOREDO;

If error occurs "ORA-19573: cannot obtain exclusive enqueue for datafile 5" when executing RECOVER DATABASE NOREDO; Run ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; via sqlplus on Standby
And finally run the following on the standby database via sqlplus:

SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

ORA-29283: invalid file operation

Error: ORA-29283: invalid file operation

Details: Error occurs when running a full data pump export

Cause:DATA_PUMP_DIR is not defined or defined incorrectly for that database Solution:Login to sqlplus as sysdba and execute:

CREATE OR REPLACE DIRECTORY DATA_PUMP_DIR as 'your dir path here';

SSIS Error : Failed to decrypt protected XML node "DTS:Password" with error 0x8009000B "Key not valid for use in specified state."

Error:Failed to decrypt protected XML node "DTS:Password" with error 0x8009000B "Key not valid for use in specified state.

Details: Error occurs after deploying SSIS package to another server

Cause:Incorrect package protection level specified - by default it is EncryptSensitiveWithUserKey
Solution:Change package protection level property to to EncryptSensitiveWithPassword, or EncryptAllWithPassword and provide the password

SSIS Error Code DTS_E_OLEDB_NOPROVIDER_64BIT_ERROR

Error: SSIS Error Code DTS_E_OLEDB_NOPROVIDER_64BIT_ERROR. The requested OLE DB provider OraOLEDB.Oracle.1 is not registered -- perhaps no 64-bit provider is available.

Details: Error occurs when attempting to run a SQL Agent job that runs SSIS package that opies data from Oracle to SQL Server

Cause:64 bit OLE DB provider Microsoft.Jet.OLEDB.4.0 is not installed on a 64-bit machine.
Solution:Run the SQL Agent job in 32 bit mode:

1. Right-click on the job name and select Properties
2. Go to Steps
3. Select the step your job fails on and click Edit
4. Select "execution optons" tab and check a "use 32 bit runtime" checkbox

[OLE DB Source [45]]: Cannot retrieve the column code page info from the OLE DB provider

Error: [OLE DB Source [45]]: Cannot retrieve the column code page info from the OLE DB provider. If the component supports the "DefaultCodePage" property, the code page from that property will be used. Change the value of the property if the current string code page values are incorrect. If the component does not support the property, the code page from the component's locale ID will be used.

Details: This error occurs attempting to view colmuns of an OleDB data source in a Data Flow task inside the Business Intelligence Development Studio, while attempting to do a data transfer between Oracle and SQL Server databases


Cause:It is actually only a warning that means that the data provider does not publish code pages used for text columns and also that SSIS does not do implicit conversions between Unicode and non-unicode strings

Solution:We can get rid of this warning by setting AlwaysUseDefaultCodePage property of the OLE DB Source Data Flow Component to True. It is set by default to False but can be changed easily from the Properties window in Business Intelligence Development Studio project.

ORA-31634: job already exists

Error: ORA-31634: job already exists ORA-31664: unable to construct unique job name when defaulted

Details: Error occurs when running a full data pump export

Cause:The table dba_datapump_jobs contains 99 orphaned jobs: The SQL below returns 99 rows:

select owner_name, job_name, state from dba_datapump_jobs order by job_name;

Solution:Remove the jobs that are not ruuning and purge them from recycle bin:

DROP TABLE OWNER_NAME.JOB_NAME;


PURGE DBA_RECYCLEBIN;


or


DROP TABLE OWNER_NAME.JOB_NAME PURGE;

ORA-19705: tag value exceeds maximum length of 31 characters

Error: ORA-19705: tag value exceeds maximum length of 31 characters

Details: This error occurs when running a backup

Cause:The database either crashed or was shutdown with the ABORT option. Media recovery cannot be enabled because the online logs may not be sufficient to recover the current datafiles.

Solution:Supply a shorter tag in the backup script and retry the operation.

ORA-00265: instance recovery required, cannot set ARCHIVELOG mode

Error: ORA-00265: instance recovery required, cannot set ARCHIVELOG mode

Details: This error occurs when switch databas eto ARCHIVELOG mode by executing:
ALTER DATABASE ARCHIVELOG;

Cause:The database either crashed or was shutdown with the ABORT option. Media recovery cannot be enabled because the online logs may not be sufficient to recover the current datafiles.

Solution:Open the database and then enter the SHUTDOWN command with the NORMAL or IMMEDIATE option:

>ALTER DATABASE OPEN;

>SHUTDOWN IMMEDIATE;