ORA-12899: value too large for column...

You may want to learn about a similar error message ORA-01438 caused by larger values being inserted in NUMBER columns. 
Message displayed with error ORA-12899 is self-explained. This error would come if you are trying to insert into a table’s column which is not big enough to hold the data being inserted. Suppose you define a column with a width of 10 characters (VARCHAR2(10)), and later if you try to insert a value longer than 10 characters, ORA-12899 would be returned. To solve this problem you can either reduce the data width being inserted, or alternatively increase the column width. If you have a multi-byte database characterset,  a VARCHAR2 column with a width of 10 may not store exactly 10 characters. Following is one example to produce ORA-12899.

DBUA Does not Find parameter file to Start Database for Upgrade

While upgrading my database form using database upgrade assistant (DBUA), it showed me error that said following

The Upgrade Assistant failed in bringing up the database <db_name>. Oracle Home <ORACLE_HOME> obtained from file /etc/oratab was used to connect to the database. Either database is not running from Oracle Home <ORACLE_HOME> or correct initialization Parameter file (pfile) was not found. To start the database, Oracle needs the pfile. Provide the full path name of the init file for the database <db_name>

Screenshot of DBUA can be seen bellow

PING[ARC1]: Heartbeat failed to connect to standby 'my_standby'. Error is 12154

If your primary database is not able to ship archived logs to the standby database with error ORA-12154, there is something wrong with the TNS entry you are using in LOG_ARCHIVE_DEST_n parameter that points to your standby database. If you check the alert log file of the primary database you will see error messages similar to the following.

kkjcre1p: unable to spawn jobq slave process, slot 2, error 1089

If you have initiated SHUTDOWN command to stop the database, new sessions cannot connect with the database. This means that even oracle scheduled jobs also cannot be initiated internally. After initiation of SHUTDOWN, if any scheduled jobs get initiated (because scheduled time of any job has reached), job would not be started and an error message will be logged in the alert log file. Following is how alert log would look like after that. Since this is just an information message, therefore  no action is needed.

ORA-39700: database must be opened with UPGRADE option

This message would appear if you have opened a database from a newer version ORACLE_HOME instead of the current version of the database. Alert logs shows messages similar to the following when you open your database with “startup open” command. Instance would immediately crash after logging these messages in the alert log file.

Poor Database Performance After Setting Huge Pages

I recently faced a problem whereby full memory of system got occupied after the database startup and eventually system was hung and reboot was inevitable. The recent change was to setting huge pages on the host. Eventually we found the reason that “soft memlock” was not set (oracle software owner name was wrongly spelled when specifying memlock in /etc/security/limits.conf file). Bu default “soft memlock” was set to a default value 64KB and none of huge pages was in use by the Oracle (SGA). As a result, SGA was allocated from the remaining memory (Huge pages would remain unused, yet allocated) and huge pages were merely consuming memory without any use. Following message in alert log let us understand the problem

Setting Huge Pages in Linux

If your Linux based database server has huge amount of physical memory, it will be a good idea to enable huge pages so that memory could be used efficiently by Oracle instance. Setting huge pages means that you have bigger sized (2 MB) memory blocks in memory to allocate to Oracle SGA. Bigger memory block size would mean fewer number of total memory blocks, and this is where managing memory becomes efficient by the OS. I would recommend to use/enable huge pages if host’s physical memory size goes beyond 128G. But you can also set huge pages even for a small amount of memory.

Migrating from Filesystem to ASM

While migrating from file system to ASM, we create ASM instance on the current host before we could stamp the disks and create asm diskgroups to migrate existing datafiles from the file system to the ASM. Before we create/start ASM instance, we need to start “Oracle Cluster Synchronization Service” (CSS). So, we initiate “dbca” to create/start ASM instance as a first step. If you are using Windows, invoke dbca application using right click and “Run as Administrator”.

Why Opatch Auto is not applying PSU on Database Home?

To apply a PSU we can download the required PSU and apply using “opatch apply” command of OPATCH utility. In RAC environment or Oracle restart environment (single node Grid Infrastructure installation), we would need to download “GI PSU” to patch the Grid Infrastructure home. We have option to download and apply “GI PSU” patch to both GI and RDBMS homes as well because GI PSU contains patch for both homes. In this case we use “opatch auto” (for 11g) or “opatchauto” (for 12c and above) command to be run as root user so that path can be applied on both homes. 

ORA-00245: control file backup failed; target is likely on a local file system

Your RMAN backup command may fail with ORA-00245 while backing up current control file as part of database backup. RMAN output along with the error message may look similar to the following. The highlighted in red is the actual cause of this error which I will explain later in this article and provide the solution for this.