Switch Logfile & Archivelog Current

Alter system switch logfile

It is asynchronous. This command is fast to return to the invoking program because the writing of the redo log to the OS filesystem is done in the background.  Some scripts will place a “sleep 60” command in their backup script to allow time for the redo to complete writing, but this is not a best practice. There is a very small risk in cases where the ARCH process cannot complete writing the redo log, such as cases where the OS archivelog file directory is out of space. It is also risky because the calling script may move on to a subsequent step, assuming that the redo has been written.

Note:

This statement execute if database  Archivelog &  NO Archivelog mode, Just switch logfile from one Group to other Group

Alter system archivelog current

It is synchronous. This is fast because this command waits until the online redo log has completed the writing of the redo log file to the filesystem. This command is safer because it waits for the OS to acknowledge (ACK) that the redo log has been successfully written. Hence, “alter system archivelog current” is the best practice for production backup scripts with RMAN.

Note:

This statement execute if  database in Archivelog mode. It will work in RAC database

Temporary Tablespace Group

Introduced in Oracle 10g “Temporary Tablespace Group”

Temporary Tablespace Group

A temporary tablespace group consists of only temporary tablespace, and has the following properties:

• It contains one or more temporary tablespaces.
• It contains only temporary tablespace.
• It is not explicitly created. It is created implicitly when the first temporary tablespace is assigned to it, and is deleted when the last temporary tablespace is removed from the group.
• 
  

Temporary Tablespace Group Benefits

Temporary tablespace group has the following benefits:

• It allows multiple default temporary tablespaces to be specified at the database level.
• It allows the user to use multiple temporary tablespaces in different sessions at the same time.
• It allows a single SQL operation to use multiple temporary tablespaces for sorting.

Data Dictionary View:  ts$ , dba_tablespace_groups

 Using a tablespace with a temporary tablespace group will result in the following select statement.

select   

   tablespace_name, group_name

from   

   DBA_TABLESPACE_GROUPS;

TABLESPACE_NAME             GROUP_NAME

---------------                -----------

TEMP01                  TEMPGROUP_A

TEMP02                  TEMPGROUP_A

TEMP03                  TEMPGROUP_B

Example 1: 

Create a temporary tablespace and implicitly add it to a temporary tablespace group.

     CREATE TEMPORARY TABLESPACE temp01

     TEMPFILE ‘/u02/oradata/temp01.dbs’ SIZE 500M

     TABLESPACE GROUP tempgroup_a;

Example 2: 

Create a temporary tablespace without assigning it to a temporary tablespace group.

The following two statements are exactly equivalent:

     CREATE TEMPORARY TABLESPACE temp04

     TEMPFILE ‘/u02/oradata/temp04.dbs’ SIZE 200M

     TABLESPACE GROUP ‘’;

     CREATE TEMPORARY TABLESPACE temp04

     TEMPFILE ‘/u02/oradata/temp04.dbs’ SIZE 200M;

Example 3:

 Remove a temporary tablespace from a temporary tablespace group.

This statement will remove temporary tablespace temp04 from its original temporary tablespace group:

     ALTER TABLESPACE temp04 TABLESPACE GROUP ‘‘;

Example 4:

 Add a temporary tablespace to a temporary tablespace group.

     ALTER TABLESPACE temp03 TABLESPACE GROUP tempgroup_b;

Example 5:

 Assign a user to a default temporary tablespace group.

In this case, user Scott will have multiple default temporary tablespaces  A single SQL operation by Scott can use more than one temporary tablespace for sorting.

     ALTER USER scott TEMPORARY TABLESPACE tempgroup_A;

Difference between logical & physical standby database

Physical standby differs from logical standby:

• Physical standby schema matches exactly the source database structure.
• Archived redo logs and FTP directly to the standby database which is always running in "recover" mode.  Upon arrival, the archived redo logs are applied directly to the standby database.

Logical standby is different from physical standby:

• Logical standby database does not have to match the schema structure of the source database.
   
• Logical standby uses LogMiner techniques to transform the archived redo logs into native DML statements (insert, update, delete).  This DML is transported and applied to the standby database.
   
• Logical standby tables can be open for SQL queries (read only), and all other standby tables can be open for updates.
   
• Logical standby database can have additional materialized views and indexes added for faster performance.

Installing Physical standbys offers these benefits:

• An identical physical copy of the primary database
• Disaster recovery and high availability
• High Data protection
• Reduction in primary database workload
• Performance Faster
• Mount Stage – Read only mode

Installing Logical standbys offer:

• Simultaneous use for reporting, summations and queries
• Efficient use of standby hardware resources
• Reduction in primary database workload
• Some limitations on the use of certain datatypes
• Open stage – Read & Write mode

For more complete differences between logical and physical standby databases, see the book "Oracle Data Guard", by Bipul Kumar.

SWAP Disk Uses

In order to provide for the sharing of RAM, a special area of disk called a swap disk is required, and the primary purpose of the swap disk is to hold page frames from in active programs on disk. The purpose of the swap disk is to offload the least-frequently-used (LRU) RAM page frames so that many applications can concurrently share the same memory.

Once RAM pages from inactive programs are written to disk (a page-out), the operating system can make the freed RAM memory available for another active task. Later, when the inactive program resumes execution, the RAM pages are re-loaded from the swap disk into RAM (a page-in). This reloading of RAM pages is called swapping, and swapping is very time-consuming and degrades the performance of the target program.

While having the swap disk ensures concurrent RAM usage above the real amount of RAM, optimal performance requires that the swap disk is never used for active programs. This is because reading RAM pages off of the swap disk is about 14,000 times slower than reading the memory pages from directly from RAM. As we know, disk access is measured in milliseconds, or thousandths of the second, while RAM access is access to in nanoseconds, or billionths of a second

In a VM architecture, the OS will write Ram to the swap disk, even thought the real RAM has not been exceeded. This is done in anticipation of a RAM shortage, and if a real RAM shortage occurs, the LRU RAM frames are already on the swap disk.

For an Oracle server, the goal is to keep all of the RAM memory demands of the database and database connections beneath the amount of physical RAM memory. In an Oracle environment, we can accurately control the amount of RAM memory that is used by the database instance System Global Area (SGA). This is because the Oracle database administrator can issue alter system command to change the RAM memory areas, and can grow and shrink the RAM memory areas on as needed basis.