database - Apps DBA Diaries

ORA-32771: Cannot Add File To Bigfile Tablespace

When trying to add a datafile to a tablespace , got the error – ORA-32771: cannot add file to bigfile tablespace.

SQL> ALTER TABLESPACE BIG_TBSP1 add datafile ‘+DATA/df01.dbf’ size 130G;
ALTER TABLESPACE BIG_TBSP1 add datafile ‘+DATA/df01.dbf’ size 130G;
*
ERROR at line 1:
ORA-32771: cannot add file to bigfile tablespace

SOLUTION:

A bigfile tablespace can contain only one datafile and no other datafile can be added to that.

SQL> select BIGFILE from dba_tablespaces where tablespace_name=’BIG_TBSP1’;

BIGFILE
———————– —
YES

How to increase space in Bigfile Tablespace?

BIGFILE tablespace stores its data in a single datafile with a much larger capacity.

We can resize the size of the datafile in BIGFILE tablespace using ALTER DATABASE Command

ALTER DATABASE DATAFILE ‘/+DATA/df0101.dbf’ RESIZE 180G;

Since BIGFILE Tablespace has only one datafile, there is no need to identify the datafile and increase its size.
We can use ALTER TABLESPACE command to resize at the tablespace level.

ALTER TABLESPACE BIG_TBSP1 RESIZE 180G;

What is the difference between Switchover and Failover in Oracle Dataguard?

A switchover means just switching roles between the primary database and standby db.
nswitchover, the primary database chnaged to a standby role, and the standby database changed to the primary role.
This is typically done for planned maintenance of the primary db server.

A failover is when the primary database fails and one of the standby databases is
transitioned to take over the primary role. Failover is performed only in the event
of a catastrophic failure of the primary database, and there is no possibility of
recovering the primary database in a timely manner. Failover may or may not result
in data loss depending on the protection mode in effect at the time of the failover.

How to mirror database Privileges of a Oracle database user to another database user?

Script for Mirroring Privileges of a user:

Scenario: A Database schema named “TEST2” is created and business wants to grant the privileges for the user same as already existing Database user “TEST1”.

Run the below queries as SYS or any Privileged user to get the DDL commands in Oracle for TEST1 user.

SELECT DBMS_METADATA.GET_GRANTED_DDL(‘ROLE_GRANT’,’TEST1′) FROM DUAL;

SELECT DBMS_METADATA.GET_GRANTED_DDL(‘SYSTEM_GRANT’,’TEST1′) FROM DUAL;

SELECT DBMS_METADATA.GET_GRANTED_DDL(‘OBJECT_GRANT’,’TEST1′) FROM DUAL;

The output will be a sequence of grant commands related to privileges assigned to TEST1 user. Now replace the string TEST1 with new user name “TEST2” and run the commands.

This will grant all privileges same as TEST1 user to TEST2 user in Oracle Database.

Change Oracle Database to ArchiveLog Mode

Steps to change the database to Archivelog Mode:

1. Login to the database server. Connect to sqlplus as sysdba

$sqlplus / as sysdba

2. Shutdown the database

SQL> shutdown immediate

3. Take a full database Backup (Cold Backup in this case)

4. Startup the database in mount stage

SQL> startup mount

5. Enable Archivelog mode

SQL> alter database archivelog;

6. Open the Database.

SQL> Alter database open;

7. Verify the changes.

SQL> archive log list;

Enable ArchiveLog Mode on Oracle RAC database fails with ORA-00265

On a test RAC environment, while archiving is being enabled, “ALTER DATABASE ARCHIVELOG” command errored with ORA-00265: instance recovery required, cannot set ARCHIVELOG mode

Below are the steps performed to enable Archivelog mode on a 3-node RAC database environment.

test0115:TEST1011 $ srvctl status database -d TEST101
Instance TEST1011 is running on node test0115
Instance TEST1012 is running on node test0116
Instance TEST1013 is running on node test0117
test0115:TEST1011 $
test0115:TEST1011 $ srvctl stop database -d TEST101

test0115:TEST1011 $ srvctl status database -d TEST101
Instance TEST1011 is not running on node test0115
Instance TEST1012 is not running on node test0116
Instance TEST1013 is not running on node test0117
test0115:TEST1011 $

test0115:TEST1011 $ srvctl start database -d TEST101 -o mount
test0115:TEST1011 $ srvctl status database -d TEST101
Instance TEST1011 is running on node test0115
Instance TEST1012 is running on node test0116
Instance TEST1013 is running on node test0117
test0115:TEST1011 $

test0115:TEST1011 $ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Sat May 9 14:13:54 2020

Copyright (c) 1982, 2013, Oracle. All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 – 64bit Production
With the Partitioning, Real Application Clusters and Automatic Storage Management options

SQL> select name,open_mode from gv$database;

NAME OPEN_MODE
——— ——————–
TEST101 MOUNTED
TEST101 MOUNTED
TEST101 MOUNTED

SQL>SQL> alter database archivelog;
alter database archivelog
*
ERROR at line 1:
ORA-00265: instance recovery required, cannot set ARCHIVELOG mode

Solution:
=========

