Sunday, April 16, 2023

Best Practices for Administering and Resetting Pluggable Databases on An Oracle RAC System

Best Practices for Administering and Resetting Pluggable Databases on An Oracle RAC System




Introduction

Oracle Real Application Clusters (RAC) is an Oracle database solution that allows multiple instances of a single Oracle database to run across different nodes in a cluster. This provides advantages such as high availability and scalability, allowing the system to remain available even if one node fails or becomes unavailable. A Pluggable Database (PDB) can be started, stopped, restarted or removed from the RAC environment without impacting other databases hosted on the same system. Restarting a PDB in RAC is necessary when changes have been made to its configuration settings and need to take effect, or if it has become corrupted due to errors or faults occurring during normal operations. It's important for administrators of an Oracle RAC system to understand best practices for administering and resetting pluggable databases in order for them to ensure optimal performance of their systems.

The Prerequisites for Restarting a PDB in RAC

Before restarting a PDB in RAC, administrators should make sure that all databases in the cluster are running. This is because any changes made to one database may affect other databases on the same system or cluster. It's also important for administrators to check if Oracle Clusterware is configured and started properly before initiating a restart of the PDB. The Clusterware provides services such as managing nodes, network connections, and shared storage across multiple systems; it must be correctly set up to ensure optimal performance of an Oracle RAC environment. Additionally, ensuring that any applicable patches have been applied prior to restarting a PDB can help prevent potential problems during startup or while accessing data from different nodes in the cluster.

Once these prerequisites have been completed, administrators can then prepare their environment by taking certain steps such as stopping applications connected to the database instance being restarted, disabling triggers and constraints associated with it, deleting temporary tablespaces created for testing purposes (if applicable), etc., before attempting a restart of the pluggable database itself. After performing these preliminary tasks, they can begin resetting their pluggable database by using either manual commands through SQL*Plus or graphical tools provided by Oracle Database Enterprise Manager (EM).

Setting the Environment Variable to Restart the PDB

To begin setting the environment variable to restart the pluggable database, administrators must first create an Oracle Restart configuration file. This is a text file that contains settings to be used by Oracle Database when restarting a PDB. It includes information regarding which diskgroup will contain the datafiles for the PDB, how many instances of Oracle should be started up and how much memory should be allocated for each instance. Additionally, it can also include details such as where log files should be stored and any user-defined parameters necessary for starting up an instance of Oracle.

Once this configuration file has been created, administrators then need to set an environment variable in order to enable automatic restarts of their pluggable databases. This is done by adding ORACLE_RESTART_ENABLE=TRUE into the target machine’s system environment variables list (in Windows OS). Once this step is complete, they can test if their setup was successful by running simple commands like ‘sqlplus / as sysdba’ or ‘startup pdbs’ from SQL*Plus prompt on the node hosting their database instance and checking if all nodes have successfully started up in clustered mode or not.

Finally, once these steps have been completed and verified correctly, administrators are now ready to start resetting their pluggable databases within RAC environments. They can do so manually using command line tools such as SQL*Plus or through graphical tools provided by Enterprise Manager (EM).

Steps to Restart the PDB in RAC

Once the configuration file has been created and the environment variable set, administrators can now begin resetting their pluggable databases within RAC environments. To do this, they must first execute a restart command for the PDB in question. This is done by entering ‘alter pluggable database open’ from an SQL*Plus prompt on the node hosting the instance of Oracle to be restarted. After executing this command, administrators should then check if all nodes have successfully started up in clustered mode or not (using commands such as ‘select * from v$ instance;’).

After verifying that all nodes are running correctly, administrators can then verify that their desired PDB has been successfully restarted by using either Enterprise Manager (EM) or SQL*Plus commands like ‘show pdbs;’ which will display information about all existing Pluggable Databases on a system. Additionally, they may also use other tools such as ASMCMD to monitor any changes made to cluster resources via Oracle Clusterware during startup operations of their PDBs.

Finally, once these steps have been completed and verified correctly, administrators should ensure that applications connected to their database instance are functioning properly before allowing users access it again after being resetted in RAC environment. This involves performing tests on user queries and checking whether data integrity is maintained across different nodes while accessing them simultaneously after restarting the PDBs in RAC systems.

Troubleshooting Failed PDB Restarts

The next step in troubleshooting failed PDB restarts is to check the Oracle Clusterware configuration. This involves verifying if all of the necessary services are running correctly, such as the Oracle Listener and any other associated components like ASM or RAC. Additionally, administrators should also ensure that they’ve configured their environment variables correctly so that Oracle can properly access its files from each node in the cluster.

Another important factor to consider when troubleshooting failed PDB restarts is checking for instance logs. These logs contain valuable information about errors which may have occurred during startup operations of a particular database instance and can provide valuable insights into what went wrong during restart attempts. The most common types of log files generated by Oracle are alert logs, trace files, SQL*Plus output files and core dumps; these should be checked carefully for any potential issues which could have caused a PDB restart failure.

