Oracle 9i Database backups

SQL Server 2000 Database backups

  In oracle 9i, redo logs are used for backup purposes. Oracle 9i puts the database in archivelog mode and automatically backs up the redo log by a process called archiving. In SQL Server 2000, transaction logs are backed up for the same purpose. But, this has to be done manually by the DBA, once they fill up. DBAs often set up a batch job that runs periodically to back up transaction log, to avoid the manual task. Batch job in SQL Server is not a very acceptable solution because it cannot adapt to changes in workload. Oracle 9i supports online backup. RMAN ensures that during online backup, impact on performance is within an acceptable limit. RMAN checks for both availability and performance of the system. SQL Server 2000 also has online backup capability, but users may experience performance degradation. Oracle 9i backups are complete and fully self- contained. Oracle database can be recovered from any situation as long as a good backup is available. SQL Server 2000 backups are not self- contained. Hence, if msdb is lost, database is recovered by installing original CD even, even if regular backups are performed. Block media recovery feature of oracle 9i allows recovering only that block which is damaged and needs recovery. The rest of the file remains online and accessible SQL Server cannot recover data in single block units. Full file needs to be taken offline, restored and recovered. Supports on-line and offline database and redo log backups. Oracle supports a number of certified vendors equipments for backup.

  SQL Server 2000 includes the capability to perform differential backups. Using this approach, backups run relatively quickly and are smaller in size than other types of backups. Moreover, differential backups may be performed while users access the database. Oracle DBMS performs automatic recovery each time it is started. SQL Server2000 performs automatic recovery by checking each database in the system each time its Windows NT/2000 Service is started. Uncommitted data from Rollback segments is removed and online redo log files are searched for any information required at the time of recovery. SQL Server transaction log has the combined functionality of an Oracle rollback segment and an Oracle online redo log. Transaction log keeps record of all changes to the database. Oracle automatically creates and schedules a predefined backup job during database creation that implements the Oracle recommended strategy for backup management. The Oracle recommended strategy calls for backups to be made as follows:

• Perform full database backup once

• Subsequently perform incremental backups

• Update full database backup image copy with incremental backups

  In SQL Server, backup management is the burden of the DBA. A DBA has to first understand SQL Server architecture, learn about all the backup and recovery features that it provides, and then devise a strategy that provides the best possible recovery for the business needs. Once all this is done, the DBA then has to create the backup job that implements the strategy. This is another area where a DBA has to worry about one less thing in Oracle than in SQL Server.

Flashback query

Users can make mistakes such as entering the wrong values or deleting the wrong set of rows. Oracle9I’s flashback query allows an administrator or a user to view the database at a point-in time in the past. Developers can use this feature to build self-service error correction applications, empowering end-users to undo and correct their errors without delay.

  Flashback query

Not Supported
]]> http://sikanderjeet.wordpress.com/2009/05/24/comparison-table-of-backup-and-recovery/feed/ 0 sikanderjeet http://sikanderjeet.wordpress.com/2009/05/24/backup-and-recovery-in-sql-server2000-and-oracle9i/ http://sikanderjeet.wordpress.com/2009/05/24/backup-and-recovery-in-sql-server2000-and-oracle9i/#comments Sun, 24 May 2009 16:54:35 +0000 sikanderjeet http://sikanderjeet.wordpress.com/?p=96 ]]> Backup and recovery

Backup and recovery is one of the important features of any Database Management system. These two are very close companions and one cannot exist without the other.

In general, act of copying files from one location to a secondary storage location is called Backup. It is done to protect the organizations from any kind of loss in case of disasters. And, the act of copying files or data from a backup location to resume functioning after a disaster or failure is called Recovery.

In Oracle 9i

A backup is a copy of data and it acts as a safeguard against application errors and unpredicted data loss.

Backups are divided into physical backups and logical backups.

Physical and Logical backups

Physical backups are backups of physical database files such as data files and control files. They are done using either Recovery Manager (RMAN) utility or Operating system utilities.

Logical backups are the backups used to supplement physical backups and they contain logical data about schema objects like tables and stored procedures. Oracle Export Utility is used and data is stored in a binary file.

Whole Database and Partial Database backups

 Whole Database backup is the most common type of backup and includes backup of current control file with all the data files. It does not require to be operated in specific archiving mode.

The whole database backups can be done with the following methods:

• An operating system utility that makes a separate copy of each individual datafile in the database as well as the current control file
• The RMAN BACKUP DATABASE command
• The RMAN COPY DATAFILE command run against each datafile in the database, and the COPY CURRENT CONTROLFILE command run against the control file

Whole Database Backup Options

Tablespace Backup is the backup of all the data files that constitute the tablespace. Tablespace backups, whether online or offline, are valid only if the database is operating in ARCHIVELOG mode. This is because the redo is required to make the restored tablespace consistent with the other tablespaces in the database.

For a database in NONARCHIVELOG mode, the tablespace backup is valid only when the tablespace is currently read-only or offline-normal. This is because; no redo is required to recover them.

You can make backups of an individual tablespace with the following methods:

• An operating system utility that makes a separate copy of each datafile in the tablespace
• The RMAN BACKUP TABLESPACE command
• The RMAN COPY DATAFILE command run against each datafile in the tablespace

Datafile Backup is a backup of a single datafile. These backups are not as common as tablespace backup and are valid for databases operating in ARCHIVELOG mode.

For a database in NOARCHIVELOG mode, the datafile backup is valid only when :

• Every datafile in a tablespace is backed up and database cannot be restored unless all the datafiles are backed up.
• the datafiles are read-only or offline-normal.

Backups of an individual datafile can be done using:

• An operating system utility
• The RMAN BACKUP DATAFILE command
• The RMAN COPY DATAFILE command, which produces a datafile copy

Control file Backup is one of the important aspects of backup and recovery. A database cannot be opened or mounted, if control file is not available.

CONFIGURE CONTROLFILE AUTOBACKUP command of RMAN, allows automatic backup of the control file. It is called control file autobackup. RMAN can restore this backup even if RMAN repository is not available. Therefore, it is a very useful feature in backup and recovery.

Manual backups can be taken using following methods:

• The RMAN BACKUP CURRENT CONTROLFILE creates a RMAN-specific backup of the control file, and the COPY CURRENT CONTROLFILE command creates an image copy of the control file.
• The SQL statement ALTER DATABASE BACKUP CONTROLFILE makes a binary backup of the control file.
• The SQL statement ALTER DATABASE BACKUP CONTROLFILE TO TRACE exports the control file contents to a SQL script file. This script can be used to create a new control file. One main disadvantage of trace file backups is that they contain no records of archived redo logs, offline ranges for datafiles, and RMAN backups and copies. For this reason only, binary backups are preferable.

Archived Redo Log Backups

Archived redo logs are essential for recovering an inconsistent backup. The only way to recover an inconsistent backup without archived logs is to use RMAN incremental backups. To be able to recover a backup through the most recent log, every log generated between these two points must be available. In other words, you cannot recover from log 100 to log 200 if log 173 is missing. If log 173 is missing, then you must halt recovery at log 172 and open the database with the RESETLOGS option.

Because archived redo logs are essential to recovery, you should back them up regularly. If you use a media manager, then back them up regularly to tape.

You can make backups of archived logs by using the following methods:

• An operating system utility
• The RMAN BACKUP ARCHIVELOG command
• The RMAN BACKUP … PLUS ARCHIVELOG command
• The RMAN COPY ARCHIVELOG command

Consistent and Inconsistent Backups

Consistent Backup is a backup of one or more database files and it is done after the database has been closed with a clean SHUTDOWN command. A    consistent whole database backup does not require recovery after it is restored. If there are recurring periods of minimal use, then regular consistent backups of the whole database are done and are supplied with online backups of often-used tablespaces.

A consistent whole database backup is the only valid backup option for databases operating in NOARCHIVELOG mode, because otherwise redo will need to be applied to create consistency. In NOARCHIVELOG mode, Oracle does not archive the redo logs, and so the required redo logs may not exist on disk.

Inconsistent Backup

An inconsistent backup is a backup of one or more database files that you make while the database is open or after the database has shut down abnormally.

