Database With SanGa

Error Description: During the recovery process on the standby database, you encounter errors such as: ORA-01111 : Name for data file is unknown. ORA-01110 : Data file is missing. ORA-01157 : Cannot identify/lock data file. These errors typically occur when a data file is created as "UNNAMED" in the $ORACLE_HOME/dbs directory, causing the Managed Recovery Process (MRP) to fail. Error Log: Errors in file /home/app/diag/rdbms/sandy04/SANDY/trace/SANDY_ora_59972.trc: ORA-01111: name for data file 30 is unknown - rename to correct file ORA-01110: data file 30: '/home/app/product/11.2.0/db_1/dbs/UNNAMED00030' ORA-01157: cannot identify/lock data file 30 - see DBWR trace file ORA-01111: name for data file 30 is unknown - rename to correct file ORA-01110: data file 30: '/home/app/product/11.2.0/db_1/dbs/UNNAMED00030' Completed standby crash recovery. Reason: The issue arises because the MRP process, while applying archives, creates an unnamed fi...

In the realm of disaster recovery (DR) planning, calculating the network bandwidth required for Oracle Data Guard is paramount. Ensuring seamless replication and efficient data synchronization between primary and standby databases hinges on accurate bandwidth estimations   Understanding Redo Generation Rate At the heart of bandwidth calculation lies the average redo generation rate per second in the database. To ascertain this crucial metric, one approach is to query the DBA_HIST_SYSMETRIC_SUMMARY table:   SELECT AVG(MAXVAL) FROM DBA_HIST_SYSMETRIC_SUMMARY WHERE METRIC_NAME=’Redo Generated Per Sec’;   This query yields the average of maximum summary redo generation values over a period, providing a reliable baseline for bandwidth computation.   Bandwidth Calculation Formula   Required bandwidth = ((REDO rate (in bytes per second) / 0.75) * 8) / 1,000,000 (in Mbps)   Here, the redo rate in bytes per second is divided by 0.75 to ac...

  I faced an error [FATAL] [DBT-50000] Unable to check for available memory and [FATAL] [DBT-50001] Unable to check the value of kernel parameter {0}. Then terminated operation when I was going to create 12c instance in silent mode.   ERROR: [FATAL] [DBT-50000] Unable to check for available memory. [FATAL] [DBT-50001] Unable to check the value of kernel parameter {0}   REASON:   It’s a bug. Can find details about this in the following document.   DBCA fails with errors: [FATAL] [DBT-50000] Unable to check for available memory in “Specify configuration option” (Doc ID 2631718.1)   SOLUTION: Run dbca with “-J-Doracle.assistants.dbca.validate.ConfigurationParams=false”   ACTION: dbca -J-Doracle.assistants.dbca.validate.ConfigurationParams=false -createDatabase -silent -responseFile ./dbca.rsp   OUTPUT: Prepare for db operation 10% complete Copying database files 40% complete Creating and starting Oracle instance 42% ...

I faced an error [FATAL] [DBT-10503] Template file is not specified and terminated operation when I was going to create 12c instance in silent mode .   ERROR: [FATAL] [DBT-10503] Template file is not specified.   REASON: This is due to the you are not set the “templateName” in response file.   SOLUTION: Set templateName=General_Purpose.dbc and execute the dbca again   ACTION: 1.        Open the dbca.rsp and set templateName as General_Purpose.dbc 2.        Save the dbca.rsp 3.        Execute the instance create statement again (dbca)

  I faced an error [FATAL] [INS-30060] Check for group existence failed and terminated operation when I was going to install 12c binary in silent mode.   ERROR: [FATAL] [INS-30060] Check for group existence failed.    CAUSE: Unexpected error occurred while trying to check for group existence.    ACTION: Refer to the logs or contact Oracle Support Services. Note for advanced users: Launch the installer by passing the following flag '-ignoreInternalDriverError'. Moved the install session logs to:   REASON: The source and the target filesystems are not mounted with the same ACL options so the copy fails as the permissions cannot be preserved on the target filesystem.   SOLUTION: Export the TMPDIR to the suitable location and execute the runInstaller again.   ACTION: export TMPDIR=/path/to/temp

I faced an error last night when I was going to start my 12c database on upgrade mode   to upgrade 19c.   ERROR: ORA-01092: ORACLE instance terminated. Disconnection forced ORA-30012: undo tablespace 'UNDOTBS1' does not exist or of wrong type Process ID: 3714866 Session ID: 434 Serial number: 1850 ORA-00603: ORACLE server session terminated by fatal error   REASON: ORA-30012 means that the default UNDO tablespace you specified in SPFILE or PFILE does not exist, or it's not an UNDO tablespace essentially. Therefore, the database fails to startup. SOLUTION: We should identify and set the correct undo tablespace name.   ACTION: 1. log in the database on mount mode   SQL> startup mount; ORACLE instance started.   Total System Global Area 1.2482E+10 bytes Fixed Size                   8939000 bytes Variable Size      ...

