Thursday, August 25, 2011

11G NEW FEATURES



RENAME ASM DISK GROUP:

11gR2 introduced renamedg utility to rename diskgroups. Before you use the command, ensure that ASM diskgroup is dismounted.

Below is syntax for the command.
 
renamedg 
[phase={ one|two |both } ] dgname=diskgroup
newdgname=newdiskgroup [config=configfile]
[ asm_diskstring=discoverystring, discoverystring ... ]
[ clean={true|false} ] [ check={true|false} ]
[ confirm={true|false}] [ verbose={ true|false} ]
[ keep_voting_files={true|false}]
 

Basically we have two phases of using renamedg command,
phase 1  à generates a configuration file to be used by phase 2.
In phase 2 à actual renaming of diskgroup is done.

Example:

renamedg dgname=data newdgname=dg asm_diskstring='/dev/oracleasm/disks/VOL*'  verbose=true


CASE sensitive passwords:

In Oracle 11g passwords are case sensitive by default. We can enable or disable this feature by setting the SEC_CASE_SENSITIVE_LOGON parameter. 

The SEC_CASE_SENSITIVE_LOGON parameter is a dynamic parameter. In the earlier version of the oracle like 10g & 9i passwords were not case sensitive

SYS@orcl11g>  show parameter SEC_CASE_SENSITIVE_LOGON
 
 
NAME                                             TYPE               VALUE
------------------------------------           -----------       -----------------------
sec_case_sensitive_logon             boolean          TRUE


Creating spfile/pfile from memory

Now we can even create a spfile/pfile from memory. It is a new feature in the 11g. Prior to 11g, we were able to create spfile from pfile or pfile from spfile.

Syntax:

CREATE SPFILE FROM MEMORY;
CREATE PFILE  FROM MEMORY;

Examples:
SYS@orcl11g>CREATE SPFILE='D:\backup\ORCL11G\spfile_bkp_18Jan2010.ora' FROM MEMORY;
File created.

SYS@orcl11g>CREATE PFILE='D:\backup\ORCL11G\pfile_bkp_18Jan2010.ora' FROM MEMORY;
File created.


Read-Only Table :

 

In Oracle 11g we can make a table read-only. It is a new feature in the Oracle 11g. Earlier we were able to make a non-system tablespace read-only. The Oracle 11g goes one step further and allows us to make a table read-only.

We have a new column called
 'read_only' in dba_tables, user_tables and all_tables views which tells whether a table is read only or not.

We will not be able to execute DML statements like INSERT, UPDATE and DELETE on a read-only table. And all so we cannot add/remove columns.
 

Syntax:
  
ALTER TABLE table_name READ ONLY;
ALTER TABLE table_name READ WRITE;


Examples:
 
SCOTT@orcl11g>DROP TABLE test_tbl;

Table dropped.


SCOTT@orcl11g>CREATE TABLE test_tbl AS SELECT * FROM dual;
Table created.


SCOTT@orcl11g>SELECT * FROM test_tbl;

D
-
X


SCOTT@orcl11g>INSERT INTO test_tbl VALUES ('A');
1 row created.

SCOTT@orcl11g>ALTER TABLE test_tbl READ ONLY;
Table altered.


SCOTT@orcl11g>SELECT table_name,read_only FROM user_tables WHERE table_name='TEST_TBL';

TABLE_NAME                     READ_ONLY
------------------------------ ----------
TEST_TBL                       YES


SCOTT@orcl11g>INSERT INTO test_tbl VALUES ('A');
INSERT INTO test_tbl values ('A')
            *
ERROR at line 1:
ORA-12081: update operation not allowed on table "SCOTT"."TEST_TBL"


SCOTT@orcl11g>UPDATE test_tbl SET dummy='Y' WHERE dummy='X';
UPDATE test_tbl SET dummy='Y' WHERE dummy='X'
       *
ERROR at line 1:
ORA-12081: update operation not allowed on table "SCOTT"."TEST_TBL"


SCOTT@orcl11g>DELETE FROM test_tbl;
DELETE FROM test_tbl
            *
ERROR at line 1:
ORA-12081: update operation not allowed on table "SCOTT"."TEST_TBL"


SCOTT@orcl11g>ALTER TABLE test_tbl ADD (name varchar2(10));
ALTER TABLE test_tbl ADD (name varchar2(10))
*
ERROR at line 1:
ORA-12081: update operation not allowed on table "SCOTT"."TEST_TBL"


SCOTT@orcl11g>ALTER TABLE test_tbl DROP COLUMN name;
ALTER TABLE test_tbl DROP COLUMN name
*
ERROR at line 1:
ORA-12081: update operation not allowed on table "SCOTT"."TEST_TBL"


SCOTT@orcl11g>ALTER TABLE test_tbl READ WRITE;

Table altered.