If your database must be open and available all the time, then inconsistent backups are your only option

An inconsistent backup is a backup in which all read/write datafiles and control files have not been checkpointed with respect to the same SCN

Online and Offline Backups

Online backup is backup of all specified datafiles of an online tablespace while the database is open, but only when the database runs in ARCHIVELOG mode. Online backup is also known as open backup.

Inconsistent data within a block is a cause of problem in online backups. Oracle cannot open the database, until all changes recorded in the online redo logs have been saved to the datafiles on disk. For that, data must be synchronized with respect to same System Change Number.

ALTER TABLESPACE BEGIN BACKUP statement places the online tablespace. It is done to put a tablespace in backup mode to make user-managed backups of datafiles in an online, read/write tablespace. After an online backup is completed, ALTER TABLESPACE ... END BACKUP or ALTER DATABASE END BACKUP statement to take the tablespace out of backup mode.

Offline backup is backup which is performed when the tablespace or datafile is offline.

ALTER TABLESPACE OFFLINE command takes tablespace offline using any of three different options: NORMAL, TEMPORARY, or IMMEDIATE. There is no need to bring tablespace or datafile back online, if backup is taken with normal option. Necessary backups on datafiles and tablespaces can be performed without ever having to shut down the database or perform recovery.

RMAN and User-Managed Backups

RMAN Backup is generated by running the BACKUP command from RMAN interface. It generates either a backup set or a proxy copy and writes it to an operating system or third-party media manager (if used).

In contrast to the BACKUP command, the RMAN COPY command generates a datafile, control file, or archived log image copy that can be restored by an operating system utility.

 The COPY command only copies to disk. However, the BACKUP command is used to back up image copies to tape.

If RMAN is used to make a backup or copy, it records the action in the target database control file. If a recovery catalog is used, then RMAN pulls the metadata from the control file into the catalog. To restore the backups or copies, run the RESTORE command. RMAN queries the metadata and then chooses among the available backups and copies and restores them.

User-Managed Backups are done by using Operating system utilities. The available commands are operating system specific.

On Windows NT, a datafile is backed up by pressing CTRL+C and then CTRL+V, by dragging and dropping, or by running a COPY command at the Command Prompt.

One major difference between user-managed backups and RMAN backups is that in the former there is no automatic metadata record of the backup. In other words, records of what you back up and where you back it up are manually maintained.

Backup and Recovery in SQL Server2000

Types of backups

Note: - The complete backups are the default and the starting point for all other types of backups.

2.    Differential: - A differential   backup backs up only the modified extents since the last complete backup was made. The modified extents are copied onto a specified backup device. Differential backups will also increase the speed of the backup operation as well as the restore. Because only the changed or newly allocated extents (bitmap tracking) are captured, differential backups are faster and smaller than full database backups.

SQl Server 2000 uses a bitmap which contains one bit for each database. The value of bit is set to 1 if any pages within that particular extent have been modified since the previous complete backup. SQl Server examines bitmap when a differential backup command is issued. It accesses only the extents that are flagged as having been modified through this bitmap and writes them to backup file.

Note: Differential database backup have several limitations like do not provide point in time restore capability, may not be restored by themselves (only be restored after a complete database backup is restored) and not be allowed to perform on master database.

3.    Transaction: – A Transaction log backups serially capture modifications to the database. An SQL Server database must have at least one transaction log file. A simple transaction place several records in the transaction log. These records are known as log records and each record has log sequence number. The same transaction records are linked together through the log sequence number.

1. This backup can be applied to a database in an unrecovered state.

1. File/ file group: – SQL Server provides the functionality to back up individual files/filegroups within a database. File/filegroup backups are used to restore the individual file/filegroup if some or all of the files within the particular filegroup are damaged.

The following boundaries are compulsory when using file/filegroup backups:

• File/filegroup backup only be restored to the same database it was backed up from.

• All transaction log backups (including the tail) for the database should be available and restorable. It is inferred that this would not be possible to do on a database that is in Simple Recovery model.

• Point-in-time recovery is not allowed when restoring file/filegroup backups. All transaction log backups have to be restored.

Note: -   A file/filegroup backup does not back up the transaction log portion of the database. This is a noteworthy difference between file/filegroup backup and complete backup.

1. File/Filegroup Differential Backups: – Differential backups can be combined with file/filegroup backups to back up only the modified extents within an SQL Server database file or filegroup. By doing this we can decrease the recovery time in disaster situations where only certain file/filegroups are lost. The most recent file/filegroup differential backup contains all changes from all earlier file/filegroup differential backups, since they are growing in nature.

File differential backups have the following boundaries:

• They are allowed only in conjunction with file/filegroup backups.
• They are not allowed for databases that use the Simple Recovery model.
• They require all transaction log backups (just like file/filegroup backups), including the tail of transaction log.

We can do these backups with two different techniques in SQL Server one through SQL Enterprise Manager or by using Transact-SQL commands.

There are three main database recovery models supported in SQL Server 2000. Table 1 lists the various recovery models that are available and describes their effects on recovery operations.

Table 1
 

These three values replace the database options select into/bulkcopy and trunc.log on chkpt.

1. Full recovery model

The full recovery model guarantees the least risk of losing work if a data file is damaged. For a database with this model, SQL Server fully logs all operations, so every row inserted through a bulk copy program (bcp) or BULK INSERT operation is written in its entirety to the transaction log.

It uses database backups and transaction log backups to provide complete protection against media failure. If one or more data files are damaged, media recovery can restore all committed transactions. In-process transactions are rolled back.

Full recovery provides the ability to recover the database to the point of failure or to a specific point in time. To guarantee this degree of recoverability, all operations, including bulk operations such as SELECT INTO, CREATE INDEX, and bulk loading data, are fully logged.

2. Bulk-Logged recovery model

The Bulk-Logged recovery model allows recovery in case of media failure and gives the best performance using the least log space for certain bulk operations, including BULK INSERT, bcp, CREATE INDEX, WRITETEXT, and UPDATETEXT. In the Bulk-Logged recovery model, SQL Server minimally logs these operations. When a bulk operation is executed, SQL Server logs only the fact that the operation occurred. However, the operation is fully recoverable because SQL Server keeps track of which extends the bulk operation modified.

In a Bulk-Logged recovery model, the data loss exposure for these bulk copy operations is greater than in the Full recovery model. While the bulk copy operations are fully logged under the Full recovery model, they are minimally logged and cannot be controlled on an operation-by-operation basis under the Bulk-Logged recovery model. Under the Bulk-Logged recovery model, a damaged data file can result in having to redo work manually.

In addition, the Bulk-Logged recovery model only allows the database to be recovered to the end of a transaction log backup when the log backup contains bulk changes. Point-in-time recovery is not supported. In SQL Server 2000, it is not necessary to perform a full database backup after bulk copy operations complete under the Bulk-Logged recovery model. Transaction log backups under this model capture both the log and the results of any bulk operations performed since the last backup.

3. Simple recovery model

The Simple recovery model brings forth the fastest bulk operations and the simplest backup-and-restore strategy. Under this model, SQL Server truncates the transaction log at regular intervals, removing committed transactions. Thus, only full database backups and differential backups are allowed; an error will be returned if a backup of the log is attempted while using the Simple recovery model. Because SQL Server doesn’t need the log for backup, it reuses sections as soon as all the transactions in them are committed or rolled back and no longer needed for recovery from server or transaction failure.

How Automatic Recovery feature of SQL 2000 Server works

The Automatic Recovery feature of SQL 2000 server rolls forward (therefore writes to the database) all the committed (complete) transactions that have been written to the log file before the checkpoint, while it rolls back (deletes) all the uncommitted (therefore incomplete) transactions that were still occurring at the time of the failure.   

Backup and recovery

Backup and recovery is one of the important features of any Database Management system. These two are very close companions and one cannot exist without the other.

In general, act of copying files from one location to a secondary storage location is called Backup. It is done to protect the organizations from any kind of loss in case of disasters. And, the act of copying files or data from a backup location to resume functioning after a disaster or failure is called Recovery.

In Oracle 9i

A backup is a copy of data and it acts as a safeguard against application errors and unpredicted data loss.

