Checking Redo Log Switch and Redo Generating by Session

Focus of this article is to check the redo log switch frequency as well as the sessions causing huge redo logs generation. A sudden surge in archived log generation can make DBA look into the issue to find out since when redo log generation has spiked. Following is the query we can easily find everywhere on the internet to find out the redo logs switch frequency. Of course this is not written by me. I do not know who is the original writer of this query therefore I can refer to that great guy or website.

Dataguard out of sync OR Log shipping not working

 You can seek help from this (single node) and this (RAC) document for setting up dataguard. But if dataguard has become out of sync, there are several things that you might need to look at before you fix it. In the following I am providing a checklist that you can take a look to find out the issue and thus implement a solution.

ORA-17502 and ORA-15001

 If you are creating a file on an ASM diskgroup, and you receive ORA-17502 along with ORA-15001, there is one reason of ORA-15001 already explained here. Also check if diskgroup mounted. But, if diskgroup is mounted and yet you receive this error, another reason of this could be the ownership set for “oracle” executable found under the $ORACLE_HOME from where ASM instance is running. When we install Grid Infrastructure and RDBMS softwares using different users, (GI home owned by grid user and RDBMS home and oracle user), then it is required that group ownership of “oracle” executable under RDBMS home is set to SYSASM privilege OS group which is ASMADMIN.

ORA-15039 and ORA-15001 while Dropping an ASM disk group

I was trying to drop a diskgroup and failed with ORA-15039 and ORA-15000. Following is what was returned.

SQL> drop diskgroup oradata; drop diskgroup oradata * ERROR at line 1: ORA-15039: diskgroup not dropped ORA-15001: diskgroup "ORADATA" does not exist or is not mounted

ORA-15032 ORA-15040 ORA-15042 while mounting a diskgroup

 You may face these 3 error messages together if you are trying to mount an ASM diskgroup and one or more disks of this diskgroup are missing. In case of an external redundancy diskgroup, you need at least one ASM disk to be available to mount a diskgroup. For a normal redundancy diskgroup, you need at least 2 disks for the ASM diskgroup before it can be mounted. And in case of a high redundancy diskgroup, you need at least 3 disks to mount a diskgroup. After an ASM instance restart, an ASM diskgroup may not get mounted automatically if it is not fulfilling the requirements explained above.

ORA-65179: cannot keep datafiles for a pluggable database that is not unplugged

 

SQL> alter pluggable database pdb2 close; Pluggable database altered. SQL> drop pluggable database pdb2; drop pluggable database pdb2 * ERROR at line 1: ORA-65179: cannot keep datafiles for a pluggable database that is not unplugged

 

ORA-19809: limit exceeded for recover files

 I faced ORA-19809 when backup of one of my databases failed during archived log backup phase. In our backup script we had a statement “ALTER SYSTEM ARCHIVE LOG CURRENT” just before the backup command for archived redo logs. When ALTER SYSTEM ARCHIVE LOG CURRENT statement was executed, following error stack was returned.

ORA-10485: Real-Time Query cannot be enabled while applying migration redo

This error message may appear in the alert log file of standby database after an upgrade/PSU etc. is applied on the primary database and if real time apply is enabled on the standby database.

The procedure to apply a PSU or other (rolling) patches is that it is first applied on the standby database server and after that on the primary database, and any post patch (or upgrade) scripts are executed on the primary database. Once this completes, all database changes happened during patch/upgrade scripts execution are shipped through redo logs to the standby database and standby database eventually becomes in sync with the primary.

CORRUPTION DETECTED: In redo blocks starting at block in dataguard

If this error comes in dataguard (physical standby) database, oracle will automatically delete the corrupted archived log file and then we would require to copy the affected archived log from the primary site and so that managed recovery could proceed. I was thinking that oracle should automatically fetch the affected/corrupted archived log itself from the primary site, but then I realized the reason of not happening this automatically and I will explain the reason later.

Once this type of corruption is detected, following type of message is shown in the alert log file.

ORA-01093: ALTER DATABASE CLOSE only permitted with no sessions connected

For me, the reason of this error was that I tried to open a standby database and then tried to start the managed recovery in order to utilize active dataguard feature. First, I cancelled the managed recovery, then opened the standby database, and as soon as I execute the command to start managed recovery process, ORA-01093 popped up; as you can see below.

ddl_lock_timeout to avoid ORA-00054

I have a previous article available here that explains about ORA-00054 and the reason of this error, and alto the enhancement starting 12c to avoid this error. In this article I would further explain ORA-00054 and how to use an initialization parameter DDL_LOCK_TIMEOUT to avoid this error. Instead of returning this error because of a lock on the object, your DDL would keep waiting for the locks to be released and get executed automatically when object is available for the DDL operation.

ASM Disks not Reachable After Reboot - Manually Loading ASM Driver

