Oracle database creates server processes to mange requests of user process. All user process issues SQL statements, it is the responsibility of Server process to execute these statements and return results to user process. Each server process has one PGA. PGA is memory where server process executes statements and stores information. PGA consists of Private SQL Area, session memory and SQL work Areas.

Each statement in oracle is associated with a Private SQL area. Private SQL area can be divided into persistent area and run-time area. Persistent area contains bind information, i.e. the values for bind variables. Runtime area is used to execute the statements. Private SQL area is created in PGA if the connection is established using dedicated server. In case of shard server connection, Private SQL area is created in SGA.

PGA also contains Session Memory which is used to store session information for example session variables and logon information.

Few queries require complex operation like Hash Join or sorting. These operations are performed in the memory. To perform these tasks, SQL work areas are created in runtime area. The size of SQL work areas should be large enough that it can contain  data accessed by SQL statements. If size of work area is not large enough then response time may increase and hurt database performance. Oracle supports automatic memory management of work areas. Automatic management involve to steps, first you decide maximum memory available for PAG. Then use PGA_AGGREGATE_TARGET initialization parameter to set maximum memory available for PGA. This will only work for dedicated server mode. Because in shared servers, SQL work areas are created in SGA.

]]> http://exploreoracle.com/2009/11/09/oracle-pga/feed/ http://exploreoracle.com/2009/10/29/ora-02248-error-while-connecting-developer-6i-to-database-11g/ http://exploreoracle.com/2009/10/29/ora-02248-error-while-connecting-developer-6i-to-database-11g/#comments Thu, 29 Oct 2009 10:57:06 +0000 admin http://exploreoracle.com/?p=261 If you have an older version of Developer 6i and try to connect to Database server 11g, connection fails with following error message

ORA-02248: invalid option for ALTER SESSION

To resolve this problem simply upgrade your Developer 6i release by applying a patch or by fresh installation. For example, when I first time encountered this problem, I was using Forms Builder 6.0.5.0.2. I removed my previous release and installed Developer release 6.0.8.8.0. After up-gradation I was able to connect to 11g server without further problem.

When I first time tried to run my form, Forms Builder 6.0.8.8.0 asked me to re-enter password. This is because 11g has new Case sensitive password feature. When I first time connected to Forms Builder, I supplied correct password which was in lower case. When I tried to run form, Forms Builder tried to connect to 11g server with upper case user and upper case password. This is default behavior of Forms builder. Similar problem occurred when I tried to call reports from Forms using RUN_PRODUCT() method. To resolve this problem either set database users passwords to upper case or issue following SQL command to disable case Sensitive password feature.

ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON = FALSE;

Upgrading your Developer release will resolve you problem but you must remember that developer 6i with 11g is not a supported combination by oracle as support for Developer 6i has been dis-continued. Oracle recommends upgrading you developer to latest version like Oracle Developer Suite 10g or Forms 11g.

http://exploreoracle.com/2009/09/06/rman-script-to-take-full-database-backup/

Now we have scenario in which all data files have lost, we have also lost controlfiles. But some how, we haven’t lost archivelog files since last backup. In this case, we can recover our database using RMAN backup and archivelog files. We shall only lose data which was in current online redo log file. Remember, at startup our database in not opened.

Invoke RMAN and connect to database using following command.

RMAN> connect target /

Now set DBID with following command, it should be the Id of your database.

RMAN> set dbid=1216018526

Now start database in nomount stage.

RMAN> startup nomount;

Now configure controlfile autoback location.

RMAN> set controlfile autobackup format for device type disk to 'd:/rmanbackup/%F’;

Use following command to restore controlfiles.

RMAN> restore controlfile from autobackup;

Using this way all three control files will be restored to their default locations. However, there is another way to restore controlfile if you do not want to restore controlfile using “from autobackup”.  In this method,  first connect to database, and then start it in nomount stage.  Now locate the file name  which contains controlfile backup in d:\rmanbackup,  copy its  name.  Now issues following command to restore control file

RMAN> restore controlfile to ‘c:/CONTROL01.CTL’ from  ‘d:/rmanbackup/C-1216018526-20090905-00′;

In this command  ‘C-1216018526-20090905-00′ is name of backup file which contains controlfile backup. This file can be from autobackup or from  other backup. Other back means controlfile backup taken using “backup format” method in RMAN.

Above restore controlfile  command will create only one controlfile at ‘c:/CONTROL01.CTL’. Now copy this first control file at its location and save as it two times to create CONTROL02.CTL, and CONTROL03.CTL files.  using this method you do not need to set DBID, and autobackup control file location.

Restoration of control file is key point in database recovery. As control file has the information about all datafiles. Once control file is restored, database can be mounted.  Mounting of database is necessary.  All recovery operation can only be performed in mount stage. You can mount your database using following command.

