Sunday, April 16, 2023

To restart a PDB (Pluggable Database) in an Oracle RAC (Real Application Clusters) environment, you can use the following commands:


To restart a PDB (Pluggable Database) in an Oracle RAC (Real Application Clusters) environment, you can use the following commands:



  1. Connect to the CDB (Container Database) as a privileged user:


    sqlplus / as sysdba
  2. Determine the name of the PDB that you want to restart:


    SELECT name FROM v$pdbs;
  3. Switch to the PDB that you want to restart:


    ALTER SESSION SET CONTAINER=<PDB_NAME>;
  4. Check the current status of the PDB:


    SELECT name, open_mode FROM v$pdbs WHERE name='<PDB_NAME>';
  5. If the PDB is currently open, close it:


    ALTER PLUGGABLE DATABASE <PDB_NAMECLOSE;
  6. Wait for the PDB to close:


    SELECT name, open_mode FROM v$pdbs WHERE name='<PDB_NAME>';
  7. Once the PDB is closed, restart it:


    ALTER PLUGGABLE DATABASE <PDB_NAMEOPEN;
  8. Check the status of the PDB to confirm that it has been restarted:


    SELECT name, open_mode FROM v$pdbs WHERE name='<PDB_NAME>';

That's it! You have successfully restarted a PDB in an Oracle RAC environment using commands.

 



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

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

Monday, September 15, 2014

How to use shared folder in oracle virtual machine




how to share the folder from Windows to Linux in VM using shared folder option



1. Click on "Device " and then on "shared folder setting".
this box will appear

2 then click on "shared folder "  and choose your path  , as shown in figure .

3. reboot your machine.

[root@localhost ~]# cd /media/
[root@localhost media]# ls
sf_XXXX


with the name sf you can find your shared folder .



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

Monday, August 25, 2014

steps for Installation of oracle 11g R2 on Linux


Step 1 :-- Check the space 

[root@localhost ~]# df -kh
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
18G   14G  2.7G  84% /
/dev/sda1              99M   11M   83M  12% /boot
tmpfs                1003M     0 1003M   0% /dev/shm
Oracle11gR2           932G  821G  111G  89% /media/sf_Oracle11gR2
[root@localhost ~]# 



Step 2
add 2 groups "oinstall" and "dba"and 1 user "oracle"


[root@localhost ~]# groupadd oinstall
[root@localhost ~]# groupadd dba
[root@localhost ~]# useradd -g oinstall -G dba oracle
[root@localhost ~]# passwd oracle  

step 3
copy database dump in  linux 

[root@localhost home]# cp -r /media/sf_Oracle11gR2/database  /home/oracle/

Logout from Root user

loging as oracle user

step 4 
oracle@localhost ~]$ pwd
/home/oracle
[oracle@localhost ~]$ ls -ltr
total 8
drwxr-x--- 8 root   root     4096 Aug 25 01:05 database
drwxr-xr-x 2 oracle oinstall 4096 Aug 25 01:11 Desktop
[oracle@localhost ~]$ su - root
Password: 
[root@localhost ~]# pwd
/root
[root@localhost ~]# cd /home
[root@localhost home]# pwd
/home
[root@localhost home]# cd oracle/





[root@localhost oracle]# chown -R oracle:oinstall database
[root@localhost oracle]# ls -ltr
total 8
drwxr-x--- 8 oracle oinstall 4096 Aug 25 01:05 database
drwxr-xr-x 2 oracle oinstall 4096 Aug 25 01:11 Desktop
[root@localhost oracle]# EXIT