SCOTT@orcl11g>INSERT INTO test_tbl VALUES('A');

1 row created.

SCOTT@orcl11g>


Invisible index :

Invisible index is a new feature of Oracle 11g. If we create an invisible index Oracle optimizer will not use it. This can be used to test a query without effecting the application. We can also make an index invisible/visible by using ALTER INDEX index_name [visible/invisible].

Syntax:

CREATE INDEX index_name ON table_name(column_name) INVISIBLE;
ALTER INDEX index_name INVISIBLE;
ALTER INDEX index_name VISIBLE;

Examples:
SYSTEM@orcl11g>show parameter optimizer_use_invisible_indexes 

NAME                                                                TYPE                 VALUE
------------------------------------                     -----------        --------------------
optimizer_use_invisible_indexes             boolean           FALSE


SYSTEM@orcl11g> desc test


Name Null? Type

----------------------------------------------------- -------- ------------
N NUMBER
NAME VARCHAR2(10)


SYSTEM@orcl11g>create index idx1 on test(n) invisible;
Index created.

SYSTEM@orcl11g>select owner,index_name,visibility from dba_indexes  where visibility = 'INVISIBLE';

OWNER                        INDEX_NAME              VISIBILIT
---------------                 ---------------------            ---------
SYSTEM                             IDX1                        INVISIBLE


SYSTEM@orcl11g>   select * from test where n=5;

N            NAME
------     ----------
5               H

Execution Plan
----------------------------------------------------------
Plan hash value: 1357081020

-------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 20 | 3 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| TEST | 1 | 20 | 3 (0)| 00:00:01 |
--------------------------------------------------------------------------

SYSTEM@orcl11g>alter index idx1 visible;
Index altered.

SYSTEM@orcl11g>  select * from test where n=5;

N           NAME
---------- ----------
5          H

Execution Plan
----------------------------------------------------------
Plan hash value: 1175071277
------------------------------------------------------------------------------------

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |

---------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 20 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST | 1 | 20 | 2 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | IDX1 | 1 | | 1 (0)| 00:00:01 |
---------------------------------------------------------------------------------

Use 1: Adding an index
You think adding an index will improve a query but you are not sure. Just create an invisible index. Test the query and decide.

Use 2: Dropping an index
You want to drop an index but don’t know how it will affect the application. Make that index invisible and analyze the performance. If it is not affecting the performance of the application, you can drop it.


crs_stat has been deprecated in 11gR2

 

While reading whats new and whats deprecated in Oracle 11gR2, I came across of the following:
Command crs_stat has been deprecated  in 11gR2, do not use it anymore, to find out all user resource state use, $GRID_HOME/bin/crsctl stat res -t 
               By the way, in 11gR2 or above, you can use the below command to find out the clusterware process state:      $GRID_HOME/bin/crsctl stat res -t -init


Wednesday, August 24, 2011

Row Migration & Row chaining


What is Row Chaining
-----------------------------


Row Chaining happens when a row is too large to fit into a single database block. For example, if you use a 8KB block size for your database and you need to insert a row of 16KB into it, Oracle will use 2/3 blocks and store the row in chain of data blocks for that segment. And Row Chaining happens only when the row is being inserted.

you can show the block size of database by

SQL> conn / as sysdba
SQL> show parameter db_block_size



What is Row Migration
---------------------
­­­­-----------

Row Migration Occurs when a row that originally fitted into one data block is updated so that the overall row length increases, and the block's free space is already completely filled. In this case, Oracle migrates the data for the entire row to a new data block, assuming the entire row can fit in a new block. Oracle preserves the original row piece of a migrated row to point to the new block containing the migrated row: the rowid of a migrated row does not change.



How can identified Row Chaining and row migration
-------------------------------------------------------------------------


There are 3 ways :-     1) by Analyze command
                                    2) USER_TABLES
                                    3) V$SYSSTAT


FIND & KILL A SESSION

SQL>   SELECT b.tablespace,b.segfile#,b.segblk#,b.blocks,a.sid,a.serial#,a.username,a.osuser, a.status
            FROM v$session a,v$sort_usage b WHERE a.saddr = b.session_addr;
 
TABLESPACE  SEGFILE#    SEGBLK#     BLOCKS  SID   SERIAL#       USERNAME       OSUSER    STATUS
----------------      -----------         ------------        -------      -----     ---------            --------------            --------         -------
TEMP                     0               5515776        128        76     19519          NI_EXT_STR    nibansal         INACTIVE
TEMP                     0               5456512        128        289    4221            VSL9                  visingh           KILLED
TEMP                     0               5438976        128        290    39365         SCOTT1           NBANSAL        KILLED
TEMP                     0               5456384        128        497    1926             AN13                akaushal         KILLED

The command for killing a session :

SQL> ALTER SYSTEM KILL SESSION ' sid,  serial# ';     (or)
SQL> ALTER SYSTEM KILL SESSION ' sid,  serial# '  immediate;