RMAN> mount database;

After mounting database, this is time to restore all datafilese. To restore database, use following command.

RMAN> restore database using tag full_db;

Media Recovery should be performed on database before opening. In this step archivelogs are applied to recover data since last backup and to bring database in consistent stage.

RMAN> recover database;

Issue following command to open database and reset logs

RMAN> alter database open resetlogs;

Following snapshots show full recovery process.

Rman Recovery (part 1)

Rman Recovery (part 2)

Following section explains how we can take full database backup using RMAN command line interface on windows.

Before tacking backup, decide which type of backup you want to take. You can take online or offline backup using RMAN. For online backups, database archiving must be turned ON. If archiving of you database is not ON, database must be in MOUNT stage to take backup using RMAN. Oracle recommends you to turn ON archiving to protect your data. This example is tested with online backup option.

1- First step is to start RMAN, click Start->Run and type RMAN and press Enter key.

2- Second step is to connect RMAN to database. In this example, RMAN metadata will be saved in control file of target database. Now, issue following commands to connect database.

RMAN> Connect target /

Here note down DBID of database. This DBID will be used in recovery process

3- Create a directory name as “D:\RMANBACKUP”. Now type following script to take full database backup.


RMAN> run{

2> configure controlfile autobackup format for device type disk to 'd:/rmanbackup/%F';


3> configure controlfile autobackup on;
4> allocate channel d1 type disk;

5> backup tag FULL_DB format 'd:/rmanbackup/db_%t_%s.bk' (database);
6> release channel d1;
7> }

After the procedure is competed, you will find backupup files in “D:\RMANBACKUP” directory.These backup files can be used to recover any datafile or all datafiles, control file or SPFILE.

In production database, you will have several backups. What if you want to restore a particular backup? To handle this issue, RMAN supports a TAG with each backup. In above script tag FULL_DB is used at line 3. At the time of recovery this tag can be used to restore a particular backup.

Following is the snapshot of all above process.

RMAN backup

Visit following link to find an example of database recovery using above backup

http://exploreoracle.com/2009/09/12/rman-recovery-restore-controlfile/

Recovery Manager (RMAN) is client/server utility provided by oracle to perform backup and recovery operations on oracle database. RMAN is available in command-line interface as well as in Enterprise manager GUI. RMAN is part of oracle database and does not require separate installation or configuration. RMAN was firstly introduced with oracle 8.0. With RMAN, process of backup and recovery is easy, reliable and fast.

Oracle supports two methods to perform backup and recovery. First method is known as user-managed backups, in this method backup of database files is taken using operating system commands and SQL *Plus commands are used to perform recovery. In second method, RMAN is used to perform all backup and recovery operations. RMAN has certain advantages over user-managed backups. Following are main advantages of RMAN over user-managed backups

1- If you want to take an online backup using user-managed technique, all online read/write tablespaces must be put in backup mode. If you failed to do so, database recovery may not be possible when required. With RMAN, no tablespace is required to be put in backup mode.

2- RMAN allows incremental backups. In incremental backup, only thatdata blocks are copied which have changed after previous backup. In user-managed backups all data blocks are copied every time.

3- RMAN checks for data block corruption and archive log corruption during backup.

4- RMAN omits data blocks that have never been used. Operating systemcommands used in user-managed backup copy all the database files with all blocks. So the size of RMAN backup is usually small.

In addition to above, RMAN maintains metadata of its operations. This metadata is called RMAN repository. RMAN repository can be kept in target database (database which is being backed up) control file or in a separate database schema called recovery catalog. This repository stores information about location of backup sets, target database schema and current RMAN settings. Metadata can be accessed by using LIST, SHOW and REPORT commands. If you are using recovery catalog, certain views are available to query RMAN repository.

When database is recovered using RMAN, RMAN requires metadata to find location and type of backups. Without this repository, RMAN can not perform restoration and recovery operation.

Visit following link to find an example of RMAN backup script,

http://exploreoracle.com/2009/09/06/rman-script-to-take-full-database-backup/

Visit  following link to find an example of database recovery using RMAN.

http://exploreoracle.com/2009/09/12/rman-recovery-restore-controlfile/

1, Michle , clerk
2, king , manager
3, joe , clerk


What if we want to use this data in SQL query? Remember we do not want to import this data in oracle database but we want to reference this data from its physical location. To achieve this oracle database has provided a feature called External Tables. Using this feature, we can register “emp.dat” file in oracle database as external table.

In oracle database, an external table resides outside of database. These tables can be used in SQL queries like regular database tables. Views can also be created on external tables but no DML operation can be performed on external table. This is why external tables are read-only. Also we cannot create indexes on external tables.