Backups are divided into physical backups and logical backups.

Physical and Logical backups

Physical backups are backups of physical database files such as data files and control files. They are done using either Recovery Manager (RMAN) utility or Operating system utilities.

Logical backups are the backups used to supplement physical backups and they contain logical data about schema objects like tables and stored procedures. Oracle Export Utility is used and data is stored in a binary file.

Whole Database and Partial Database backups

 Whole Database backup is the most common type of backup and includes backup of current control file with all the data files. It does not require to be operated in specific archiving mode.

The whole database backups can be done with the following methods:

• An operating system utility that makes a separate copy of each individual datafile in the database as well as the current control file
• The RMAN BACKUP DATABASE command
• The RMAN COPY DATAFILE command run against each datafile in the database, and the COPY CURRENT CONTROLFILE command run against the control file

Whole Database Backup Options

Tablespace Backup is the backup of all the data files that constitute the tablespace. Tablespace backups, whether online or offline, are valid only if the database is operating in ARCHIVELOG mode. This is because the redo is required to make the restored tablespace consistent with the other tablespaces in the database.

For a database in NONARCHIVELOG mode, the tablespace backup is valid only when the tablespace is currently read-only or offline-normal. This is because; no redo is required to recover them.

You can make backups of an individual tablespace with the following methods:

• An operating system utility that makes a separate copy of each datafile in the tablespace
• The RMAN BACKUP TABLESPACE command
• The RMAN COPY DATAFILE command run against each datafile in the tablespace

Datafile Backup is a backup of a single datafile. These backups are not as common as tablespace backup and are valid for databases operating in ARCHIVELOG mode.

For a database in NOARCHIVELOG mode, the datafile backup is valid only when :

·         Every datafile in a tablespace is backed up and database cannot be restored unless all the datafiles are backed up.

·         the datafiles are read-only or offline-normal.

Backups of an individual datafile can be done using:

• An operating system utility
• The RMAN BACKUP DATAFILE command
• The RMAN COPY DATAFILE command, which produces a datafile copy

Control file Backup is one of the important aspects of backup and recovery. A database cannot be opened or mounted, if control file is not available.

CONFIGURE CONTROLFILE AUTOBACKUP command of RMAN, allows automatic backup of the control file. It is called control file autobackup. RMAN can restore this backup even if RMAN repository is not available. Therefore, it is a very useful feature in backup and recovery.

Manual backups can be taken using following methods:

• The RMAN BACKUP CURRENT CONTROLFILE creates a RMAN-specific backup of the control file, and the COPY CURRENT CONTROLFILE command creates an image copy of the control file.
• The SQL statement ALTER DATABASE BACKUP CONTROLFILE makes a binary backup of the control file.
• The SQL statement ALTER DATABASE BACKUP CONTROLFILE TO TRACE exports the control file contents to a SQL script file. This script can be used to create a new control file. One main disadvantage of trace file backups is that they contain no records of archived redo logs, offline ranges for datafiles, and RMAN backups and copies. For this reason only, binary backups are preferable.

Archived Redo Log Backups

Archived redo logs are essential for recovering an inconsistent backup. The only way to recover an inconsistent backup without archived logs is to use RMAN incremental backups. To be able to recover a backup through the most recent log, every log generated between these two points must be available. In other words, you cannot recover from log 100 to log 200 if log 173 is missing. If log 173 is missing, then you must halt recovery at log 172 and open the database with the RESETLOGS option.

Because archived redo logs are essential to recovery, you should back them up regularly. If you use a media manager, then back them up regularly to tape.

You can make backups of archived logs by using the following methods:

• An operating system utility
• The RMAN BACKUP ARCHIVELOG command
• The RMAN BACKUP … PLUS ARCHIVELOG command
• The RMAN COPY ARCHIVELOG command

Consistent and Inconsistent Backups

Consistent Backup is a backup of one or more database files and it is done after the database has been closed with a clean SHUTDOWN command. A    consistent whole database backup does not require recovery after it is restored. If there are recurring periods of minimal use, then regular consistent backups of the whole database are done and are supplied with online backups of often-used tablespaces.

A consistent whole database backup is the only valid backup option for databases operating in NOARCHIVELOG mode, because otherwise redo will need to be applied to create consistency. In NOARCHIVELOG mode, Oracle does not archive the redo logs, and so the required redo logs may not exist on disk.

Inconsistent Backup

An inconsistent backup is a backup of one or more database files that you make while the database is open or after the database has shut down abnormally.

If your database must be open and available all the time, then inconsistent backups are your only option

An inconsistent backup is a backup in which all read/write datafiles and control files have not been checkpointed with respect to the same SCN

Online and Offline Backups

Online backup is backup of all specified datafiles of an online tablespace while the database is open, but only when the database runs in ARCHIVELOG mode. Online backup is also known as open backup.

Inconsistent data within a block is a cause of problem in online backups. Oracle cannot open the database, until all changes recorded in the online redo logs have been saved to the datafiles on disk. For that, data must be synchronized with respect to same System Change Number.

ALTER TABLESPACE BEGIN BACKUP statement places the online tablespace. It is done to put a tablespace in backup mode to make user-managed backups of datafiles in an online, read/write tablespace. After an online backup is completed, ALTER TABLESPACE ... END BACKUP or ALTER DATABASE END BACKUP statement to take the tablespace out of backup mode.

Offline backup is backup which is performed when the tablespace or datafile is offline.

ALTER TABLESPACE OFFLINE command takes tablespace offline using any of three different options: NORMAL, TEMPORARY, or IMMEDIATE. There is no need to bring tablespace or datafile back online, if backup is taken with normal option. Necessary backups on datafiles and tablespaces can be performed without ever having to shut down the database or perform recovery.

RMAN and User-Managed Backups

RMAN Backup is generated by running the BACKUP command from RMAN interface. It generates either a backup set or a proxy copy and writes it to an operating system or third-party media manager (if used).

In contrast to the BACKUP command, the RMAN COPY command generates a datafile, control file, or archived log image copy that can be restored by an operating system utility.

 The COPY command only copies to disk. However, the BACKUP command is used to back up image copies to tape.

If RMAN is used to make a backup or copy, it records the action in the target database control file. If a recovery catalog is used, then RMAN pulls the metadata from the control file into the catalog. To restore the backups or copies, run the RESTORE command. RMAN queries the metadata and then chooses among the available backups and copies and restores them.

User-Managed Backups are done by using Operating system utilities. The available commands are operating system specific.

On Windows NT, a datafile is backed up by pressing CTRL+C and then CTRL+V, by dragging and dropping, or by running a COPY command at the Command Prompt.

One major difference between user-managed backups and RMAN backups is that in the former there is no automatic metadata record of the backup. In other words, records of what you back up and where you back it up are manually maintained.

Backup and Recovery in SQL Server2000

Types of backups

1.    Complete: – A complete backup mostly copies all the pages from a database onto a backup device, including all entries in the transaction log—excluding any unallocated extents in the files, which can be a local or network disk file, a local tape drive, or even a named pipe. 

Note: - The complete backups are the default and the starting point for all other types of backups.

2.    Differential: - A differential   backup backs up only the modified extents since the last complete backup was made. The modified extents are copied onto a specified backup device. Differential backups will also increase the speed of the backup operation as well as the restore. Because only the changed or newly allocated extents (bitmap tracking) are captured, differential backups are faster and smaller than full database backups.

SQl Server 2000 uses a bitmap which contains one bit for each database. The value of bit is set to 1 if any pages within that particular extent have been modified since the previous complete backup. SQl Server examines bitmap when a differential backup command is issued. It accesses only the extents that are flagged as having been modified through this bitmap and writes them to backup file.

Note: Differential database backup have several limitations like do not provide point in time restore capability, may not be restored by themselves (only be restored after a complete database backup is restored) and not be allowed to perform on master database.

3.    Transaction: – A Transaction log backups serially capture modifications to the database. An SQL Server database must have at least one transaction log file. A simple transaction place several records in the transaction log. These records are known as log records and each record has log sequence number. The same transaction records are linked together through the log sequence number.

