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.

ORA-17503 ORA-27140 ORA-27300 ORA-27301 ORA-27302

ORA-00210: cannot open the specified control file
ORA-00202: control file: '+DATA/mydb/controlfile/current.257.918811113'
ORA-17503: ksfdopn:2 Failed to open file +DATA/mydb/controlfile/current.257.918811113
ORA-15001: diskgroup "DATA" does not exist or is not mounted
ORA-15055: unable to connect to ASM instance
ORA-27140: attach to post/wait facility failed
ORA-27300: OS system dependent operation:invalid_egid failed with status: 1
ORA-27301: OS failure message: Operation not permitted
ORA-27302: failure occurred at: skgpwinit6
ORA-27303: additional information: startup egid = 1000 (oinstall), current egid = 1031 (dba)
ORA-00210: cannot open the specified control file
ORA-00202: control file: '+DATA/mydb/controlfile/current.256.918811111'
ORA-17503: ksfdopn:2 Failed to open file +DATA/mydb/controlfile/current.256.918811111
ORA-15001: diskgroup "DATA" does not exist or is not mounted
ORA-15055: unable to connect to ASM instance
ORA-27140: attach to post/wait facility failed
ORA-27300: OS system dependent operation:invalid_egid failed with status: 1
ORA-27301: OS failure message: Operation not permitted
ORA-27302: failure occurred at: skgpwinit6
ORA-27303: additional information: startup egid = 1000 (oinstall), current egid = 1031 (dba)

Managing ASM Power Limit During Disk Re-balance

While adding or removing disks to/from a diskgroup, ASM does a re-balance of allocation units (ASM extents); we can specify a power limit of this re-balance. Power limit is used to handle the workload of re-balancing in a way that it does not interfere the normal operation of our database and does not slow down IO operations. Following are some important points to note about rebalance power limit.

ORA-01503: CREATE CONTROLFILE failed with ORA-01192

There could be several reasons for facing ORA-01503 while creating a new controlfile. When we plan to create a controlfile, we can write our own script, but creating a script using “ALTER DATABASE BACKUP CONTROLFILE TO TRACE” command generates a perfect script for us and we do not need to write script ourselves. In the following I will discuss a scenario where I ORA-01503 and how I solved it.

ORA-01126: database must be mounted in this instance and not open in any instance

There are certain administration tasks that need database to be mounted, not open, while performing the task, otherwise ORA-01126 would be returned. In the following I am explaining one of those operations that returned me ORA-01126 because I had my database open while converting my database to archivelog mode.

RMAN-03009 and ORA-19510: failed to set size of 92079 blocks for file

If you RMAN backup commands are failing with RMAN-03009 with ORA-19502 and ORA-19510, it is because your destination file system has no space left on it for the backup. You need to make sure that file system where you are storing backup should have sufficient space to host the backup. Output of command may be similar to the following