oracle@localhost ~]$ cd database/
[oracle@localhost database]$ ls
doc  install  response  rpm  runInstaller  sshsetup  stage  welcome.html
[oracle@localhost database]$ ls -ltr
total 36
drwxr-x--- 12 oracle oinstall 4096 Aug 25 01:02 doc
drwxr-x---  2 oracle oinstall 4096 Aug 25 01:02 sshsetup
-rwxr-x---  1 oracle oinstall 3226 Aug 25 01:02 runInstaller
drwxr-x---  2 oracle oinstall 4096 Aug 25 01:02 rpm
drwxr-x---  2 oracle oinstall 4096 Aug 25 01:02 response
drwxr-x---  4 oracle oinstall 4096 Aug 25 01:02 install
-rwxr-x---  1 oracle oinstall 5402 Aug 25 01:05 welcome.html
drwxr-x--- 14 oracle oinstall 4096 Aug 25 01:05 stage





oracle@localhost database]$ cd ..
[oracle@localhost ~]$ chmod -R 777 database 
[oracle@localhost ~]$ ls -ltr
total 8
drwxrwxrwx 8 oracle oinstall 4096 Aug 25 01:05 database
drwxr-xr-x 2 oracle oinstall 4096 Aug 25 01:11 Desktop

[oracle@localhost ~]$ cd database/
[oracle@localhost database]$ ./r
response/     rpm/          runInstaller  
[oracle@localhost database]$ ./runInstaller 
Starting Oracle Universal Installer...







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

Tuesday, August 12, 2014

Most useful Dictionary and Views for oracle dba

Most useful Dictionary and Views for oracle dba .

Data Dictionary
Which users are in the database password file:
V$PWFILE_USERS

Where values set in the init.ora file can be viewed – all parameters:
V$PARAMETER

Script used to create the objects that comprise the data dictionary:
catalog.sql

To grant a special role to users so they can look at DBA views:
SELECT_CATALOG_ROLE

Information about all database objects in the database:
DBA_OBJECTS

Information about all tables in the database:
DBA_TABLES

Information about all indexes in the database:
DBA_INDEXES

Information about all views (including dictionary views) in the database:
DBA_VIEWS

Information about all sequences in the database:
DBA_SEQUENCES

Information about all users in the database:
DBA_USERS

Information about all constraints in the database:
DBA_CONSTRAINTS

Information about all table columns that have constraints on them:
DBA_CONS_COLUMNS

Information about all columns that have indexes on them in the database:
DBA_IND_COLUMNS

Information about all columns in all the tables in the database:
DBA_TAB_COLUMNS


Information about all the roles in the database:
DBA_ROLES

Information about all object privileges in the database:
DBA_TAB_PRIVS

Information about all system privileges granted to all users in the database:
DBA_SYS_PRIVS

Displays all PL/SQL source code in the database:
DBA_SOURCE

Information about all triggers in the database:
DBA_TRIGGERS

Information about object privileges granted to roles
ROLE_TAB_PRIVS

Information about system privileges granted to roles
ROLE_SYS_PRIVS

Information about roles granted to roles
ROLE_ROLE_PRIVS

Information about all tablespaces in the database:
DBA_TABLESPACES

Information about all profiles in the database:
DBA_PROFILES


For all parameters?
V$PARAMETER

General information about the database mounted to your instance:
V$DATABASE

Most information about the performance of the database is kept here:
V$SYSSTAT

Most information about the performance for individual user sessions is stored here:
V$SESSION , V$SESSTAT

Information about online redo logs (2)
V$LOG, V$LOGFILE

Information about datafiles
V$DATAFILE

Basic information about control files, and the two columns it has:
V$CONTROLFILE. STATUS / NAME

An object you can query to obtain a listing of all data dictionary objects (4)
CATALOG, CAT, DICTIONARY, DICT.

When the control file was created, Sequence Number, most recent SCN:
V$DATABASE

Information stored in different sections of the control file, Sequence Number:
V$CONTROLFILE_RECORD_SECTION

To see the names and locations of all control files in the db? (2)
V$PARAMETER. V$CONTROLFILE


Tablespace and Datafiles
Temporary Segments:
Name, tablespace location, and owner of temporary segments:
DBA_SEGMENTS

Size of temporary tablespaces, current number of extents allocated to sort segments, and sort segment high-water mark information. Space usage allocation for temporary segments:
V$SORT_SEGMENT