I faced an error last night when I was going to recover my 12c database after restoration new environment.   ERROR: RMAN-03002: failure of recover command at 11/28/2023 06:12:57 RMAN-11003: failure during parse/execution of SQL statement: alter database recover logfile '/path/to/recovery file destination/o1_mf_1_235860_lpbxjrbh_.arc' ORA-00379: no free buffers available in buffer pool DEFAULT for block size 16K   REASON: There has been no memory allocated to 8K or 16K or 32K block buffers cache. Explicitly allocating memory to the non-default block buffers will resolve the ORA-00379: no free buffers available in buffer pool DEFAULT for block size 8K or 16K or 32K errors   ACTION: 1. log in the database 2. check parameter DB_16K_CACHE_SIZE and set value   SQL> show parameter DB_16K_CACHE_SIZE;   NAME                       ...

----------------------------------------------------------------------------------------------------------------------------- To increase the size limit of the Datafile, use the following SQL command: Increasing the Size Limit ALTER DATABASE DATAFILE '/U01/ORADATA/SANGA.DBF' AUTOEXTEND ON MAXSIZE 4096M; In this command, we are adjusting the maximum size of the Datafile to 4096MB (4GB). This change ensures that the Datafile can automatically extend its size up to the specified limit when it reaches capacity.   Removing the Size Limit In certain scenarios, you may want to remove the size limit altogether to allow the Datafile to grow without any restrictions. To achieve this, use the following SQL command in Oracle Database Enterprise Manager: ALTER DATABASE DATAFILE ‘/U01/ORADATA/SANGA.DBF’ AUTOEXTEND ON MAXSIZE UNLIMITED; With this command, the size limit on the Datafile is set to "UNLIMITED," allowing it to grow dynamically without any predefined rest...

STANDBY LOGS Get relevant details from primary side SQL> select GROUP#,BLOCKSIZE,THREAD# from v$standby_log;     GROUP#  BLOCKSIZE    THREAD# ---------- ---------- ----------          9        512          1         10        512          1         11        512          1         12        512          1         13        512          1         14        512          2         15        512          2         16        512          2   ...

Install the following packages if they are not already present. yum install binutils-2*x86_64* yum install glibc-2*x86_64* nss-softokn-freebl-3*x86_64* yum install glibc-2*i686* nss-softokn-freebl-3*i686* yum install compat-libstdc++-33*x86_64* yum install glibc-common-2*x86_64* yum install glibc-devel-2*x86_64* yum install glibc-devel-2*i686* yum install glibc-headers-2*x86_64* yum install elfutils-libelf-0*x86_64* yum install elfutils-libelf-devel-0*x86_64* yum install gcc-4*x86_64* yum install gcc-c++-4*x86_64* yum install ksh-*x86_64* yum install libaio-0*x86_64* yum install libaio-devel-0*x86_64* yum install libaio-0*i686* yum install libaio-devel-0*i686* yum install libgcc-4*x86_64* yum install libgcc-4*i686* yum install libstdc++-4*x86_64* yum install libstdc++-4*i686* yum install libstdc++-devel-4*x86_64* yum install make-3.81*x86_64* yum install numactl-devel-2*x86_64* yum install sysstat-9*x86_64* yum install compat-libstdc++-33*i686* yum install compat-libcap*

The following packages are listed as required, including the 32-bit version of some of the packages.  # OL6 and OL7 (RHEL6 and RHEL7) yum install binutils -y yum install compat-libcap1 -y yum install compat-libstdc++-33 -y yum install compat-libstdc++-33.i686 -y yum install glibc -y yum install glibc.i686 -y yum install glibc-devel -y yum install glibc-devel.i686 -y yum install ksh -y yum install libaio -y yum install libaio.i686 -y yum install libaio-devel -y yum install libaio-devel.i686 -y yum install libX11 -y yum install libX11.i686 -y yum install libXau -y yum install libXau.i686 -y yum install libXi -y yum install libXi.i686 -y yum install libXtst -y yum install libXtst.i686 -y yum install libgcc -y yum install libgcc.i686 -y yum install libstdc++ -y yum install libstdc++.i686 -y yum install libstdc++-devel -y yum install libstdc++-devel.i686 -y yum install libxcb -y yum install libxcb.i686 -y yum install make -y yum install nfs-utils -y yum install net-tools -y yum install ...

On the primary database, create the control file for the standby database, as shown in the following example: SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/stby.ctl'; Note: You cannot use a single control file for both the primary and standby databases. The filename for the newly created standby control file must be different from the filename of the current control file of the primary database.  The control file must also be created after the last time stamp for the backup datafiles.

  What is MRP in Oracle database? Managed recovery process (MRP) The managed recovery process (MRP) applies information from the archived redo logs to the standby database.  When performing managed recovery operations, log apply services automatically apply archived redo logs to maintain transactional synchronization with the primary database. Start the apply process on standby server. # Foreground redo apply. Session never returns until cancel.  ALTER DATABASE RECOVER MANAGED STANDBY DATABASE; # Background redo apply. Control is returned to the session once the apply process is started. ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; If you need to cancel the apply process, issue the following command. ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; If you prefer, you can set a delay between the arrival of the archived redo log and it being applied on the standby server using the following commands. ALTER DATABASE RECOVER MANAGED STANDBY ...

To unlock a user in Oracle, you need to follow these steps:    1. log in to the Oracle Database as a SYS user.    2. use ALTER USER statement to unlock the user:        ALTER USER <username> IDENTIFIED BY <password> ACCOUNT UNLOCK; NOTE: if you unlock an account without resetting the password, then the password remains expired, therefore, the IDENTIFIED BY password clause is necessary.  The first time the user logs in to the Oracle Database, he needs to change his password.