A transaction log backup backs up all transactions since the previous transaction log backup, or the complete database backup if there have been no transaction log backups performed for the database in the past. The backups of the log are then used in the recovery process to restore the database fully, to a point in time.  This backup can be applied to a database in an unrecovered state.

4.    File/ file group: – SQL Server provides the functionality to back up individual files/filegroups within a database. File/filegroup backups are used to restore the individual file/filegroup if some or all of the files within the particular filegroup are damaged.

The following boundaries are compulsory when using file/filegroup backups:

·         File/filegroup backup only be restored to the same database it was backed up from.

·         All transaction log backups (including the tail) for the database should be available and restorable. It is inferred that this would not be possible to do on a database that is in Simple Recovery model.

·         Point-in-time recovery is not allowed when restoring file/filegroup backups. All transaction log backups have to be restored.

Note: -   A file/filegroup backup does not back up the transaction log portion of the database. This is a noteworthy difference between file/filegroup backup and complete backup.

5.    File/Filegroup Differential Backups: – Differential backups can be combined with file/filegroup backups to back up only the modified extents within an SQL Server database file or filegroup. By doing this we can decrease the recovery time in disaster situations where only certain file/filegroups are lost. The most recent file/filegroup differential backup contains all changes from all earlier file/filegroup differential backups, since they are growing in nature.

File differential backups have the following boundaries:

·         They are allowed only in conjunction with file/filegroup backups.

·         They are not allowed for databases that use the Simple Recovery model.

·         They require all transaction log backups (just like file/filegroup backups), including the tail of transaction log.

We can do these backups with two different techniques in SQL Server one through SQL Enterprise Manager or by using Transact-SQL commands.

There are three main database recovery models supported in SQL Server 2000. Table 1 lists the various recovery models that are available and describes their effects on recovery operations.

Table 1

These three values replace the database options select into/bulkcopy and trunc.log on chkpt.

1. Full recovery model

The full recovery model guarantees the least risk of losing work if a data file is damaged. For a database with this model, SQL Server fully logs all operations, so every row inserted through a bulk copy program (bcp) or BULK INSERT operation is written in its entirety to the transaction log.

It uses database backups and transaction log backups to provide complete protection against media failure. If one or more data files are damaged, media recovery can restore all committed transactions. In-process transactions are rolled back.

Full recovery provides the ability to recover the database to the point of failure or to a specific point in time. To guarantee this degree of recoverability, all operations, including bulk operations such as SELECT INTO, CREATE INDEX, and bulk loading data, are fully logged.

2. Bulk-Logged recovery model

The Bulk-Logged recovery model allows recovery in case of media failure and gives the best performance using the least log space for certain bulk operations, including BULK INSERT, bcp, CREATE INDEX, WRITETEXT, and UPDATETEXT. In the Bulk-Logged recovery model, SQL Server minimally logs these operations. When a bulk operation is executed, SQL Server logs only the fact that the operation occurred. However, the operation is fully recoverable because SQL Server keeps track of which extends the bulk operation modified.

In a Bulk-Logged recovery model, the data loss exposure for these bulk copy operations is greater than in the Full recovery model. While the bulk copy operations are fully logged under the Full recovery model, they are minimally logged and cannot be controlled on an operation-by-operation basis under the Bulk-Logged recovery model. Under the Bulk-Logged recovery model, a damaged data file can result in having to redo work manually.

In addition, the Bulk-Logged recovery model only allows the database to be recovered to the end of a transaction log backup when the log backup contains bulk changes. Point-in-time recovery is not supported. In SQL Server 2000, it is not necessary to perform a full database backup after bulk copy operations complete under the Bulk-Logged recovery model. Transaction log backups under this model capture both the log and the results of any bulk operations performed since the last backup.

3. Simple recovery model

The Simple recovery model brings forth the fastest bulk operations and the simplest backup-and-restore strategy. Under this model, SQL Server truncates the transaction log at regular intervals, removing committed transactions. Thus, only full database backups and differential backups are allowed; an error will be returned if a backup of the log is attempted while using the Simple recovery model. Because SQL Server doesn’t need the log for backup, it reuses sections as soon as all the transactions in them are committed or rolled back and no longer needed for recovery from server or transaction failure.

How Automatic Recovery feature of SQL 2000 Server works

The Automatic Recovery feature of SQL 2000 server rolls forward (therefore writes to the database) all the committed (complete) transactions that have been written to the log file before the checkpoint, while it rolls back (deletes) all the uncommitted (therefore incomplete) transactions that were still occurring at the time of the failure.  

But they have different ways to implement these security features in their databases which creates some differences in their security. Let us discuss the implications of these differences in security:

• Creating login accounts and users in Oracle 9i and SQL Server is roughly equivalent. But SQL Server 2000 provides extra security using two modes of authentication: Windows Authentication and Mixed mode. Windows Authentication mode uses the security mechanism within the Windows NT/2000 to provide security to SQL Server 2000. So in this mode, authentication is done using Windows platform and it makes this mode platform specific.

• Oracle 9i uses Oracle Advanced Security for Enterprise Edition only to provide features like data encryption, data privacy, encryption, integrity, authentication and single sign-on. This feature adds extra cost to the Enterprise Edition. But SQL Server provides all these features at much lower cost and greater ease of use.

• Data encryption in Oracle 9i is done using Oracle Advanced Security feature. And in SQL Server 2000, it is done using Encrypted File System of Windows 2000. Hence, SQL Server 2000 and Windows 2000 provide better security working together. And this feature makes easier to configure security in SQL Server 2000.

• SQL Server 2000 provides same security features across their all product lines i.e. across all versions of 2000. But Oracle 9i provides different security features with Oracle Advanced Security for Enterprise Edition and makes it more costly. But this difference makes a point for organizations which do not want a very secure database and can use Oracle 9i’s Standard Edition for less cost. But even then SQL Server is less costly as compared to Oracle 9i and provides almost same security features.

• Oracle 9i provides very fine- grained auditing and Virtual Private Databases feature which takes security to an extra level as compared to SQL Server 2000 and hence, gives Oracle 9i an edge over SQL Server 2000.

Big Question. Which database is more secure?

Even after looking at the differences in security features of the two databases and implications of those differences, we cannot mention which database is more secure. Though Oracle 9i provides some extra security features, but the ease to implement the security features still lies with SQL Server 2000. Moreover, Oracle 9i provides Extra Security feature with Oracle Advanced Security for Enterprise Edition by incurring some extra cost for that. While SQL Server 2000 is cheap and it provides better security features when working with Windows 2000.

But we can still say SQL Server 2000 provides better security for environment which needs an easy to use and comparatively cheap database.

And oracle 9i with its extra security features is costlier and needs better expertise to make use of all the security features developed.

in future may be i will edit this document …….. 

THANKS……..

A database acts as a central repository of data for any organization. Therefore, security is an important concept for any database management system.

Security is to protect the data from unauthorized access and unwanted changes.

The primary goals of security are to ensure:

• Data confidentiality: Only authorized individuals should be able to view data.
• Data integrity: All authorized users should feel confident that the data presented to them is accurate and not improperly modified.
• Data availability: Authorized users should be able to access the data they need, when they need it.

Database security can be divided into two parts:

1. System security
2. Data security

System security covers access and use of database at system level, such as username and password, and the systems operations that users can perform.

Data security covers access and use of database objects, and the operations that the users can perform on the objects.

Security in Oracle 9i

Oracle 9i provides features like standard user authentication and oracle advanced security to protect the data from unauthorized user access. These features offer data integrity, data privacy, authentication and authorization.

User Authentication and authorization:

Oracle 9i provides User Authentication and authorization. User Authentication is to check for the identity of a user. A user must supply a valid username and password to access a database. Authorization is to make sure that user has appropriate privileges to access an object. Authorization control is to check which user is allowed what operation on which database object.

These prevent unauthorized access.

Grant based security:

Profiles, privileges, and roles can be used in oracle to control user access.

Profile: It is a mechanism within the database which allows setting and controlling the password and resource limits for a user.

Oracle server automatically creates a DEFAULT profile, whenever a database is created.

Profile usage:

• Allow assemble resource limits for similar users.
• Make sure that user logs off the database when they have left their session idle for some time.
• Manage resource usage in large, complex multiuser database systems.
• Easily assign resource limits to users.
• Restrict users from performing operations that require large amount of resources.
• Control the use of passwords.

Oracle password management is controlled with profiles, and it provides greater control over database security.

Privileges: They are rights to control user access to database and its objects. With privileges, some users may be allowed only to view the data, while others may have the control to create and update the same data.

System privileges are to provide users with access to the database. System privileges should be used where security is not a major concern, because a single grant statement could remove all the security from the table.

Object privileges are to allow the users to manipulate the content of the objects in the database.

It is very complex form of providing security. Large number of individual grant statements may be required to assign security.

Roles: A role is a group of related privileges that can be granted to the user. A role makes it easier to maintain, revoke and grant the privileges.

Role is a way to manage the privileges. Earlier to grant user access to an object, it had to be done on a table-by-table basis which made it very difficult to manage the privileges. That is when oracle created role database object.

Roles provide security by defining a set of access rules or privileges and then assigning them to the users.

Invoker rights:

Invoker rights means that the user who creates the stored procedure is the only one with rights to a table affected by the procedure. These are rights to control privileges, one grants to the users. For example, if a procedure is created that is to update data in a table, users can run this procedure to perform update, but they have not been granted the update privilege. Only way for users to update data in table is by using the program.

Invoker rights take security to one step further. With invoker rights, methods that used to manipulate the data in a database can be controlled. And one does not need to worry if users can change data without any kind of control on your part.

Oracle Advanced Security

Oracle Advanced Security provides data privacy, encryption, integrity, authentication and single sign-on.

• Encryption ensures data privacy by keeping the data to be transmitted between nodes as private.
• Integrity is to ensure for secure transmission by checking that data is not changed or tempered with during transmission.
• Single sign-on enables users to authenticate to multiple servers using a single username/password combination.
• Authentication makes sure that users are authenticated or verified properly.

Auditing

Oracle 9i introduced a new feature called “fine-grained auditing. It allows auditing i.e. keeping track of activities down to column level in queries. By default, only instance startup, instance shutdown and connections to the database using privileges are audited.

Fine-grained auditing is not suggested for daily activities, but may be useful for specific auditing situations.

 Firewalls in oracle

Oracle provides firewall support

Oracle Net Firewall Proxy Kit allows firewall vendors to provide connection support for Oracle environments.

Oracle supports two categories of firewalls:

• Proxy- based firewalls
• Stateful packet inspection firewalls

 Virtual Private Database

“The Virtual Private Database (VPD) is the aggregation of server-enforced, fine-grained access control, together with a secure application context in the Oracle9i database server. It provides a flexible mechanism for building applications that enforce the security policies customers want enforced, only where such control is necessary.”

This feature enables to configure security at row level.

The Virtual Private Database offers the following benefits:

• Lower cost of ownership. Organizations can reap huge cost savings by building security once, in the data server, instead of implementing the same security in each application that accesses data.

• Elimination of the “application security problem.” Users cannot bypass security policies embedded in applications because the security policy is attached to the data. The same security policy is automatically enforced by the data server, no matter how a user accesses data, whether through a report-writing tool, a query, or through an application.

•  Application transparency. Virtual Private Database is enforced at the database layer and takes into account application-specific logic used to limit data access within the database. Both commercial off the- shelf applications and custom-built applications can take advantage of its granular access control, without the need to change any lines of application code.

•  New business opportunities. In the past, organizations couldn’t give customers and partners direct access to their production systems because there was no way to secure the data. Hosting companies couldn’t have data for multiple companies reside in the same data server, because they could not separate each company’s data. Now, all these scenarios are possible, because fine-grained access control gives you server-enforced data security with the assurance of physical data separation.

These benefits contribute to Oracle9i’s industry-leading security solutions.

Security in SQL Server 2000

Two main ways to implement security in SQL Server 2000 are Authentication and permissions.

Authentication

SQL Server 2000 provides two different security modes:

• Windows Authentication Mode security
• Mixed Mode security (both windows authentication and SQL Server authentication)

Windows Authentication Mode:

When SQL Server is run under windows 2000, security is checked in three different places, as you attempt to connect to SQL Server 2000. Validations are done by Windows 2000, SQL server itself (in the form of a SQL Server login), and then at the database level (in the form of a database username).

Windows Authentication: when connection is made from client computer to a windows NT/2000 computer running SQL Server 2000, Windows might require validation of network connection.

SQL server login Authentication: A valid SQL Server login name and password are required to connect to SQL Server.

SQL Server Database Username: A valid database username is required to use any database on your system.

Mixed Mode security:

In Mixed Mode security, a user can connect either using Windows authentication or SQL Server authentication.

SQL Server authentication:  In this mode, SQL server accepts a login ID and password from a user, and without any help from Windows, checks whether the credentials are valid or not i.e. it checks whether it is a trusted connection or not. If it is a trusted connection, then SQL Server uses Windows authentication, otherwise uses SQL Server authentication (i.e. try to find the same login Id and password which user has passed)

In SQL Server authentication, SQL Server is fully responsible for authenticating a user and enforcing password and login restrictions.

Windows authentication is not available when SQL Server is running on Windows 9x computer. Hence, SQL Server authentication is always used on a windows 9x computer. 

Windows authentication mode is the default authentication mode for SQL Server 2000. It provides advanced security features such as password expirations, password attributes, auditing and account lockouts.

For all trusted connections, use Windows authentication mode. Otherwise use mixed mode.

Permissions:

Permissions are final layer of security. These are explicit rights given to access database, either for read-only or modification operations.

Two types of permissions are granted:

1. Statement level permissions
2. Object level permissions

Statement level permissions are to allow a user to run a particular Transact-SQL command. These permissions allow users to create objects, create databases or back up databases.

Object level permissions are to allow a user to perform some operation like SELECT, INSERT, UPDATE or DELETE.

Permissions in SQL Server 2000 are managed by three terms: GRANT, DENY and REVOKE.

Permissions must be implemented very carefully to ensure the security of the data. In SQL Server, no database users have any inherent permission; they have only the permissions which are granted to them.

Roles:

Role in SQL Server 2000 is like a group to which individual users or logins can be added. Roles provide a flexible approach to manage security. SQL server provides 4 types of roles:

1. Fixed server roles
2. Fixed database roles
3. User defined roles
4. Application roles

Fixed server roles:

Logins or users can be added to these roles to assign the administrative permissions of this role. Instead of giving full system administrator functionality, these roles allow the DBA to provide only server level permissions that each user require. These are also called server wide roles. SQL Server 2000 provides a list of fixed server roles which cannot be altered and new server roles cannot be created.

This approach allows DBAs to keep better track of the members and their actions and provides highest level of security.

Fixed database roles:

Database users can be added to these roles to assign the database administrative permissions. Instead of giving full database owner functionality, these roles allow the DBA to provide only database level permissions to the user. These fixed server roles are unique within a database. SQL server provides a list of fixed database roles which cannot be altered, but new database roles can be created.

Database roles are database specific, and one cannot have roles that affect more than a single database at any time. These roles provide security at database level.

User defined roles:

Roles can be created and then users or roles can be assigned to the newly created roles. These roles allow the DBA or database owner to manage permissions in a more easy way.

This feature should be carefully used to avoid security conflicts.

Application roles:

Application roles are a very important and useful feature of SQL Server 2000. These roles are different from other roles due to the need of a password to be activated and they do not contain any users. These roles are also database specific.

After activation of these roles, users cannot access objects in other databases. If the user wants to run a cross-database transaction, the other database must have a guest user account enabled.

 SQL Server 2000 Auditing:

 Auditing has made SQL Server 2000 more secure and easier to administer. Auditing is not turned on by default. But by enabling auditing, SQL Server 2000 can audit user activity such as which tables users access, which queries users run, and which stored procedures users invoke.

Auditing can be enabled by clicking on the appropriate option under Audit level on the Security tab of the SQL Server Properties dialog box.

To keep a track of logins, it is recommended that both failure and success login records must be audited.

Encryption:

 SQL Server encryption provides extra protection to secure the databases.