Types of sorts that are happening currently on the database
V$SORT_USAGE

To see the username corresponding with the session:
V$SESSION

Information about every datafile in the database associated with a temporary tablespace:
DBA_TEMP_FILES

Similar to DBA_TEMP_FILES, this performance view gives Information about every datafile in the database associated with a temporary tablespace:
V$TEMPFILE

Storage Structures
A summary view, contains all types of segments and their storage parameters, space utilization settings:
DBA_SEGMENTS

Tablespace quotas assigned to users:
DBA_TS_QUOTAS

Segment name, type, owner, total bytes of extent, name of tablespace storing the extent:
DBA_EXTENTS

The location and amount of free space by tablespace name:
DBA_FREE_SPACE

The location of free space in the tablespace that has been coalesced:
DBA_FREE_SPACE_COALESCED

Information about datafiles for every tablespace
DBA_DATAFILES

Performance view for information for datafiles for every tablespace
V$DATAFILE

To see the total amount of space allocated to a table?
DBA_EXTENTS

Table creation timestamp, information about the object ID:
DBA_OBJECTS

High water mark, all storage settings for a table, and statistics collected as part of the analyze (for row migration) operation on that table
DBA_TABLES

Information about every column in every table:
DBA_TAB_COLUMNS

To determine how many columns are marked unused for later removal?
DBA_UNUSED_COL_TABS

To find the number of deleted index entries ?
INDEX_STATS

To determine the columns on a table that have been indexed:
DBA_ID_COLUMNS

The dynamic view to show whether the index is being used in a meaningful way?
V$OBJECT_USAGE

To see whether a constraint exists on a particular column?
DBA_CONS_COLUMNS
To see the constraints associated with a particular table:
DBA_CONSTRAINTS

To find the username, ID number, (encrypted) password, default and temporary tablespace information, user profile of a user, password expiry date:
DBA_USERS

To all objects, which objects belong to which users, how many objects a user has created?
DBA_OBJECTS

Resource-usage parameters for a particular profile:
DBA_PROFILES

Identifies all resources in the database and their corresponding cost:
RESOURCE_COST

Identifies system resource limits for individual users:
USER_RESOURCE_LIMITS

Shows all system privileges:
DBA_SYS_PRIVS

Show all object privileges:
DBA_TAB_PRIVS

Shows all privileges in this session available to you as the current user:
SESSION_PRIVS

Views for audits currently taking place are created by this script:
cataudit.sql

a list of audit entries generated by the exists option of the audit command:
DBA_AUDIT_EXISTS

A list of audit entries generated for object audits:
DBA_AUDIT_OBJECT

A list of audit entries generated by session connects and disconnects:
DBA_AUDIT_SESSION

A list of audit entries generated by statement options of the audit command:
DBA_AUDIT_STATEMENT

A list of all entries in the AUD$ table collected by the audit command:
DBA_AUDIT_TRAIL

To determine the roles available in the database, the names of all the roles on the database and if a password is required to use each role:
DBA_ROLES

Names of all users and the roles granted to them:
DBA_ROLE_PRIVS

All the roles and the roles that are granted to them:
ROLE_ROLE_PRIVS

Which system privileges have been granted to a role:
DBA_SYS_PRIVS

All the system privileges granted only to roles:
ROLE_SYS_PRIVS

All the object privileges granted only to roles:
ROLE_TAB_PRIVS

All the roles available in the current session:
SESSION_ROLES

Which object privilege has been granted to a role:
DBA_TAB_PRIVS

To display the value of the NLS_CHARACTERSET parameter:
NLS_DATABASE_PARAMETERS







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

Friday, August 1, 2014

Transportable Tablespaces











Transportable Tablespaces

Transportable tablespaces were introduced in Oracle 8i to allow whole tablespaces to be copied between databases in the time it takes to copy the datafiles. In Oracle 8i one of the restrictions was that the block size of both databases must be the same. In Oracle 9i the introduction of multiple block sizes has removed this restriction. In this article I will run through a simple example of transporting a tablespace between two databases.