After a system reboot if you see ASM disks are not available, and scanning ASM disk returns “Unable to instantiate disk”, as follows, it could be because oracleasm driver was not loaded and hence ASM did not work as expected. As a result, ASM disks will not be visible to ASM instance and ASM diskgroups would not mounted. Following is the example output of if you execute “oracleasm scandisks” command.

Not All Endpoints Registered

If issuing “crsctl status resource” command show the status of listener as “Not All Endpoints Registered”, it is usually because of contradictions in the Listener settings. It means that probably you have a manually setup listener (by editing listener.ora file) with different settings than registered with the CRS/HAS. Or, there could be multiple listeners configured from multiple oracle homes – one from Grid Infrastructure home, and other listener with same configuration running from other home and started manually (using lsnrctl command).

DBMS_AW_EXP: BIN$ZRGxDTT9TumIWFOmM0qIHQ==$0 not AW$

If you see any similar messages during expdp, you may ignore these messages. Alternatively, you may purge the recyclebin and initiate the expdp again. Issue “purge dba_recyclebin” from SQLPUS. The messages displayed in expdp log are as follows.

Initialization parameter setting back to original value

I faced a very strange situation whereby I was setting my log_archive_dest_1 parameter using ALTER SYSTEM command with SCOPE=BOTH, which meant that this parameter value change should have been consistent across the instances reboot as this change was also being made in the spfile (SPFILE was in use for that database/instance) as well as in memory. However, it was not happening actually. After every instance restart, the value of this parameter would again set to the old value and this was causing problems for us.

ORA-00972: identifier is too long

In Oracle 12.1 and below, the maximum length for the name of an object (Table, View, Procedure, Package, Function, Materialized View etc.) is 30 bytes (or 30 characters, if each character is of 1 byte as per character set used). Starting 12.2, name length has been increased to 128 bytes/characters. Likewise, the name of a column of a table or view should also not exceed the allowed length. In the following I am providing a few examples where we will see ORA-00972 error returned in 12.1 database

SQL Plan Management and SQL Baseline

Before you read this article, I would suggest you to read my articles about bind variable peeking and adaptive cursor sharing.

Starting 11g release, adaptive cursor sharing makes optimizer to generate and select multiple execution plans based on the bind variable values passed during the execution. Oracle also introduced SQL Plan Management feature starting 11g whereby the history of plans of an SQL is maintained in SQL Baseline and out of which one or more plans can become “accepted” and can be used for that SQL. This is our choice to make plan(s) “accepted” if think that plan is optimal. We may ignore sub-optimal plans. In this will explain SQL Plan Management using an example.

gc buffer busy acquire and gc buffer busy release

These two wait events are similar to ”buffer busy wait” that you might have observed which is recorded when a session tries to access a data block/buffer which is already being accessed by another session that is connected to the same instance and buffer is also in the current instance’s buffer cache. In RAC environment, if a session tries to read a buffer from a remote instance’s buffer cache but the buffer is already being read by a different session, a “gc buffer busy acquire” wait event is recorded. If a session tries to read a buffer from the buffer cache of local instance, but buffer is already being read into remote instance’s buffer cache from local cache by a session connected to that remote instance, a “gc buffer busy release” wait event is recorded.  

ORA-15046: ASM file name...is not in single-file creation form

We can use ASM provided command “cp” to copy files from file system to ASM diskgroup and vice versa; and also from one ASM diskgroup to the other. If you receive ORA-15046 while copying a file to an ASM diskgroup from file system, or from another diskgroup, mostly it is because you are providing a file name for the destination file that is not allowed in the ASM. From file name here I mean the file name in the format that is used in ASM i.e. file_name.235.84753829. Same error would also come if an invalid directory location is provided. Following is an example of this error message

DBA_TABLESPACE_USAGE_METRICS and CDB_TABLES_ACES_USAGE_METRICS

DBA_TABLESPACE_USAGE_METRICS and CDB_TABLESPACE_USAGE_METRICS (starting 12c) provide us summary of space usage of each tablespace including TEMP and UNDO tablespaces. Only different between these 2 views is same as between all other CDB* and DBA* views whereby CDB* views contain information from all PDBs that is viewable from root container and have an extra column CON_ID to correspond each row to a particular PDB. Using this view makes it very easy to analyze space usage. In this article I would explain how to get information from these dictionary views to check the utilization of space within the tablespace(s). You may also want to read my articles about Tablespace space usage history and forecast for 12c and above, and for 11g and 10g.

Adaptive Cursor Sharing

This feature was introduced in 11g release 1 to cater a performance issue caused by bind variable peeking. Adaptive cursor sharing means that if an SQL is submitted for execution that has bind variables, and it already has an execution plan in shared pool, still optimizer can generate a new execution plan based on the values passed in the bind variable this time. This means that on every call of an SQL, optimizer may use already available plans in the shared pool, or it may generate a new one that is more efficient based on the bind variable values.