Windows 2000 introduced Encrypted File System (EFS) that allows encrypting individual files and folders on an NTFS partition. This feature can be used to encrypt SQL Server database files. The files must be encrypted using the service account of SQL Server. For changing the service account of SQL Server, the files must be decrypted, service account should be changed and the files should be encrypted again with the new service account.

Protocol encryption can be enabled for the server by selecting Force protocol encryption on the General tab of the Server Network Utility.

 Comparison of security features in Oracle 9i and SQL Server 2000

Refernces

http://www.oracle.com/technology/deploy/security/oracle9ir2/pdf/VPD9ir2twp.pdf

http://www.blurtit.com/q380589.html

http://www.dba-oracle.com/art_builder_grant_sec.htm

http://www.cs.uvm.edu/oracle9doc/network.901/a90148/galsystematic.htm

http://technet.microsoft.com/en-us/library/cc966507.aspx

http://vyaskn.tripod.com/sql_server_security_best_practices.htm

http://vyaskn.tripod.com/row_level_security_in_sql_server_databases.htm

http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle_11i_Auditing.pdf

Comments:

There is little difference in storage structure of the two databases. Physical storage structure differs as there are tablespaces in oracle to group related logical structures together but segments are used in SQL server. In oracle, each database has a control file but no control files are found in SQL server.

References:

1. Oracle (2007).Oracle® Database SQL Developer Supplementary Information for Microsoft SQL Server Migrations Release 1.2 Part Number E10379-01 from http://download.oracle.com/docs/cd/E10405_01/doc/appdev.120/e10379/ss_oracle_compared.htm#BABFDFBI 

2 .Abbey,M. Corney,M. & Abramson,I.(2002). Oracle9i A beginners’s Guide

U.S.A: McGraw-hillW

3. Waymire, R.,& Sawtell,R.(2001). Sams Teach Yourself Microsoft Sql Server2000 in 21 Days

U.S.A: Sams

Oracle and SQL server data types do not match exactly. Moreover there are some data types which are defined in oracle but do not exist in Sql Server and comparison of them have been listed below.

Schema of any database is definition of tables, views, indexes, constraints, stored procedures, triggers and other database – specific objects.

So comparison of some specific schema objects of oracle and SQL server is as given below:

Schema objects comparison:

COMMENTS:-

There are some differences in schema objects in both the databases. In oracle, there are clusters which allow for a different way to store table data. But there is no such other way to store table data in SQL server. Package is a collection of procedures and functions bundled together, but no package concept is there in SQL server. Triggers for each row, synonyms and snapshot are used in oracle which is not found in SQL server.

In this article, I compare SQL Server 2000 with Oracle 9i Database regarding price, performance, platforms supported, SQL dialects and products limits.

Platform comparison

SQL Server 2000 only works on Windows-based platforms, including Windows 9x, Windows NT, Windows 2000 and Windows CE.
In comparison with SQL Server 2000, Oracle 9i Database supports all known platforms, including Windows-based platforms, AIX-Based Systems, Compaq Tru64 UNIX, HP 9000 Series HP-UX, Linux Intel, Sun Solaris and so on.

Hardware requirements

To install SQL Server 2000, you should have the Intel or compatible platforms and the following hardware:

To install Oracle 9i under the Intel or compatible platforms, you should have the following hardware:

To install Oracle 9i Database under the UNIX Systems, such as AIX-Based Systems, Compaq Tru64 UNIX, HP 9000 Series HP-UX, and Sun Solaris, you should have the following hardware:

Software requirements

SQL Server 2000 comes in six editions: Enterprise, Standard, Personal, Developer, Desktop Engine, and SQL Server CE (a compatible version for Windows CE) and requires the following software:

Oracle 9i Database comes in three editions: Enterprise, Standard and Personal and requires the following software:

Performance comparison

It is very difficult to make the performance comparison between SQL Server 2000 and Oracle 9i Database. The performance of your databases depends rather from the experience of the database developers and database administrator than from the database’s provider. You can use both of these RDBMS to build stable and efficient system. However, it is possible to define the typical transactions, which used in inventory control systems, airline reservation systems and banking systems. After defining these typical transactions, it is possible to run them under the different database management systems working on the different hardware and software platforms.

TPC tests

The TPC produces benchmarks that measure transaction processing and database performance in terms of how many transactions a given system and database can perform per unit of time, e.g., transactions per second or transactions per minute.

The TPC organization made the specification for many tests. There are TPC-C, TPC-H, TPC-R, TPC-W and some old tests, such as TPC-A, TPC-B and TPC-D. The most popular test is the TPC-C test (OLTP test).

Note. Because most organizations really do not run very large databases, so the key points on which SQL Server 2000 won the TPC-C benchmarks do not really matter to the vast majority of companies.

Price comparison

Compare pricing for SQL Server 2000 Standard Edition and Oracle9i Standard Edition:

Compare pricing for SQL Server 2000 Enterprise Edition (which include OLAP and Data Mining) and Oracle9i Enterprise Edition with OLAP and/or Data Mining:

Note. This is not a full price comparison between SQL Server 2000 and Oracle 9i Database. It is only a brief comparison. You can have any discounts and the prices can be increased or decreased in the future. See Microsoft and Oracle to get more information about the price of their products.

Features comparison

Both SQL Server 2000 and Oracle 9i Database support the ANSI SQL-92 entry level and do not support the ANSI SQL-92 intermediate level. In the Features comparison section of this article I want to make the brief comparison of the Transact-SQL with PL/SQL and show some SQL Server 2000 and Oracle 9i Database limits.

T-SQL vs PL/SQL

The dialect of SQL supported by Microsoft SQL Server 2000 is called Transact-SQL (T-SQL). The dialect of SQL supported by Oracle 9i Database is called PL/SQL. PL/SQL is more powerful language than T-SQL. This is the brief comparison of PL/SQL and T-SQL:

SQL Server 2000 and Oracle 9i limits

Here you can find some SQL Server 2000 and Oracle 9i Database limits:

Conclusion

The SQL Server 2000 advantages:

• SQL Server 2000 is cheaper to buy than Oracle 9i Database.
• SQL Server 2000 holds the top TPC-C performance and price/performance results.
• SQL Server 2000 is generally accepted as easier to install, use and manage.

The Oracle 9i Database advantages:

• Oracle 9i Database supports all known platforms, not only the Windows-based platforms.
• PL/SQL is more powerful language than T-SQL.
• More fine-tuning to the configuration can be done via start-up parameters.

 References

2. Oracle documentation

3. Oracle and SQL Server 2000 Price Comparison

4. Why is SQL Server better/worse than Oracle?

5. Top Ten TPC-C by Performance Version 5 Results

6. Top Ten TPC-C by Price/Performance Version 5 Results

Segment Types

 Objects in an Oracle database such as tables, indexes, clusters, sequences, etc., are comprised of segments.  There are several different types of segments.

 Table:  Data is stored in tables.  When a table is created with the CREATE TABLE command, a table segment is allocated to the new object.

·         Table segments do not store table rows in any particular order.

·         Table segments do not store data that is clustered or partitioned.

·         The DBA has almost no control over the location of rows in a table.

·         The segment belongs to a single tablespace.

Table Partition:  If a table has high concurrent usage, that is simultaneous access by many different system users as would be the case for a SALES_ORDER table in an online-transaction processing environment, you will be concerned with scalability and availability of information as the DBA.  This may lead you to create a table that is partitioned into more than one table partition segment.

• A partitioned table has a separate segment for each partition.
• Each partition may reside in a different tablespace.
• Each partition may have different storage parameters.
• The Oracle Enterprise Edition must have the partitioning option installed in order to create a partitioned table.

 Cluster:  Rows in a cluster segment are stored based on key value columns.  Clustering is sometimes used where two tables are related in a strong-weak entity relationship.

• A cluster may contain rows from two or more tables.
• All of the tables in a cluster belong to the same segment and have the same storage parameters.
• Clustered table rows can be accessed by either a hashing algorithm or by indexing.

Index:  When an index is created as part of the CREATE TABLE or CREATE INDEX command, an index segment is created. 