Setup
Source Database
Destination Database
Cross-Platform Tablespace Conversions
Related articles.

Oracle Data Pump in Oracle Database 10g (expdp and impdp)
Data Pump Enhancements in Oracle Database 11g Release 1
SQL Developer 3.1 Data Pump Wizards (expdp, impdp)
Cross-Platform Tablespace Conversion
Setup

For this example I'm going to create a new tablespace, user and table to work with in the source database.

CONN / AS SYSDBA

CREATE TABLESPACE test_data
DATAFILE '/u01/app/oracle/oradata/DB11G/test_data01.dbf'
SIZE 1M AUTOEXTEND ON NEXT 1M;

CREATE USER test_user IDENTIFIED BY test_user
DEFAULT TABLESPACE test_data
TEMPORARY TABLESPACE temp
QUOTA UNLIMITED ON test_data;

GRANT CREATE SESSION, CREATE TABLE TO test_user;

CONN test_user/test_user

CREATE TABLE test_tab (
id NUMBER,
description VARCHAR2(50),
CONSTRAINT test_tab_pk PRIMARY KEY (id)
);

INSERT /*+ APPEND */ INTO test_tab (id, description)
SELECT level,
'Description for ' || level
FROM dual
CONNECT BY level <= 10000; COMMIT; Source Database For a tablespace to be transportable it must be totally self contained. This can be checked using the DBMS_TTS.TRANSPORT_SET_CHECK procedure. The TS_LIST parameter accepts a comma separated list of tablespace names and the INCL_CONSTRAINTS parameter indicates if constraints should be included in the check. CONN / AS SYSDBA EXEC SYS.DBMS_TTS.TRANSPORT_SET_CHECK(ts_list => 'TEST_DATA', incl_constraints => TRUE);

PL/SQL procedure successfully completed.

SQL>
The TRANSPORT_SET_VIOLATIONS view is used to check for any violations.

SELECT * FROM transport_set_violations;

no rows selected

SQL>
Assuming no violations are produced we are ready to proceed by switching the tablespace to read only mode.

SQL> ALTER TABLESPACE test_data READ ONLY;

Tablespace altered.

SQL>
Next we export the tablespace metadata using the export (expdp or exp) utility. If you are using 10g or above you should use the expdp utility. This requires a directory object pointing to a physical directory with the necessary permissions on the database server.

CONN / AS SYSDBA
CREATE OR REPLACE DIRECTORY temp_dir AS '/tmp/';
GRANT READ, WRITE ON DIRECTORY temp_dir TO system;
We can now export the tablespace metadata.

$ expdp userid=system/password directory=temp_dir transport_tablespaces=test_data dumpfile=test_data.dmp logfile=test_data_exp.log
If you are using a version prior to 10g, you do not need the directory object and your command would look something like this.

$ exp userid='system/password as sysdba' transport_tablespace=y tablespaces=test_data file=test_data.dmp log=test_data_exp.log
Copy the datafile to the appropriate location on the destination database server. Also copy the dump file to a suitable place on the destination database server. You may use binary FTP or SCP to perform this copy.

The source tablespace can now be switched back to read/write mode.

ALTER TABLESPACE test_data READ WRITE;

Tablespace altered.

SQL>
Destination Database

Create any users in the destination database that owned objects within the tablespace being transported, assuming they do not already exist.

CONN / AS SYSDBA

CREATE USER test_user IDENTIFIED BY test_user;
GRANT CREATE SESSION, CREATE TABLE TO test_user;
Now we import the metadata into the destination database. If you are using 10g or above you should use the impdp utility. This requires a directory object pointing to a physical directory with the necessary permissions on the database server.

CONN / AS SYSDBA
CREATE OR REPLACE DIRECTORY temp_dir AS '/tmp/';
GRANT READ, WRITE ON DIRECTORY temp_dir TO system;
We can now import the tablespace metadata.