Finally, it's also important for administrators to perform basic checks on databases hosted on different nodes within an Oracle RAC system after resetting a pluggable database in order to ensure that data integrity has been maintained across all instances within the cluster. This includes validating tablespaces (including temporary ones), ensuring proper backups have been taken before performing changes or upgrades, confirming user privileges and roles assigned to various users accessing databases from multiple nodes etc., all of which must be verified prior allowing application users access it again after being resetted in RAC environment.

Conclusion

In conclusion, restarting Pluggable Databases (PDBs) in an Oracle Real Application Clusters (RAC) environment can be a complex task that requires careful planning and preparation. However, the advantages of performing this procedure are numerous – from improved database performance to increased availability for applications using PDBs as their data source. By following best practices such as ensuring all prerequisite steps are taken before attempting a reset, verifying that Clusterware is configured and started properly, setting up environment variables correctly and checking logs for any potential issues; administrators can ensure successful restarts of their pluggable databases within RAC environments with minimal downtime or disruption. Additionally, it's also important to remember to perform basic checks on databases hosted on different nodes after resetting a PDB in order to maintain data integrity across all instances within the cluster.




Looking forward for your suggestions.. please feel free to write to me.. Your help would definitely help to improve our blog. Chetan Yadav

Thursday, March 16, 2023

Recovery Manager (RMAN)






An application used for backing up, restoring, and recovering Oracle databases is called Oracle Recovery Manager (RMAN). For Oracle databases, RMAN offers a complete backup and recovery solution, including full backups, incremental backups, and backups of particular database components.

You must connect to the target database and set aside a channel before you can run an RMAN backup. The channel can be assigned manually or automatically by RMAN, and it can be a disc or tape device. Once the channel has been assigned, you can start the backup procedure using the backup command.


You can specify different parameters with the backup command, including the backup type, backupset size, and compression level. For instance, you can use the following command to backup the database completely:

shell
RMAN>  backup database;
You can use the following command to carry out an incremental backup:

 
 
RMAN> backup incremental level 1 database;

  The backup is examined for consistency and restoreability using the validate command.

You must connect to the target database and set aside a channel before you can restore a backup. The database can then be restored using the restore command. You can specify other options with the restore command, including the restoration type and backupset location. For instance, you may use the following command to restore a database backup in its entirety:

shell
 
RMAN> restore database; 
After a restore, you can use the recover command to restore the database. To bring the database up to date, the recover command applies any necessary redo logs to the restored backup. For instance, you can use the following command to restore the database after a restoration:

 
 
RMAN> recover database;
For Oracle databases, RMAN offers a strong backup and recovery solution that enables you to execute full backups, incremental backups, and backups of particular database components. The validate and recover commands make sure that the backup is valid and the database is current while the backup and restore commands let you personalise the backup and restore procedure.


Looking forward for your suggestions.. please feel free to write to me.. Your help would definitely help to improve our blog. Chetan Yadav

Monday, March 6, 2023

Migration Oracle Database 11g to 19c (CDB)


    Moving from Oracle Database 11g to 19c (CDB) might be challenging, but with the appropriate knowledge and direction, it can be a straightforward procedure. This article offers a thorough tutorial to assist you in upgrading your Oracle Database 11g to 19c (CDB).

Are you considering upgrading from Oracle Database 11g to 19c (CDB)? If so, a thorough understanding of the procedure is required to guarantee a smooth upgrading. This article offers a thorough tutorial on how to smoothly upgrade your Oracle Database 11g to 19c (CDB).


 


  A Complete Guide on Upgrading from Oracle Database 11g to 19c

                                                Are you still using Oracle Database 11g for your database? It's time to update it to Oracle Database 19c (CDB), the most recent version, in order to benefit from new features, improved security, and improved speed. The transition from Oracle Database 11g to Oracle Database 19c (CDB) might be challenging, but with the correct information and direction, it can be a straightforward procedure. This article offers a thorough tutorial to assist you in upgrading your Oracle Database 11g to 19c (CDB).

There are a few things you should take into account before you start the update process:

Make sure your system and software fit Oracle Database 19c's hardware and software requirements (CDB).

Verify your existing Oracle Database 11g's compatibility with Oracle Database 19c (CDB). Verify that the new version is compatible with all the applications that use the database.

Backup: Create a copy of your current database before you start the upgrade procedure. In the event that the upgrade procedure fails, this will assist you in restoring the database.

Testing: Prior to upgrading the production system, it is generally desirable to carry out a test upgrade on a test system. This will assist you in locating any problems that might occur throughout the update procedure.

After giving these things some thought, let's go on to the upgrade procedure.

Upgrade Oracle Database 11g to 12c as the first step

Upgrade your Oracle Database from 11g to 12c is the first step in moving to Oracle Database 19c (CDB). Because Oracle Database 19c (CDB) requires Oracle Database 12c Release 2 (12.2.0.1) or later versions, this step is crucial. The following stages are involved in upgrading Oracle Database 11g to Oracle Database 12c:

Install Oracle Database 12c Release 2 (12.2.0.1) or a later version by downloading it.

Make a backup of the database.

Using the command-line interface or the Database Upgrade Assistant (DBUA), upgrade the database (CLI).

Do post-upgrade duties, such as recompiling broken objects using the utlrp.sql script.

Upgrade Oracle Database 12c to 19c in step two (CDB)

The next stage is to upgrade to Oracle Database 19c after you have upgraded your Oracle Database 11g to 12c (CDB). The following steps are part of the upgrade process:

Install Oracle Database 19c by downloading it (CDB).

Make an Oracle Database 12c backup.

Use the DBUA or CLI to upgrade the database.

run the utlrp.sql script and other post-upgrade actions.



Looking forward to your suggestions.. please feel free to write to me.. Your help would definitely help to improve our blog. Chetan Yadav

Wednesday, March 1, 2023

Upgrade from Oracle Database 11g to 19c (Non-CDB)

                     Upgrading your Oracle database is a crucial task that ensures your system is up-to-date and functioning properly. Oracle Database 19c is the latest version of the database software that offers many new features and improvements over its predecessors. In this blog, we will discuss how to upgrade from Oracle Database 11g to 19c (Non-CDB).
Before starting the upgrade process, it is essential to perform a thorough backup of your existing database. This will help you recover your data in case of any issues during the upgrade process. Once you have backed up your data, you can proceed with the following steps:


Step 1: Pre-Upgrade Tasks
Before upgrading to 19c, you need to perform some pre-upgrade tasks. These tasks include:

Checking the minimum requirements for the Oracle Database 19c installation.
Gathering information about the existing database, such as the version, patch level, and configuration details.
Ensuring that the existing database is compatible with 19c. You can use the pre-upgrade information tool to check for compatibility issues.
Resolving any compatibility issues that may be identified by the pre-upgrade information tool.

Step 2: Install Oracle Database 19c Software
Download and install the Oracle Database 19c software on your server. Ensure that you install the software for the same platform as the existing database.

Step 3: Upgrade the Database
To upgrade the database, follow these steps:

Connect to the existing database as a privileged user.
Start the Database Upgrade Assistant (DBUA) utility.
The DBUA will guide you through the upgrade process, including the upgrade options and parameters.
Once the upgrade process is complete, verify the upgraded database's functionality.

Step 4: Post-Upgrade Tasks
After upgrading to 19c, perform the following post-upgrade tasks:

Run the post-upgrade status tool to verify the upgraded database's status.
Ensure that all the required database parameters are correctly set.
Run the time zone script to update the database's time zone data.

If you are using Oracle Enterprise Manager, ensure that the agent and plug-ins are upgraded to 19c.
In conclusion, upgrading to Oracle Database 19c (Non-CDB) from 11g is a straightforward process that requires careful planning and execution. By following the steps outlined above, you can ensure a successful upgrade and take advantage of the new features and improvements offered by Oracle Database 19c. Remember always to back up your database before making any changes to your system to ensure that your data is secure.

Looking forward to your suggestions.. please feel free to write to me.. Your help would definitely help to improve our blog. Chetan Yadav

Saturday, August 7, 2021

Parameter for Oracle Data Guard

1. LOG_ARCHIVE_CONFIG - highly recommended by oracle, The DG_CONFIG is set on each database to set Data Guard Configuration. 

2. LOG_ARCHIVE_MAX_PROCESS - optional by Oracle, specify the number ( from 1- 30 ) of archiver (ARCn) process you want oracle software to invoke initially.
The default value is 4.

3.DB_CREATE_FILE_DEST - It specifies the default location of the Oracle Managed datafile.4
DB_CREATE_FILE_DEST= dictory / disk group. 
4.FAL_CLIENT - this parameter is no longer required.

5. FAL_SERVER - it specifies more oracle Net Services name, it can retrieve the missing archive file.
ORACLE_NET _SERVICE_NAME


 looking forward to your suggestions.. please feel free to write to me. Your help would definitely help to improve our blog. Chetan Yadav

how many Database are using ASM

How to know how many databases are using ASM 


we can use 

V$asm_client 




Looking forward to your suggestions.. please feel free to write to me.. Your help would definitely help to improve our blog. Chetan Yadav

Thursday, June 3, 2021

Parameter to set in primary and standby dataguard

Parameter are 
1. LOG_ARCHIVE_CONFIG 
2.LOG_ARCHIVE_MAX_PROCESSES 
3.DB_CREATE_FILE_DEST 
4.DB_FILE_CONVERT 
5.LOG_FILE_NAME_CONVERT 
6.LOG_ARCHIVE_DEST_n 
7.lOG_ARCHIVE_DEST_STATE_n 
8.FAL_SERVER 
9.FAL_CLIENT
 10.STANDBY_FILE_MANAGMENT 

Looking forward to your suggestions.. please feel free to write to me.. Your help would definitely help to improve our blog. Chetan Yadav