• Tables may have more than one index, and each index has its own segment.
• Each index segment has a single purpose – to speed up the process of locating rows in a table or cluster.

 Index-Organized Table:  This special type of table has data stored within the index based on primary key values.  All data is retrievable directly from the index structure (a tree structure).

 Index Partition:  Just as a table can be partitioned, so can an index.  The purpose of using a partitioned index is to minimize contention for the I/O path by spreading index input-output across more than one I/O path.

• Each partition can be in a different tablespace.
• The partitioning option of Oracle Enterprise Edition must be installed.

 Undo:  An undo segment is used to store “before images” of data or index blocks prior to changes being made during transaction processing.  This allows a rollback using the before image information.

 Temporary:  Temporary segments are created when commands such as CREATE INDEX, SELECT DISTINCT, GROUP BY, and ORDER BY clauses cause Oracle to perform memory sorts of information.  Often sort actions require more memory than is available.  When this occurs, intermediate results of sort actions are written to disk so that the sort operation can continue – this allows information to swap in and out of memory by writing/reading to/from disk.  Temporary segments store intermediate sort results.

 LOB:  Large objects can be stored as one or more columns in a table.  Large objects (LOBs) include images, separate text documents, video, sound files, etc. 

• These LOBs are not stored in the table – they are stored as separate segment objects.
• The table with the column actually has a “pointer” value stored in the column that points to the location of the LOB.

 Nested Table:  A column in one table may consist of another table definition.  The inner table is called a “nested table” and is stored as a separate segment.  This would be done for a SALES_ORDER table that has the SALES_DETAILS (order line rows) stored as a nested table. 

 Bootstrap Segment:  This is a special cache segment created by the sql.bsq script that runs when a database is created. 

• It stores initial data dictionary cache information when a database is opened.
• This segment cannot be queried or updated and requires no DBA maintenance.

 Storage Clauses/Parameters

 When database objects are created, the object always has a set of storage parameters.  This figure shows three ways that an object can obtain storage clause parameters. 

Tablespaces have space managed depending on the type of tablespace:

• Locally Managed Tablespaces – use bitmaps to track used and free space – Locally managed is the default for non-SYSTEM permanent tablespaces when the type of extent management is not specified at the time a tablespace is created.
  • Tablespace extents for Locally Managed are either (1) Uniform specified with the UNIFORM clause or (2) variable extent sizes determined by the system with the AUTOALLOCATE clause. 
    • Uniform:
      • Specify an extent size or use the 1MB default size.
      • Each extent contains at least 5 database blocks.
    • System Managed:
      • Oracle determines optimal size of additional extents with a minimum extent size of 64KB.
      • With SEGMENT SPACE MANAGEMENT AUTO, the minimum extent size is 1MB if the Database Block size is 16K or larger.
• Dictionary Managed Tablespaces – data dictionary tables track space utilization.

 Facts about storage parameters:

• Segment storage parameters can override the tablespace level defaults with the exception of two parameters.  You cannot override the MINIMUM EXTENT or UNIFORM SIZE tablespace parameters.
• If you do not specify segment storage parameters, then a segment will inherit the tablespace default parameters.
• If tablespace default storage parameters are not set, the Oracle server system default parameters are used. 
• Locally managed tablespaces cannot have the storage parameters INITIAL, NEXT, PCTINCREASE, and MINEXTENTS specified; however, these parameters can be specified at the segment level. 
• When storage parameters of a segment are modified, the modification only applies to extents that are allocated after the modification takes place.

 Extents

 Extents are allocated in chunks that are not necessarily uniform in size, but the space allocated is contiguous on the disk drive as is shown in this figure.  When a database object such as a table grows, additional disk space is allocated to its segment of the tablespace in the form of an extent.

 Example of a CREATE TABLE Command

• This shows the creation of a table named Orders in the Data01 tablespace.
• Data01 is locally managed, but here the storage parameters specified override the storage parameters for the tablespace.

 CREATE TABLE Orders (
    Order_Id        NUMBER (3) PRIMARY KEY,
    Order_Ddate     DATE DEFAULT (SYSDATE),
    Ship_Date       DATE,
    Client          VARCHAR(3) NOT NULL,
    Amount_Due      NUMBER(10,2),
    Amount_Paid     NUMBER(10,2))