$ impdp userid=system/password directory=temp_dir dumpfile=test_data.dmp logfile=test_data_imp.log transport_datafiles='/u01/app/oracle/oradata/DB11GB/test_data01.dbf'
If you are using a version prior to 10g, you do not need the directory object and your command would look something like this.

$ imp userid='system/password as sysdba' transport_tablespace=y datafiles='/u01/app/oracle/oradata/DB11GB/test_data01.dbf' tablespaces=test_data file=test_data.dmp log=test_data_imp.log
Switch the new tablespace into read write mode.

SQL> ALTER TABLESPACE test_data READ WRITE;

Tablespace altered.

SQL>
The tablespace is now available in the destination database.

SELECT tablespace_name, plugged_in, status
FROM dba_tablespaces
WHERE tablespace_name = 'TEST_DATA';

TABLESPACE_NAME PLU STATUS
------------------------------ --- ---------
TEST_DATA YES ONLINE

1 row selected.

SQL>
Cross-Platform Tablespace Conversions

If you are transporting tablespaces between platforms you need to perform Cross-Platform Tablespace Conversions.

For more information see:

Transporting Tablespaces Between Databases
Oracle Data Pump in Oracle Database 10g (expdp and impdp)
Data Pump Enhancements in Oracle Database 11g Release 1
SQL Developer 3.1 Data Pump Wizards (expdp, impdp)
Cross-Platform Tablespace Conversion
Hope this helps. Regards Tim...
















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

Monday, July 28, 2014


How to see the database is open (mount or unmont ) state in 11g ?

select database_status from v$instance
select * from v$database

_______________________________________________________________________________________________


2. HOW MUCH SPACE IS AVAILABLE IN UNDO N HOW MUCH IS USED


SELECT d.tablespace_name, round(((NVL(f.bytes,0) + (a.maxbytes - a.bytes))/1048576+
u.exp_space),2)
as max_free_mb, round(((a.bytes - (NVL(f.bytes,0)+ (1024*1024*u.exp_space)))*100/a.maxbytes),2)
used_pct FROM sys.dba_tablespaces d, (select tablespace_name, sum(bytes) bytes,
sum(greatest(maxbytes,bytes)) maxbytes from sys.dba_data_files group by tablespace_name) a,
(select tablespace_name, sum(bytes) bytes from sys.dba_free_space group by tablespace_name) f ,
(select tablespace_name , sum(blocks)*8/(1024) exp_space from
dba_undo_extents where status NOT IN ('ACTIVE','UNEXPIRED') group by tablespace_name) u
WHERE d.tablespace_name = a.tablespace_name(+) AND d.tablespace_name = f.tablespace_name(+)
AND d.tablespace_name=u.tablespace_name AND d.contents = 'UNDO' AND u.tablespace_name = (select
UPPER(value)
from v$parameter where name = 'undo_tablespace');

3. How much active,expired and unexpired

=====================================



set linesize 152

col tablespace_name for a20

col status for a10

select tablespace_name,status,count(extent_id) "Extent Count",
sum(blocks) "Total Blocks",sum(bytes)/(1024*1024*1024) spaceInGB
from dba_undo_extents
group by tablespace_name, status having tablespace_name=upper('&TSNAME')
order by tablespace_name;
(2:35:42 AM) vipul.pahuja@oracle.com: SQL> select * from t11;

SALARY
----------
12000

SQL> select tablespace_name,status,count(extent_id) "Extent Count",
sum(blocks) "Total Blocks",sum(bytes)/(1024*1024*1024) spaceInGB
from dba_undo_extents
group by tablespace_name, status having tablespace_name=upper('&TSNAME')
order by tablespace_name; 2 3 4 5
Enter value for tsname: UNDOTBS1
old 4: group by tablespace_name, status having tablespace_name=upper('&TSNAME')
new 4: group by tablespace_name, status having tablespace_name=upper('UNDOTBS1')