External tales are created using ORGANIZATION EXTERNAL clause in CREATE TABLE statement. Following section creates an external table to reference data in “emp.dat” data.

Create a directory as c:\external_data. Create a new file as “emp.dat” in c:\external_data directory. Copy and paste following three rows in “emp.dat” file,


1, Michle , clerk
2, king , manager
3, joe , clerk


Now Connect to oracle database from sys user and issue following SQL statements,

create or replace directory data_dir as 'C:\external_table';
grant read,write on directory data_dir to scott;


Now connect to SCOTT user and following CREATE TABLE statement to create external table


CREATE TABLE EXT_TABLE
(EMP_ID NUMBER,
EMP_NAME VARCHAR2(50),
EMP_JOB VARCHAR2(20))
ORGANIZATION EXTERNAL
(
TYPE ORACLE_LOADER
DEFAULT DIRECTORY DATA_DIR
ACCESS PARAMETERS
(
records delimited by newline
fields terminated by ','
)
LOCATION ('EMP.DAT')
)

Now we can query external table. We can use this external table like we use other database tables.

All above process is shown in figure below.

External Tables

For further details you may visit following link

http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/tables.htm#sthref2445

When changes are made to datafiles, before these changes are written to datafies, redo entries for these changes are written to online redo log file. These redo entries can be used to re-build or re-store database changes. When a redo log file is full and archivelog mode of database is turned on, this redo log file is copied to offline destination known as archived redo log. The process of coping online redo log to archive redo log is called archiving. Redo log files work in circular fashion, it means redo log files are reused. For example, if our database has two redo log files, oracle uses second redo log file when first redo log file is full. When second redo log file is also full, oracle switches back to first redo log file. So if archiving is not turned on redo entries in redo log file are lost.

We need archive redo logs in flowing situations,

To take an online or hot backup, database archiving must be turned on because in online backup, datafiles have different SCN and data in data files in not consistent. When we restore an online backup, archived redo logs are applied to bring database in consistent stage.

Suppose we have taken a physical backup. After four hours of physical backup, few or all datafiles stop working due to media loss. We have a backup which is four hour old. We can only recover last four hours working only if automatic archiving is on.

Flashback database feature also requires that database archiving should be turned on.

To summarize, we can conclude that to protect our data and to ensure database recovery, archiving of database must be turned on.

1- Transaction Specific Temporary Table

A transaction specific temporary table holds a data until a commit is performed. A transaction begins when first SQL statement is executed and ends when a commit or rollback is performed. When a transaction ends either by commit or rollback, data in transaction specific temporary table is lost.

Use following command to create a transaction specific temporary table

CREATE GLOBAL TEMPORARY TABLE temp_table
(emp_id number,
emp_name varchar2(50))
ON COMMIT DELETE ROWS;

Note ON COMMIT clause in table creation. If ON COMMIT clause is omitted, by default oracle creates a transaction specific temporary table.

2- Session Specific Temporary Table

A session specific temporary table holds data until session lasts. When a commit is performed on session specific temporary table, data is preserved in table. But the data is not visible to others session. The data is lost when session ends.

Session specific temporary table can be created using “PRESERVE DATA” in ON COMMIT clause.

CREATE GLOBAL TEMPORARY TABLE temp_table
(emp_id number,
emp_name varchar2(50))
ON COMMIT PRESERVE ROWS;

The definition of temporary table is visible to all the sessions. Unlike permanent table, segment for temporary table is allocated when first INSERT statement is executed on temporary table. Indexes can also be created on temporary tables. The scope and life time of these indexes is similar to temporary tables.

1- After query execution, user may commit or rollback transaction. If user issues a rollback, original data is copied from Undo data entries.

2- Suppose a user execute query which take 20 minutes to execute. Other users may change the data during these 20 minutes. This may cause read inconsistency. To insure read consistency, oracle database uses original data from undo entries if data is changed during the execution of a query.

3- Flashback features including Oracle Flashback Query, Oracle Flashback version, Flashback transaction query and Oracle Flashback Table make use of undo data.

Undo Management and Undo Retention Period

Oracle supports two types of Undo management, Manual Undo Management and Auto Undo Management. In manual management, undo data is kept in rollback segments. When new database is created, oracle creates one rollback segments is system tablespace. Additional rollback segments can be created on requirement. Memory management for rollback segments is really complex. By default database is configured to use Manual Undo Management but it is not recommended by oracle.

Oracle database 9i and latest releases including 10g provide auto management of undo data. In auto management, undo data is stored in undo tablespace. Oracle creates one undo tablespace when a new database is created. Undo tablespace can also be created using following SQL statement.

CREATE UNDO TABLESPACE undotbs_02
DATAFILE ‘/oracle/oradata/orcl/undo0201.dbf’ SIZE 100M REUSE;