Example:


SQL> ALTER SYSTEM KILL SESSION '76,19519' ;
       (or)
SQL> ALTER SYSTEM KILL SESSION '76,19519'  IMMEDIATE;

For Windows:        C:>  orakill ORACLE_SID spid

For  UNIX :         $   KILL -9 spid;       (get SPID from V$PROCESS)

Monday, August 15, 2011

Oracle Golden Gate


Oracle Golden Gate is a tool provided by oracle for transactional data replication among oracle databases and other RDBMS tools (SQL SERVER, DB2.Etc). Its modular architecture gives you the flexibility to easily decouple or combined to provide best solution to meet the business requirements.
 Because of this flexibility in the architecture, Golden Gate supports numerous business requirements:
  • High Availability
  • Data Integration
  • Zero downtime upgrade and migration
  • Live reporting database
etc
 Oracle Golden Gate Architecture
 Oracle Golden Gate Architecture is composed of the following Components:
 ● Extract
 ● Data pump
 ● Replicat
 ● Trails or extract
 ● Checkpoints
 ● Manager
 ● Collector

 Below is the architecture diagram of GG:
 
 Oracle Golden Gate server runs on both source and target server. Oracle Golden Gate is installed as an external component to the database and it wont uses database resource, in turn it won’t effect database performance. Where as Oracle streams which uses built in packages which are provided by oracle, which uses most of the database resources and there are chances of performance slow down in both source and target databases.
 Let first have a look at architectural components of Oracle Golden Gate:
 EXTRACT:
Extract runs on the source system and it is the extraction mechanism for oracle Golden Gate( capture the changes which happens at the source database).
 The Extract process extracts the necessary data from the database transaction logs. For oracle database transaction logs are nothing both REDO log file data. Unlike streams which runs in the oracle database itself and needs the access to the database. Oracle Golden Gate does not needs access to the oracle database and also it will extract only the committed transaction from the online redo log file.
 Whenever there is a long running transaction which generates more number of redo data will force to switch the redo log file and in turn more number of archive logs will be generated. In these cases the extract process need to read the archive log files to get the data.
 Extract process captures all the changes that are made to objects that are configured for synchronization.  Multiple Extract processes can operate on different objects at the same time. For example once process could continuously extract transactional data changes and stream them to a decision support database. while another process performs batch extracts for periodic reporting or, two extract processes could extract and transmit in parallel to two replicat processes ( with two trails) to minimize target latency when the databases are large.
 DATAPUMP
 Datapump is the secondary extract process within source oracle Golden Gate configuration. You can have the source oracle Golden Gate configured without Datapump process also, but in this case Extract process has to send the data to trail file at the target. If the Datapump is configured the primary extract process writes the data to the source trail file and Datapump will read this trail file and propagate the data over the network to target trail file. The Datapump adds the storage flexibility and it isolates the primary extract process from TCP/IP activity.
 You can configure the primary extract process and Data pump extract to extract online or extract during batch processing.
 REPLICAT
 Replicat process runs on the target system. Replicat reads extracted transactional data changes and DDL changes (IF CONFIGURED) that are specified in the Replicat configuration, and then it replicates them to the target database.
 TRAILS OR EXTRACTS
 To support the continuous extraction and replication of source database changes, Oracle Golden Gate stores the captured changes temporarily on the disk in a series of files call a TRAIL. A trail can exist on the source or target system and even it can be in a intermediate system, depending on how the configuration is done. On the local system it is known as an EXTRACT TRAIL and on the remote system it is known as REMOTE TRAIL.
 The use of a trail also allows extraction and replication activities to occur independently of each other. Since these two ( source trail and target trail) are independent you have more choices for how data is delivered.
 CHECKPOINT
 Checkpoints stores the current read and write positions of a process to disk for recovery purposes. These checkpoints ensure that data changes that are marked for synchronization are extracted by extract and replicated by replicat.
 Checkpoint work with inter process acknowledgments to prevent messages from being lost in the network. OracleGolden Gatehas a proprietary guaranteed-message delivery technology.
 Checkpoint information is maintained in checkpoint files within the dirchk sub-directory of the Oracle Golden Gate directory. Optionally, Replicat checkpoints can be maintained in a checkpoint table within the target database, apart from standard checkpoint file.
 MANAGER
 The Manager process runs on both source and target systems and it is the heart or control process of Oracle Golden Gate. Manager must be up and running before you create EXTRAT or REPLICAT process. Manager performs Monitoring, restarting oracle golden gate process, report errors, report events, maintains trail files and logs etc.
 COLLECTOR
 Collector is a process that runs in the background on the target system. Collector receives extracted database changes that are sent across the TCP/IP network and it writes them to a trail or extract file.
Auto Scroll Stop Scroll