1. Shutdown the database cleanly

SQL> shutdown immediate (on 3 RAC nodes)

2. Startup the database in mount stage

SQL> startup mount

3. Enable Archivelog mode

SQL> Alter database archivelog;

Database altered.

4. Open the database

SQL> Alter database open.

5. Verify archielog mode is enabled.

SQL> ARCHIVE LOG LIST;

Impdp fails with error ORA-31604

Issue:

When tried to Import a table from one Oracle database to another using IMPDP utility,encountered the error ORA-31604: invalid transform NAME parameter “MODIFY” for object type PROCACT_INSTANCE in function ADD_TRANSFORM

Impdp logfile has the below error:

Starting “<LOGIN_SCHEMA>”.”SYS_IMPORT_FULL_10″: <LOGIN>/******** parfile=<PARFILE_NAME>.par logfile=<LOG_NAME>.log dumpfile=<DUMPFILE_NAME>.dmp parallel=1

Processing object type TABLE_EXPORT/TABLE/PROCACT_INSTANCE

ORA-39126: Worker unexpected fatal error in KUPW$WORKER.LOAD_MD_TRANSFORMS []

ORA-31604: invalid transform NAME parameter “MODIFY” for object type PROCACT_INSTANCE in function ADD_TRANSFORM

ORA-06512: at “SYS.DBMS_SYS_ERROR”, line 86

ORA-06512: at “SYS.KUPW$WORKER”, line 8996

Cause: This is a bug in Oracle Database versio 11g, fixed in Oracle Database version 12c

Solution:

As a workaround, implement any of the below solutions:

1. Use an additional parameter that is exclude=PROCACT_INSTANCE during impdp

2. Redo the export with exclude=PROCACT_INSTANCE and perform import using new dumpfiles.

The use of the exclude=PROCACT_SYSTEM will exclude the resource manager objects such as resource plans and groups. We need to re-create resource plans and groups after impdp is successfully completed.

How to check if MRP Process is Running

Below Query is Used to verify if MRP process is running fine on Standby Database, after any maintenance activity that requires disconnect to Primary and Standby database.

SQL> SELECT CLIENT_PROCESS, PROCESS, THREAD#, SEQUENCE#, STATUS FROM V$MANAGED_STANDBY;

Below is the sample output from the query:

SQL> SELECT CLIENT_PROCESS, PROCESS, THREAD#, SEQUENCE#, STATUS FROM V$MANAGED_STANDBY;

CLIENT_P PROCESS THREAD# SEQUENCE# STATUS

——– ——— ———- ———- ————

ARCH ARCH 2 101072 CLOSING

ARCH ARCH 0 0 CONNECTED

ARCH ARCH 1 298101 CLOSING

ARCH ARCH 2 103073 CLOSING

ARCH ARCH 3 95398 CLOSING

ARCH ARCH 1 296100 CLOSING

ARCH ARCH 3 95399 CLOSING

ARCH ARCH 3 95400 CLOSING

ARCH RFS 0 0 IDLE

LGWR RFS 2 101074 IDLE

LGWR RFS 1 296102 RECEIVING

UNKNOWN RFS 0 0 IDLE

LGWR RFS 3 95401 IDLE

UNKNOWN RFS 0 0 IDLE

17 rows selected.

Convert Physical database into a Snapshot Standby Database

What are the benefits of Snapshot standby database?

Snapshot Standby Database is introduced from Oracle 11gR1. A Snapshot Standby database is a physical standby that is temporarily disconnected from Data Guard configuration, and started in READ-WRITE mode.It functions as a updateable Stand-alone Database, which is an exact Replica of Primary Database which is normally used for testing purpose. We can revert the Snapshot standby database to Physical Standby database after the testing is completed.

Steps to convert Physical database into a Snapshot Standby Database:

1. First step to convert to Snapshot standby database is to enable FLASHBACK feature on the Physical Standby, if not already enabled.

Ensure there is sufficient space available in Flash Recovery Area (FRA) for Flashback Logs.

2. Stop redo apply on the physical standby database:

SQL>alter database recover managed standby database cancel;

3. Turn on flashback logging:

SQL>alter database flashback on;

4. Convert the standby database into a snapshot standby database:

( For RAC Configurations: Shutdown all other instances except one, which is used as Snapshot standby database)

SQL>alter database convert to snapshot standby;

5.Shut down the snapshot standby database and startup the database (it will be opened for read/write access):

SQL>shutdown immediate;

SQL>startup

After the Snapshot mode is enabled on the database, perform the required testing and revert back to Physical Standby mode after the testing is complete.

Steps to Revert the Physical Standby Database Back to its Original State

1. Change the standby database back into its standby mode (from snapshot mode) as follows:

SQL>startup mount force;

SQL>alter database convert to physical standby;

SQL>shutdown immediate;

SQL>startup nomount;

SQL>alter database mount standby database;

2. Enable redo log apply.

SQL>alter database recover managed standby database using current logfile disconnect;

3.On the primary database, issue the following statement to re-enable archiving to the physical standby database:

SQL>alter system set log_archive_dest_state_2=enable scope=both;