PCTFREE 5 PCTUSED 65
STORAGE (

    INITIAL 1M

    NEXT 48K

    PCTINCREASE 5

    MINEXTENTS 1

Database Block

 The Database Block or simply Data Block, as you have learned, is the smallest size unit for input/output from/to disk in an Oracle database.

• A data block may be equal to an operating system block in terms of size, or may be larger in size, and should be a multiple of the operating system block.
• The DB_BLOCK_SIZE parameter sets the size of a database’s standard blocks at the time that a Database is created.  However, Oracle actually supports the creation of databases that have more than one block size.  This is primarily done when you need to specify tablespaces with different block sizes in order to maximize I/O performance. 

• You’ve already learned that a database can have up to four nonstandard block sizes specified. 
• Block sizes must be sized as a power of two between 2K and 32K in size, e.g., 2K, 4K, 8K, 16K, or 32K. 
• A sub cache of the Database Buffer Cache is configured by Oracle for each nonstandard block size. 

Standard Block Size:  The DB_CACHE_SIZE parameter replaces the previous DB_BLOCK_BUFFERS parameter from Oracle 8i and previous RDBMS software releases.  This new parameter specifies the size of the Database Buffer Cache.  The minimum size for DB_CACHE_SIZE must be specified as follows:

• One granule where a granule is a unit of contiguous virtual memory allocation in RAM. 
• If the total System Global Area (SGA) based on SGA_MAX_SIZE is less than 128MB, then a granule is 4MB.
• If the total SGA is greater than 128MB, then a granule is 16MB. 
• The default value for DB_CACHE_SIZE is 48MB. 

 Nonstandard Block Size:  If a DBA wishes to specify one or more nonstandard block sizes, the parameter following parameters are set.  If the operating system only supports block sizes up to a specified limit, for example, 16MB, then do not try to set block sizes greater than the operating system limit.  Additionally, do not use these parameters to set standard block sizes.  For example, if the standard block size is 4KB, do not use the DB_4K_CACHE_SIZE parameter.

• DB_2K_CACHE_SIZE   — parameter for 2KB nonstandard block sizes.
• DB_4K_CACHE_SIZE   — parameter for 4KB nonstandard block sizes.
• DB_8K_CACHE_SIZE   — parameter for 8KB nonstandard block sizes.
• DB_16K_CACHE_SIZE   — parameter for 16KB nonstandard block sizes.
• DB_32K_CACHE_SIZE   — parameter for 32KB nonstandard block sizes.

• Temporary tablespaces must be the standard block size.  This also applies to permanent tablespaces that have been specified as default temporary tablespaces for system users.

Data Block Contents

This figure shows the components of a data block.  This is the structure regardless of the type of segment to which the block belongs.

Block header – contains common and variable components including the block address, segment type, and transaction slot information. 

The block header also includes the table directory and row directory. 

On average, the fixed and variable portions of block overhead total 84 to 107 bytes.

• Table Directory – used to track the tables to which row data in the block belongs.
  • Data from more than one table may be in a single block if the data are clustered.
  • The Table Directory is only used if the data are clustered.
• Row Directory – used to track which rows from a table are in this block. 
  • The Row Directory includes for each row or row fragment in the row data area.
  • When space is allocated in the Row Directory to store information about a row, this space is not reclaimed upon deletion of a row, but is reclaimed when new rows are inserted into the block.
  • A block can be empty of rows, but if it once contained rows, then data will be allocated in the Row Directory (2 bytes per row) for each row that ever existed in the block.
• Transaction Slots are space that is used when transactions are in progress that will modify rows in the block. 
• The block header grows from top down.
• Data space (Row Data) – stores row data that is inserted from the bottom up.

Free space in the middle of a block can be allocated to either the header or data space, and is contiguous when the block is first allocated.

• Free space is allocated to allow variable character and numeric data to expand and contract as data values in existing rows are modified. 
• New rows are also inserted into free space. 
• Free space may fragment as rows in the block are modified or deleted. 
• SMON coalesces this free space periodically.

 Manual Data Block Free Space Management — Database Block Space Utilization Parameters

 Manual data block management requires a DBA to specify how block space is used and when a block is available for new row insertions.  This is the default method for data block management for dictionary managed tablespace objects (another reason for using locally managed tablespaces with UNIFORM extents).  Database block space utilization parameters are used to control space allocation for data and index segments. 

 The INITTRANS parameter specifies the initial number of transaction slots created when a database block is initially allocated to either a data or index segment.  These slots store information about the transactions that are making changes to the block at a given point in time.  The amount of space allocated for a transaction slot is 23 bytes. If you set INITRANS to 2, then there are 46 bytes (2 * 23) pre-allocated in the header, etc.  These slots are in the database block header.

The INITTRANS parameter specifies a minimum level of concurrent access.  The default is 1 for a data segment and 2 for an index segment.  If a DBA specifies INITTRANS at 4, for example, this means that 4 transactions can be concurrently making modifications to the database block.  Also, setting this to a figure that is larger than the default can eliminate the processing overhead that occurs whenever additional transaction slots have to be allocated to a block’s header when the number of concurrent transactions exceeds the INITTRANS parameter.

The MAXTRANS parameter specifies the maximum number of concurrent transactions that can modify rows in a database block.  Surprisingly, the default maximum is 255.  This value is quite large.  This parameter is set to guarantee that there is sufficient space in the block to store data or index data.

The PCTFREE and PCTUSED Parameters

You, as the DBA, must decide how much Free Space is needed for data blocks in manual management of data blocks. 

You set the free space with the PCTFREE and PCTUSED parameters at the time that you create an object like a Table or Index. 

PCTFREE:  The PCTFREE parameter is used at the time an object is created to set the percentage of usable block space to be reserved during row insertion for possible later updates to rows in the block. 

PCTUSED:  The parameter PCTUSED is used to set the level at which a block can again be considered by Oracle for insertion of new rows.  It is like a low water mark whereas PCTFREE is a high water mark.

Both PCTFREE and PCTUSED are calculated as percentages of the available data space – Oracle deducts the space allocated to the block header from the total block size when computing these parameters.

Free lists:  When a segment is created, it is created with a Free List that is used to track the blocks allocated to the segment that are available for row insertions. 

Automatic Segment Space Management

Free space can be managed either automatically or manually.  Automatic segment space management was introduced with Oracle 9i.  It simplifies the management of the PCTUSED, FREELISTS, and FREELIST GROUPS parameters and generally provides better space utilization where objects may vary considerably in terms of row size.  This can also yield improved concurrent access handling for row insertions.  A restriction is that you cannot use this approach if a tablespace will contain LOBs.

Using the Data Dictionary to Manage Storage

Periodically you will need to obtain information from the data dictionary about storage parameter settings.  The following views are useful.

• DBA_EXTENTS – information on space allocation for segments.
• DBA_SEGMENTS – stores information on segments.
• DBA_TABLESPACES – a row is added when a tablespace is created. 
• DBA_DATA_FILES – a row is added for each datafile in the database.
• DBA_FREE_SPACE – shows the space in each datafile that is free.

REFERENCES

http://www.akadia.com/services/sqlsrv_data_structure.html

Character Strings

• CHAR (size) – A fixed-sized field of characters. The largest this particular datatype can become is 2000 bytes. In other words, it can only hold 2000 characters. If you don’t specify the length of the CHAR datatype, the default size is a single character (i.e. 1 byte).

• NCHAR (size) – A fixed-sized field of characters, where the character set is determined by its definition. So, the maximum size is 2000 bytes per row or 2000 characters. This handles multibyte character sets.

• VARCHAR2 (size) – A variable-sized field of characters. The largest this datatype can become is 4000 characters.

• NVARCHAR2 (size) – A variable-sized field of characters, where the character set is determined by its definition. The maximum size is 4000 bytes per row or 4000 characters. This handles multibyte character sets.

Note: The VARCHAR2 datatype is the successor of VARCHAR. So it is recommended that you use VARCHAR2 as a variable-sized array of characters.

• LONG – A variable-sized field of characters. The maximum size of this field is 2GB.

Number

• NUMBER (precision, scale) – A variable-sized number, where the precision is between 1 and 38 and size is between -84 and 127. A NUMBER datatype with only one parameter is NUMBER (precision), where the parameter specifies the precision of the number. A NUMBER datatype with no parameters is set to its maximum size.

Date and Time

• DATE – A fixed-sized 7 bit field that is used to store dates. One thing to note is that the time is stored as part of the date. The default format DD-MON-YY can be overridden by NLS_DATE_FORMAT.

• TIMESTAMP (precision) – A variable-sized value ranging from 7 to 11 bytes, that is used to represent a date/time value. It includes both date and time. The precision parameter determines how many numbers are in the fractional part of SECOND field. The precision of the SECOND field within the TIMESTAMP value may have a value ranging from 0 to 9 with a default precision of 6.

• TIMESTAMP (precision) WITH TIME ZONE – A fixed-sized value of 13 bytes, which represents a date/time value along with a time zone setting. There are two ways one can set the time zone. The first is by using the UTC offset, say ‘+10:0’, or secondly by the region name, say ‘Australia/Sydney’.

• TIMESTAMP (precision) WITH LOCAL TIME – A variable value ranging from 7 to 11 bytes. This particular datatype is similar to the TIMESTAMP WITH TIME ZONE datatype. The difference is that the data is normalised to the database time zone when stored. The entry is manipulated to concur with the client’s time zone when retrieved.

Intervals

• INTERVAL DAY (day_precision) TO SECOND (second_precision) – A fixed-sized 11 byte value that represents a period of time. It includes days, hours, minutes and seconds.

• INTERVAL YEAR (year_precision) TO MONTH – A fixed-sized 5 byte value that represents a period of time. It includes years and months.

Binaries

• RAW (size) – A variable-sized field of raw binary data. The maximum size for this datatype is 2000 bytes.

• LONG RAW – A variable-sized field of raw binary data. The maximum size for this datatype is 2 GB.

• BLOB – The Binary Large Object is a field that holds unstructured binary data. The maximum size for this datatype is 4 GB.

• CLOB – The Character Large Object is a field that holds single byte character data. The maximum size for this datatype is 4 GB.

• NCLOB – The National Character Large Object is a field that holds either single byte of multibyte character data dependent on the national character set. The maximum size for this datatype is 4 GB.

• BFILE – An external binary file. The maximum size for this file is 4 GB. The size is also limited by the operating system.

Rows

• ROWID – A datatype that contains binary data that is used to identify a row.

Each ROWID is:

•  
  • 6 bytes for normal indexes on non-partitioned tables, local indexes on partitioned tables and row pointers for chained/migrated rows.
  • 10 bytes for global indexes on partitioned tables.

• UROWID – The Universal ROWID is the datatype used to store both logical and physical ROWID values as well as foreign tables accessed through a gateway.

Alternatives for ANSI Standard Datatypes

Instead of using ANSI standard datatypes, you can use Oracle defined datatypes. View the table below to see the Oracle datatype alternative for ANSI standard datatypes.

Datatypes Used in SQL Server2005

Exact numerics

numeric and decimal are Fixed precision and scale data types and are functionally equivalent.

Approximate numerics

datetime and smalldatetime

Character Strings

Unicode Character Strings

Binary Strings

Other Data Types

• sql_variant: Stores values of various SQL Server-supported data types, except text, ntext, and timestamp.
• timestamp: Stores a database-wide unique number that gets updated every time a row gets updated.
• uniqueidentifier: Stores a globally unique identifier (GUID).
• xml: Stores XML data. You can store xml instances in a column or a variable (SQL Server 2005 only).
• cursor: A reference to a cursor.
• table: Stores a result set for later processing.

References:-

1.       http://www.devarticles.com/c/a/Oracle/Datatypes-Used-in-Oracle-9i/1/

2.      

3.       http://pstcc11.pstcc.edu/~rbarber/hpc2800/handouts/datatypes.htm

4.       http://www.teratrax.com/sql_guide/data_types/sql_server_data_types.html    (sql server datatypes)

5.       http://msdn.microsoft.com/en-us/library/aa258271.aspx  (sql server)