TABLESPACE_NAME STATUS Extent Count Total Blocks SPACEINGB
------------------------------ --------- ------------ ------------ ----------
UNDOTBS1 EXPIRED 33 744 .00567627
UNDOTBS1 UNEXPIRED 16 1208 .009216309

SQL> update t11 set salary=15000 where salary=12000;

1 row updated.

SQL> select tablespace_name,status,count(extent_id) "Extent Count",
sum(blocks) "Total Blocks",sum(bytes)/(1024*1024*1024) spaceInGB
from dba_undo_extents
group by tablespace_name, status having tablespace_name=upper('&TSNAME')
order by tablespace_name; 2 3 4 5
Enter value for tsname: UNDOTBS1
old 4: group by tablespace_name, status having tablespace_name=upper('&TSNAME')
new 4: group by tablespace_name, status having tablespace_name=upper('UNDOTBS1')

TABLESPACE_NAME STATUS Extent Count Total Blocks SPACEINGB
------------------------------ --------- ------------ ------------ ----------
UNDOTBS1 ACTIVE 1 128 .000976563
UNDOTBS1 EXPIRED 33 744 .00567627
UNDOTBS1 UNEXPIRED 15 1080 .008239746

SQL> update t11 set salary=20000 where salary=15000;

1 row updated.

SQL> select tablespace_name,status,count(extent_id) "Extent Count",
sum(blocks) "Total Blocks",sum(bytes)/(1024*1024*1024) spaceInGB
from dba_undo_extents
group by tablespace_name, status having tablespace_name=upper('&TSNAME')
order by tablespace_name; 2 3 4 5
Enter value for tsname: UNDOTBS1
old 4: group by tablespace_name, status having tablespace_name=upper('&TSNAME')
new 4: group by tablespace_name, status having tablespace_name=upper('UNDOTBS1')

TABLESPACE_NAME STATUS Extent Count Total Blocks SPACEINGB
------------------------------ --------- ------------ ------------ ----------
UNDOTBS1 ACTIVE 1 128 .000976563
UNDOTBS1 EXPIRED 33 744 .00567627
UNDOTBS1 UNEXPIRED 15 1080 .008239746

SQL> update t11 set salary=25000 where salary=20000;

1 row updated.

SQL> select tablespace_name,status,count(extent_id) "Extent Count",
sum(blocks) "Total Blocks",sum(bytes)/(1024*1024*1024) spaceInGB
from dba_undo_extents
group by tablespace_name, status having tablespace_name=upper('&TSNAME')
order by tablespace_name; 2 3 4 5
Enter value for tsname: UNDOTBS1
old 4: group by tablespace_name, status having tablespace_name=upper('&TSNAME')
new 4: group by tablespace_name, status having tablespace_name=upper('UNDOTBS1')

TABLESPACE_NAME STATUS Extent Count Total Blocks SPACEINGB
------------------------------ --------- ------------ ------------ ----------
UNDOTBS1 ACTIVE 1 128 .000976563
UNDOTBS1 EXPIRED 33 744 .00567627
UNDOTBS1 UNEXPIRED 15 1080 .008239746

SQL> commit;

Commit complete.

SQL> select tablespace_name,status,count(extent_id) "Extent Count",
sum(blocks) "Total Blocks",sum(bytes)/(1024*1024*1024) spaceInGB
from dba_undo_extents
group by tablespace_name, status having tablespace_name=upper('&TSNAME')
order by tablespace_name; 2 3 4 5
Enter value for tsname: UNDOTBS1
old 4: group by tablespace_name, status having tablespace_name=upper('&TSNAME')
new 4: group by tablespace_name, status having tablespace_name=upper('UNDOTBS1')

TABLESPACE_NAME STATUS Extent Count Total Blocks SPACEINGB
------------------------------ --------- ------------ ------------ ----------
UNDOTBS1 EXPIRED 34 752 .005737305
UNDOTBS1 UNEXPIRED 15 1200 .009155273

SQL>






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