Fatal NI connect error 12541

If you see this error message in the alert log file of your primary database in a dataguard environment, it is most likely that listener on the standby database host(s) is not running. As a result, primary database will not be able to ship redo data to the standby database. This failure of log shipping will add lines similar to the following in the alert log file of the primary database.

Fatal NI connect error 12547, connecting to:

Sometimes you may see following error message in your alert log file. There is a similar Fatal NI error 12537 that appears in the alert log file when session exists during the session creation phase. But error 12547 comes when session terminates abnormally. For example, client application crashes without properly exiting the database, or sessions gets disconnected because of a network disconnection.

How to Enable Block Change Tracking

In RMAN incremental backup strategy, enabling block change tracking significantly increases incremental RMAN backups performance by helping RMAN to find out only changed/modified blocks (since last full backup) very fast, because only these are the blocks to be backed up during an incremental backup. List of these blocks (changed since last full backup) is maintained in the block change tracking file. In this article I will explain how to enable block change tracking.

ORA-16179: incremental changes to "log_archive_dest_1" not allowed with SPFILE

This error comes when you use wrong syntax while setting log archive destination using   log_Archive_dest_n parameter.  I faced this error while trying to set log_archive_dest_1 parameter using ALTER SYSTEM command and the reason of this error was that I missed the keyword “location=” while specifying the destination directory. But this error may also come because of other syntax errors in the command while setting the parameter.     

ORA-01261: Parameter db_recovery_file_dest destination string cannot be translated

DB_RECOVERY_FILE_DEST parameter is used to set Fast Recovery Area for the instance and  archived logs, flashback logs, and RMAN backups are kept at this location and are automatically handled by the database. While using ALTER SYSTEM command to set db_recovery_file_dest parameter you might face following error.

ORA-00257 archiver error

There are a several archived log errors that exist, and there are several different reasons for these errors as well. As we know that redo log groups are used in a circular fashion and redo logs are reused again and again. After every log switch, the previous redo log file is archived (if database is running in archivelog mode). If oracle is not able to create an archived log file after a redo log switch ORA-00257 would appear, and after a few more redo log switches the turn of this redo log file would come again. Since oracle was not able to archived this redo log previously, it will not overwrite this redo log and database would hang. This redo log must be archived before it could be reused. Alert log would who errors as follows if it is not able to create an archived log file

ORA-48913: Writing into trace file failed, file size limit...

In some environments DBAs limit the size of trace files generated by the database. This included all trace files that could get generated under USER_DUMP_DEST/DIAGNOSTIC_DEST). The parameter to set the limit for trace files is MAX_DUMP_FILE_SIZE and its value is in OS number of blocks. After setting this value, if any trace file size would increase form the size specified in this parameter, ORA-48913 would be recorded in alert log file.

Creating services with srvctl

In a RAC environment we can create services and run these services on a specific RAC instance/node (or a set of instances/nodes). This makes it possible for the applications to connect to specific instances. In this article I would explain how we create a service and make it run on the instance(s) of our choice, and make it automatically failover to another instance/node if current instance node goes down.

How to Add and Remove database to CRS or Oracle Restart

In RAC or Oracle Restart environment we can use “srvctl” command to add resources to CRS for automatic management of the resources. In this article I would explain how we remove and add a database resource to CRS in RAC environment. Same process can be used for single instance database in Oracle Restart environment. These steps are needed to be executed as RDBMS software owner “oracle”. Starting 12c, single letter options (-d, -i, etc.) can still be used, but probably these would be made obsolete in coming releases because full length option (-db, -instance etc.) have been introduced and I will use these full length options here.

CRS-0245: User doesn't have enough privilege to perform the operation

Reason of CRS-0245 is that you are executing “srvctl” command to perform a task that is not authorized for current logged in user. For example, I was trying to remove a RAC database from CRS using srvctl and I faced this error because I was executing this command as “grid” user whereas I was supposed to execute this command as “oracle” user that is RDBMS software owner.