Use UNDO_MANAGEMENT initialization parameter to enable auto undo management. Set the value of this initialization parameter to Auto to start undo management as shown below

UNDO_MANAGEMENT=Auto

When oracle instance start, it select first undo tablespace to keep undo data. UNDO_TABLESPACE initialization parameter can be used to utilize a specific undo tablespace if you have more than one undo tablespaces.

The size of undo tablespace can be fixed or autoextend. Even with outoextend option enabled, maximum size of undo tablespace can be controlled by MAXSIZE clause. If undo tablespace has fixed size or MAXSIZE defined then old undo entries can be overwritten by new entries. The size of undo table space should be large enough to insure the undo data is available when required. This is done by setting Undo Retention period. Oracle database tries to retain undo data for time given by undo Retention period. Oracle database tries best to ensure this retention period. To insure read consistency, Undo retention period should be at least equal to time taken by your longest running query. If query is running and oracle finds that the data required by query is overwritten in undo tablespace, query fails with snapshot too old error message. If an SQL statement has not been committed or rolled back, its undo entries are said to be Active. Oracle ensures that these entries retain until corresponding entries are committed. Undo entries are marked expired which are old than current retention period. Undo retention period can be set by using UNDO_RETENTION initialization parameter. Value for this parameter can be set in parameter file as shows below

UNDO_RETENTION=3000

The value is in seconds

Use following statements to set Retention period at runtime

ALTER SYSTEM SET UNDO_RETENTION = 3000;

If you are using Logical level flashback features, make sure that retention period is set according to requirements as flash back features use undo data to get past information.

By default retention period in not guaranteed, oracle database may overwrite undo data if space for new undo entries is not available. You can use RETENTION GUARANTEE clause while creating undo tablespace to guarantee retention period.

Logical Database Backup

Logical backup means to backup you logical structure, for example, tables and packages. Logical backup can be taken using oracle utilities like Data Pump or oracle export utility.

Physical Database Backup

Physical backup is taken by maintaining backup of those files which constitute physical structure of oracle database. These files include datafiles, control files, redo log files, archived redo logs, parameter file and password file. Physical backup is considered more reliable and all of oracle backup and recovery techniques revolve around physical backups. Oracle uses term “Backup” for physical backups. Physical backups can be taken by using operating system commands or by using oracle utility RMAN. RMAN is powerful utility to mange backups. Most of oracle backup and recovery techniques are designed around RMAN.

Usually DBA requires data recovery in two possible scenarios, loss of data due to user error or loss of data due to media failure.

Some user can accidentally change or deleted data or an error in application might cause logical data corruption. As a result of this, DBA is required to recover database to a stage prior to that mistake. In this case, an old backup is restored and archive logs are applied to recover lost data.

Some time, due to corruption of physical media, few or all of storage files are lost. In this case, DBA is required to reconstruct the database.

Oracle Flashback Features

Before the release of oracle database 10g, all data recovery techniques were applied when database is not in open stage. Oracle database 10g has provided a new feature called Flashback feature which can be used to recover data lost due to user errors and data can be recovered when database is in open stage. Flashback recovery is considered an alternate to Point-in-time recovery. Oracle Flashback feature can be divided into two categories, Logical Level Features and Physical Level Features.

Except Flashback Drop, all Logical Level Flashback features rely on UNDO Data which is kept in undo tablespace. Recovery using these features depends on retention period.  At logical level Flashback features consists of following

Oracle Flashback Query

This feature allows you to execute a query on past stage of data. For example, you can execute a query by provide time interval of two hours back, the result will be same as query would have retrieved two hours back.

Oracle Flashback version and Flashback transaction query

In oracle database, a transition begins when first SQL statement is executed and transacting ends when commit or rollback is issued. When transaction is completed, all effected rows attain a Version. If within a transaction, a row has been updated ten times, it will have only one final Version. When a new transaction is performed a new Version of the rows is recorded.

Oracle flashback version query feature allows us to get all version of particular rows within a given time interval. As stated earlier, a final version may have been attained after execution of several SQL statements. Oracle Flashback transaction query feature allows to view changes made within a transition. FLASHBACK_TRANSACTION_QUERY view is used to get Flashback transitions. This view also contains undo statements to reverse the effect of transaction.

Oracle Flashback Table

This feature is used to bring a table to a past stage.

Oracle Flashback Drop

This feature is used to recover a dropped table. Flashback drop is managed around Recycle Bin concept.

At physical level, oracle has provided Flashback Database feature. Flashback Database use flashback logs and archives redo logs to obtain past version of data. Flashback database can be used to restore entire database to an earlier point.

Restore Points

Oracle Database 10g also supports restore points. You can define a restore point with an SCN number. In future, database can be restored to an available restore point. Restore points can also be  used  in conjunction with Flashback Database.