The user who creates a file is the owner of that file. Every file and directory comes with three types of permissions:
• Read: Lets you view the contents of the file only.
• Write: Lets you change the contents of the file. Write permission on a directory will let you create, modify, or delete files in that directory.
• Execute: Lets you execute (run) the file if the file contains an executable program (script).
Read permission is the most basic permission. Having the execute permission without the read permission is of no use,you can’t execute a file if you can’t read it in the first place.

Use the ls -al command to list the file permissions along with the filenames in a directory. For example, look at the (partial) output of the following command:

$ ls -al
-rwxrwxrwx 1 oracle dba 320 Jan 23 09:00 test.ksh
-rw-r—r- 1 oracle dba 152 Jul 18 13:38 updown.ksh
-rw-r—r- 1 oracle dba 70 Nov 22 01:30 tokill.ksh

You’ll notice that at the beginning of each line, each file has a combination of ten different letters and the blank sign (-).
The first letter could be a blank or the letter d. If it is the letter d, then it’s a directory. If it’s a blank, it’s a regular file.
The next nine spaces are grouped into three sets of the letters rwx. The rwx group refers to the read, write, and execute permissions on that file. The first set of rwx indicates the permissions assigned to the owner of the file. The second set lists the permissions assigned to the group the user belongs to. The last set lists the permissions on that file granted to all the other users of the system.

For example, consider the access permissions on the following file:
$ -rwxr-x–x 1 oracle dba Nov 11 2001 test.ksh

Because the first character is a hyphen (-), this is a file, not a directory. The next three characters, rwx, indicate that the owner of the file test.ksh has all three permissions (read, write, and execute) on the file. The next three characters, r-x, show that all the users who are in the same group as the owner have read and execute permissions, but not write permissions. In other words, they cannot change the contents of the file. The last set of characters, –x, indicates that all other users on the system can execute the file, but they cannot modify it.

Any file that you create will first have the permissions set to -rw-r–r–. That is, everybody has read permissions, and no user has permission to execute the file. If you put an executable program inside the file, you’ll want to grant someone permission to execute the file. You can set the permissions on the file by using the chmod command in one of two ways.
First, you can use the symbolic notation, with the letter o standing for owner, g for group, and u for other users on the system. You grant a group or users specific permissions by first specifying the entity along with a plus sign (+) followed by the appropriate symbol for the permission.

In the following example, the notation go+x means that both the group and others are assigned the execute (x) permission on the test.ksh shell script:

$ chmod go+x test.ksh

The next example shows how you can use symbolic notation to remove read and write permissions on a file from the group:

$ chmod g-rw test.ksh

Second, you can use the octal numbers method to change file permissions. Each permission carries different numeric “weights”: read carries a weight of 4, write a weight of 2, and execute a weight of 1. To determine a permission setting, just add the weights for the permissions you want to assign. The highest number that can be associated with each of the three different entities—owner,group, and all others—is 7, which is the same as having read, write, and execute permissions on the file.

For example, consider the following:

$ chmod 777 test.txt
$ ls
$ -rwxrwxrwx 1 oracle dba 102 Nov 11 15:20 test.txt

The file test.txt initially had its file permissions set to 644 (rw, r, r.) The command chmod 777 assigned full permissions (read, write, and execute) to all three entities: owner, group, and all others.
If you want to change this so that only the owner has complete rights and the others have no permissions at all, set the octal number to 700 (read, write, and execute permissions for the owner, and no permissions at all for the group or others) and use the chmod command as follows:

$ chmod 700 test.txt
$ ls -altr test.txt
-rwx—— 1 oracle dba 0 Mar 28 11:23 test.txt

Thanks to Arup Nanda for his excellent presentation.

Acme’s database contains a table called SALES, as you saw earlier. The table has the following structure:

Some users want to add a column called SALE_CATEGORY, which identifies the type of the sale: LOW, MEDIUM, HIGH and ULTRA, depending on the amount of sale and the customer in question. This column will help them identify the records for appropriate action and routing to the concerned employee for handling. Here are the logic for values in the column:

Although this column is a crucial business requirement, the development team does not want to change the code to create the necessary logic. Of course, you could add a new column in the table called sale_category, and write a trigger to populate the column using the logic shown above—a fairly trivial exercise. But performance issues would arise due to context switching from and into the trigger code.

In Oracle Database 11g, you do not need to write a single line of code in any trigger. All you have to do instead is add a virtual column. Virtual columns offer the flexibility to add columns that convey business sense without adding any complexity or performance impact.

Here’s how you would create this table:

SQL> create table sales
  2  (
  3     sales_id      number,
  4     cust_id       number,
  5     sales_amt     number,
  6     sale_category varchar2(6)
  7     generated always as
  8     (
  9        case
 10           when sales_amt <= 10000 then 'LOW'
 11           when sales_amt > 10000 and sales_amt <= 100000 then 'MEDIUM'
 12           when sales_amt > 100000 and sales_amt <= 1000000 then 'HIGH'
 13           else 'ULTRA'
 14        end
 15      ) virtual
 16  );

Note lines 6-7; the column is specified as “generated always as”, meaning the column values are generated at runtime, not stored as part of the table. That clause is followed by how the value is calculated in the elaborate CASE statement. Finally, in line 15,”virtual” is specified to reinforce the fact that this is a virtual column. Now, if you insert some records:

SQL> insert into sales (sales_id, cust_id, sales_amt) values (1,1,100);

1 row created.

SQL> insert into sales (sales_id, cust_id, sales_amt) values (2,102,1500);

1 row created.

SQL>insert into sales (sales_id, cust_id, sales_amt) values (3,102,100000);

1 row created.

SQL> commit;

Commit complete.

SQL> select * from sales;

  SALES_ID    CUST_ID  SALES_AMT SALE_C
---------- ---------- ---------- ------
         1          1        100 LOW
         2        102       1500 LOW
         3        102     100000 MEDIUM

3 rows selected.

the virtual column values are all populated as usual. Even though this column is not stored, you can refer to it as any other column in the table. You can even create indexes on it.

SQL> create index in_sales_cat on sales (sale_category);

Index created.

The result will be a function-based index.

SQL> select index_type
  2  from user_indexes
  3  where index_name = 'IN_SALES_CAT';

INDEX_TYPE
---------------------------
FUNCTION-BASED NORMAL

SQL>  select column_expression
  2  from user_ind_expressions
  3  where index_name = 'IN_SALES_CAT';

COLUMN_EXPRESSION
--------------------------------------------------------------------------------
CASE  WHEN "SALES_AMT"<=10000 THEN 'LOW' WHEN ("SALES_AMT">10000 AND "SALES_AMT"
<=100000) THEN CASE  WHEN "CUST_ID"<101 THEN 'LOW' WHEN ("CUST_ID">=101 AND "CUS
T_ID"<=200) THEN 'MEDIUM' ELSE 'MEDIUM' END  WHEN ("SALES_AMT">100000 AND "SALES
_AMT"<=1000000) THEN CASE  WHEN "CUST_ID"<101 THEN 'MEDIUM' WHEN ("CUST_ID">=101
 AND "CUST_ID"<=200) THEN 'HIGH' ELSE 'ULTRA' END  ELSE 'ULTRA' END

You can even partition on this column, as you saw in the Partitioning installment of this series. You can’t, however, enter a value for this column. If you try to, you won’t get far:

insert into sales values (5,100,300,'HIGH','XX')
            *
ERROR at line 1:
ORA-54013: INSERT operation disallowed on virtual columns

Oracle provides a way to hide code with the PL/SQL Wrapper utility. When
source code has been wrapped, not only is the file unreadable, but also when it
is loaded into the database, the code cannot be read in the data dictionary.

The wrapper utility does not encrypt the code. Instead, it converts it to
hexadecimal digits so that it cannot be read or edited.

example:

SQL> CREATE TABLE lecturer (
2       id               NUMBER(5) PRIMARY KEY,
3       first_name       VARCHAR2(20),
4       last_name        VARCHAR2(20),
5       major            VARCHAR2(30),
6       current_credits  NUMBER(3)
7       );

Table created.

SQL> INSERT INTO lecturer (id, first_name, last_name, major,current_credits)
2   VALUES (10001, ‘Scott’, ‘Lawson’,'Computer Science’, 11);

1 row created.
SQL>  INSERT INTO lecturer (id, first_name, last_name, major, current_credits)
2   VALUES (10002, ‘Mar’, ‘Wells’,'History’, 4);

1 row created.
SQL>  INSERT INTO lecturer (id, first_name, last_name, major,current_credits)
2   VALUES (10003, ‘Jone’, ‘Bliss’,'Computer Science’, 8);

1 row created.
SQL> INSERT INTO lecturer (id, first_name, last_name, major,current_credits)
2  VALUES (10004, ‘Man’, ‘Kyte’,'Economics’, 8);

1 row created.
SQL> INSERT INTO lecturer (id, first_name, last_name, major,current_credits)
2  VALUES (10005, ‘Pat’, ‘Poll’,'History’, 4);

1 row created.
SQL> INSERT INTO lecturer (id, first_name, last_name, major,current_credits)
2  VALUES (10006, ‘Tim’, ‘Viper’,'History’, 4);

1 row created.
SQL> INSERT INTO lecturer (id, first_name, last_name, major,current_credits)
2  VALUES (10007, ‘Barbara’, ‘Blues’,'Economics’, 7);

1 row created.
SQL>  INSERT INTO lecturer (id, first_name, last_name, major,current_credits)
2   VALUES (10008, ‘David’, ‘Large’,'Music’, 4);

1 row created.
SQL>  INSERT INTO lecturer (id, first_name, last_name, major,current_credits)
2   VALUES (10009, ‘Chris’, ‘Elegant’,'Nutrition’, 8);

1 row created.
SQL>  INSERT INTO lecturer (id, first_name, last_name, major,current_credits)
2   VALUES (10010, ‘Rose’, ‘Bond’,'Music’, 7);

1 row created.
SQL>  INSERT INTO lecturer (id, first_name, last_name, major,current_credits)
2   VALUES (10011, ‘Rita’, ‘Johnson’,'Nutrition’, 8);

1 row created.
SQL>  INSERT INTO lecturer (id, first_name, last_name, major,current_credits)
2   VALUES (10012, ‘Sharon’, ‘Clear’,'Computer Science’, 3);

1 row created.

SQL> commit;

Commit complete.

SQL> select * from lecturer;

ID FIRST_NAME           LAST_NAME            MAJOR                          CURRENT_CREDITS
———- ——————– ——————– —————————— —————
10001 Scott                Lawson               Computer Science                            11
10002 Mar                  Wells                History                                      4
10003 Jone                 Bliss                Computer Science                             8
10004 Man                  Kyte                 Economics                                    8
10005 Pat                  Poll                 History                                      4
10006 Tim                  Viper                History                                      4
10007 Barbara              Blues                Economics                                    7
10008 David                Large                Music                                        4
10009 Chris                Elegant              Nutrition                                    8
10010 Rose                 Bond                 Music                                        7
10011 Rita                 Johnson              Nutrition                                    8

ID FIRST_NAME           LAST_NAME            MAJOR                          CURRENT_CREDITS
———- ——————– ——————– —————————— —————
10012 Sharon               Clear                Computer Science                             3

12 rows selected.

i have a file named newrec which has the following stored procedure,

D:\>type newrec.sql
CREATE OR REPLACE PROCEDURE AddNewStudent (
p_FirstName  lecturer.first_name%TYPE,
p_LastName   lecturer.last_name%TYPE,
p_Major      lecturer.major%TYPE) AS
BEGIN
INSERT INTO lecturer (ID, first_name, last_name,
major, current_credits)
VALUES (1, p_FirstName, p_LastName,p_Major, 0);
END AddNewStudent;
/

Now i am going to wrap this file by using the pl/sql wrapper utility.

D:\>wrap iname=newrec.sql oname=newrec_wrap.plb

PL/SQL Wrapper: Release 10.2.0.4.0- Production on Wed Mar 24 15:11:28 2010

Copyright (c) 1993, 2004, Oracle.  All rights reserved.

Processing newrec.sql to newrec_wrap.plb

Now the warped file looks like

D:\>type newrec_wrap.plb
CREATE OR REPLACE PROCEDURE AddNewStudent wrapped
a000000
1
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
7
13c 10b
Ud07xFlyvsFfWzUuUo/ECDS1uwMwgzLQf5kVfC8CkE7VSPOjV6LB3C2tbCWH2WzMbkWgCl6V
nSCroGKsIM/Pz7vijegUtkZn/gAolngi+O5/5ugOzdwrbhdMtmfpY9CJigmxLkM8mroV9ArS
H7pTJvivJxDeNgnJVjK9+jXaRIB7uiunpPRb2bxYzIXYNVSL84v0EbW3GoAW1uctu/KoC+3Z
PVzqN3aRW3Gd9AoPpceWFSKWUU+0qd9AKYvPfMwrfhnBkGlD

/

Now this wrapper file will get compiled without any errors.

SQL> @D:\newrec_wrap.plb

Procedure created.

Even in the data dictionary only your wrapped code exists.
SQL> select text from user_source where NAME=’ADDNEWSTUDENT’;

TEXT
——————————————————————————–
PROCEDURE AddNewStudent wrapped
a000000
1
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd

TEXT
——————————————————————————–
abcd
abcd
abcd
abcd
abcd
abcd
abcd
7
13c 10b
Ud07xFlyvsFfWzUuUo/ECDS1uwMwgzLQf5kVfC8CkE7VSPOjV6LB3C2tbCWH2WzMbkWgCl6V
nSCroGKsIM/Pz7vijegUtkZn/gAolngi+O5/5ugOzdwrbhdMtmfpY9CJigmxLkM8mroV9ArS

TEXT
——————————————————————————–
H7pTJvivJxDeNgnJVjK9+jXaRIB7uiunpPRb2bxYzIXYNVSL84v0EbW3GoAW1uctu/KoC+3Z
PVzqN3aRW3Gd9AoPpceWFSKWUU+0qd9AKYvPfMwrfhnBkGlD

The MERGE statement was introduced in Oracle 9i as part of Oracle’s ETL-enabling technology. It enables us to conditionally update or insert data into a target table and in many cases is more flexible and efficient than previous hand-coded “UPSERT” solutions. With the release of 10g, Oracle has added many enhancements to MERGE, making it a considerably more flexible and powerful statement than its 9i predecessor. For example, MERGE can now UPDATE, DELETE and INSERT with separate conditions for each. It also supports UPDATE-only or INSERT-only operations. We’ll examine such improvements in this article.

setup

Throughout this article, we’ll be using a source and target table to perform the MERGE examples. The target table will have a subset of the source table’s data, meaning that with any MERGE, there will be an “80-20″ mix of UPDATEs and INSERTs. Note that the target table is modified to enable NULL in all columns. This will enable us to keep the column lists short for the INSERT operations in the examples.

SQL> CREATE TABLE src AS SELECT * FROM all_objects WHERE ROWNUM <= 100;

Table created.

SQL> CREATE TABLE tgt AS SELECT * FROM src WHERE ROWNUM <= 80;

Table created.

SQL> ALTER TABLE tgt MODIFY
  2  ( owner         NULL
  3  , object_name   NULL
  4  , object_id     NULL
  5  , created       NULL
  6  , last_ddl_time NULL
  7  );

Table altered.

recap: merge in oracle 9i

We’ll begin by demonstrating a straight MERGE supported by Oracle 9i. We’ll pick an arbitrary operation for UPDATE (in this case setting the OBJECT_NAME to lower case). The DML operations in this example are of little consequence; rather it is the syntax that is important.

SQL> MERGE
  2     INTO  tgt
  3     USING src
  4     ON   (src.object_id = tgt.object_id)
  5  WHEN MATCHED
  6  THEN
  7     UPDATE
  8     SET tgt.object_name = LOWER(src.object_name)
  9  WHEN NOT MATCHED
 10  THEN
 11     INSERT (tgt.object_id, tgt.object_name)
 12     VALUES (src.object_id, src.object_name);

100 rows merged.

This tells us that we’ve merged 100 records. From the setup of the data, we’d expect there to be 80 lower-cased object names in the target table. We can check this with a simple regular expression as follows.

SQL> SELECT COUNT(*)
  2  FROM   tgt
  3  WHERE  REGEXP_LIKE(object_name,'[a-z]');

  COUNT(*)
----------
        80

1 row selected.

Now we’ve revisited the MERGE statement as supported by Oracle 9i, we can move onto the 10g new features and enhancements.

optional insert or update in 10g

In Oracle 10g, either the INSERT or UPDATE operations are optional (you must have one, but not necessarily both, unlike in 9i). This is a critical enhancement and one which makes the MERGE statement much more flexible. In particular, this new feature could make updates with correlated sub-queries a thing of the past as MERGE is easier to code, easier to understand, more flexible, less error-prone and faster. In the following example, we’ll MERGE source into target but ignore new rows by leaving out the INSERT operation. Note how much easier this is to code and read than a “double-correlated UPDATE”.

SQL> MERGE
  2     INTO  tgt
  3     USING src
  4     ON   (src.object_id = tgt.object_id)
  5  WHEN MATCHED
  6  THEN
  7     UPDATE
  8     SET tgt.object_name = LOWER(src.object_name);

80 rows merged.

The following example demonstrates the opposite by leaving out the UPDATE operation. This is the logical equivalent of a conditional INSERT..SELECT statement.

SQL> MERGE
  2     INTO  tgt
  3     USING src
  4     ON   (src.object_id = tgt.object_id)
  5  WHEN NOT MATCHED
  6  THEN
  7     INSERT (tgt.object_id, tgt.object_name)
  8     VALUES (src.object_id, src.object_name);

20 rows merged.

In addition to the conditional INSERT..SELECT above, MERGE also supports unconditional INSERT..SELECT by way of the 1=0 condition which Oracle calls a constant filter predicate. The purpose of this is to avoid a join between source and target. Whether this will draw developers away from coding a straightforward INSERT..SELECT statement will, of course, be a matter of personal preference!

SQL> MERGE
  2     INTO  tgt
  3     USING src
  4     ON   (1 = 0)    --constant filter predicate to avoid join
  5  WHEN NOT MATCHED
  6  THEN
  7     INSERT (tgt.object_id, tgt.object_name)
  8     VALUES (src.object_id, src.object_name);

100 rows merged.

We can see that the unconditional INSERT..SELECT that this example implies has loaded all records from source to target. The lack of keys or constraints on the demonstration tables has allowed this to happen, though in a real system, this would be likely to fail.

conditional dml

With Oracle 10g, we can can now apply additional conditions to the UPDATE or INSERT operation within a MERGE. This is extremely useful if we have different rules for when a record is updated or inserted but we do not wish to restrict the ON condition that joins source and target together. To explain this another way, any filters added to the ON clause, other than the primary join conditions, could increase the likelihood that a record flips over to the “NOT MATCHED” bucket. This would in all probability be wrong and considered a bug.

We can see this in the following example. We MERGE source to target but only wish to UDPATE or INSERT specific matched records. We simply add a suitable predicate (WHERE clause) to the UPDATE and INSERT statements within the MERGE. This does not affect the join between the source and target data in any way so does not change the nature of the MERGE.

SQL> MERGE
  2     INTO  tgt
  3     USING src
  4     ON   (src.object_id = tgt.object_id)
  5  WHEN MATCHED
  6  THEN
  7     UPDATE
  8     SET tgt.object_name = LOWER(src.object_name)
  9     WHERE src.object_type = 'PACKAGE'
 10  WHEN NOT MATCHED
 11  THEN
 12     INSERT (tgt.object_id, tgt.object_name)
 13     VALUES (src.object_id, src.object_name)
 14     WHERE src.created > TRUNC(SYSDATE) - 365;

20 rows merged.

We can see that these predicates have restricted the number of records merged.

deleting during a merge

Possibly the most unexpected 10g enhancement to MERGE is the ability to conditionally DELETE rows from the target dataset during an UPDATE operation. There are a couple of important points to note regarding this. First, the DELETE works against conditions on the target data, not the source. Second, the DELETE works only on rows that have been updated as a result of the MERGE. Any rows in the target table that are not touched by the MERGE are not deleted, even if they satisfy the DELETE criteria.

We’ll begin with a simple example of the DELETE operation. We’ll remove any records that are in both the source and target data (i.e. WHEN MATCHED) that are of OBJECT_TYPE = ‘TYPE’.

SQL> MERGE
  2     INTO  tgt
  3     USING src
  4     ON   (src.object_id = tgt.object_id)
  5  WHEN MATCHED
  6  THEN
  7     UPDATE
  8     SET tgt.object_name = LOWER(src.object_name)
  9     DELETE
 10     WHERE tgt.object_type = 'TYPE'
 11  WHEN NOT MATCHED
 12  THEN
 13     INSERT (tgt.object_id, tgt.object_name)
 14     VALUES (src.object_id, src.object_name);

100 rows merged.

We can now look a bit more closely at the MERGE-UPDATE-DELETE operation and what data it affects. First, we’ll populate the target table with new data and add some of the same records to the source data to ensure we have matches.

SQL> TRUNCATE TABLE tgt;

Table truncated.

SQL> TRUNCATE TABLE src;

Table truncated.

SQL> INSERT ALL
  2     WHEN object_type IN ( 'PACKAGE', 'PACKAGE BODY' )
  3     THEN INTO tgt
  4     WHEN object_type IN ( 'PACKAGE', 'PACKAGE BODY' )
  5     AND  object_name LIKE 'DBMS%'
  6     THEN INTO src
  7  SELECT *
  8  FROM   all_objects;

2320 rows created.

SQL> SELECT object_type
  2  ,      COUNT(*)
  3  FROM   src
  4  GROUP  BY
  5         object_type;

OBJECT_TYPE           COUNT(*)
------------------- ----------
PACKAGE                    374
PACKAGE BODY               367

2 rows selected.

SQL> SELECT object_type
  2  ,      COUNT(*)
  3  FROM   tgt
  4  GROUP  BY
  5         object_type;

OBJECT_TYPE           COUNT(*)
------------------- ----------
PACKAGE                    816
PACKAGE BODY               763

2 rows selected.

Using ALL_OBJECTS data, we’ve setup the example such that the source and target tables contain data relating only to packages. The source table has a subset of the target data and only contains packages that begin with ‘DBMS’. The target table contains data for all packages. Using this data, we can easily demonstrate the effect of a conditional DELETE. In the following example, we’ll MERGE the source table into the target table but include a DELETE of any matched records that have an OBJECT_TYPE = ‘PACKAGE’. For simplicity, we’ll use an update-only MERGE.

SQL> MERGE
  2     INTO  tgt
  3     USING src
  4     ON   (src.object_id = tgt.object_id)
  5  WHEN MATCHED
  6  THEN
  7     UPDATE
  8     SET tgt.object_name = LOWER(src.object_name)
  9     DELETE
 10     WHERE tgt.object_type = 'PACKAGE';

741 rows merged.

Remember that the DELETE condition should only be tested against records that match. In this case, the only records that should match are those that begin with ‘DBMS’ (these were the only packages in the source table). Following the MERGE, therefore, we should have no packages in our target table that begin with ‘DBMS’. The records in the target table that did not have a matching source record should remain. We can test this by counting both the number of packages and just those that begin with ‘DBMS’ as below.

SQL> SELECT SUM( CASE object_type
  2                 WHEN 'PACKAGE'
  3                 THEN 1
  4                 ELSE 0
  5              END ) AS package_records
  6  ,      SUM( CASE
  7                 WHEN object_type = 'PACKAGE'
  8                 AND  object_name LIKE 'DBMS%'
  9                 THEN 1
 10                 ELSE 0
 11              END ) AS dbms_package_records
 12  FROM   tgt;

PACKAGE_RECORDS DBMS_PACKAGE_RECORDS
--------------- --------------------
            442                    0

1 row selected.

As we can see, despite requesting a DELETE for OBJECT_TYPE = ‘PACKAGE’, we still have 442 records of this type in the target table. As stated, this data does not have a match in the source data and therefore is not subjected to the DELETE.

To demonstrate that we did get some updates, we can look at the data that would have matched during the MERGE but would not have satisfied the DELETE criteria. This time, we expect this to be package body records that begin with ‘DBMS’. For this data, we would expect the OBJECT_NAME to be lower-cased as a result of the MERGE. We can look at a small sample as below.

SQL> SELECT object_name
  2  FROM   tgt
  3  WHERE  object_type = 'PACKAGE BODY'
  4  AND    object_name LIKE 'dbms%'
  5  AND    ROWNUM <= 3;

OBJECT_NAME
------------------------------
dbms_aq_exp_queues
dbms_prvtaqip
dbms_prvtaqis

3 rows selected.

2) Add the new path (new disks from the new storage) to your asm_disktring to be recognized by ASM:

Example:

SQL> alter system set asm_disktring = ‘/dev/dellpowerc*’ , ‘/dev/dellpowerh*’;

Where: ‘/dev/dellpowerc*’ are the current disks.
Where: ‘/dev/dellpowerh*’ are the new disks.

3) Confirm that the new disks are being detected by ASM:

SQL> select path from v$asm_disk;

4) Add the new disks to your desired diskgroup:

SQL> alter diskgroup <diskgroup name> add disk
‘<new disk 1>’,
‘<new disk 2>’,
‘<new disk 3>’,
‘<new disk 4>’,
.
.
.
‘<new disk N>’;

5) Then wait until the rebalance operation completes:

SQL> select * from v$asm_operation;

6) Finally, remove the old disks:

SQL> alter diskgroup <diskgroup name> drop disk
<disk name A>,
<disk name B>,
<disk name D>,
<disk name E>,
.
.
.
<disk name X>;

7) Then wait until the rebalance operation completes:

SQL> select * from v$asm_operation;

8) Done, your ASM diskgroups and database have been migrated to the new storage.

Note: Alternatively, we can execute add disk & drop disk statements in one operation, in that way only one rebalance operation will be started as follow:

SQL> alter diskgroup <diskgroup name>
add disk ‘<new device physical name 1>’, .., ‘<new device physical name N>’
drop disk <old disk logical name 1>, <old disk logical name 2>, ..,<old disk logical name N>
rebalance <#>;

This is more efficient than separated commands (add disk & drop disk statements).

Wow …..

It  will be a great challenge for Oracle to swipe  IBM in Hardware Business.

And We can expect a Large improvements in Solaris and Sparc as Larry said.

It provides the basic clustering services at the operating system level that enable Oracle software to run in clustering mode. In earlier versions of  Oracle (version 9i and earlier), RAC required a vendor supplied clusterware like Sun Cluster or Veritas Cluster Server and with a seperate software for  Linux and Windows.

Oracle clusterware naming Evolution:

In 9i     - Third Party softwares  (Sun Cluster or Veritas Cluster Server)
In 10gR1-Cluster  Ready services (Oracle corporation)
In 10gR2- Oracle Clusterware     (Oracle corporation)

Oracle Clusterware stores configuration information in the Oracle Cluster Repository (OCR),
which must be located on shared storage available to all nodes. The Membership of the cluster is determined using a  file known as the voting disk, which must also be available to all nodes. Voting Disk  acts a tiebreaker during communication failures and  Consistent heartbeat information from all the nodes is sent to voting disk when the cluster is running .

Oracle Clusterware comprises a set of daemons(Background process).

1.Cluster Ready Services Daemon(crsd)

This component manages high availability operations within the cluster. Objects managed by CRS are known as resources and can include databases, instances, services, listeners, virtual IP addresses, and application processes. By default, CRS manages four application process resources: Oracle Net listeners, virtual IP addresses, the Global Services Daemon (GSD), and the Oracle Notification Service (ONS).

Configuration information about each resource is stored in the Oracle Cluster Repository
(OCR). When the status of a resource changes, CRS generates an event.

CRS monitors resources, such as instances and listeners. In the event of the failure of a resource, CRS will attempt to automatically restart the component.

2.Oracle Cluster Synchronization Service Daemon (OCSSD)

This component manages the cluster configuration by controlling which nodes are members of the cluster. When a node joins or leaves the cluster, CSS notifies the other nodes of the change in configuration.
If this process fails, then the cluster will be restarted.

3.Event Volume Manager Daemon (evmd)

The EVM component publishes events created by Oracle Clusterware. It will restart Automatically on failures and death of the evmd process does not halt the instance

4.Process Monitor Daemon (oprocd)

Oprocd provides the I/O Fencing solution for the Oracle Clusterware. It is the process monitor for the oracle clusterware and it uses the hang check timer or watchdog timer (depending on the implementation) for the cluster integrity.

Platform: windows server 2003
Database : 10.2.0.4

Recently we have faced an problem with Gathering statistics which leads to
an oracle internal error (Ora-00600).

There is a  production database which has doing some  large transactions.

we usally gather the statistics for this database bettweeen the interval of two weeks .

we will gather the ststistics using the folowing method

exec dbms_stats.gather_schema_stats(ownname=>’user01′,estimate_percent=>dbms_stats.auto_sample_size,cascade=>true);

Last night we have gathered statistics for the a schema .
Suddenly  Only the next day morning Our users reported that some Oracle errors is
flashed  on one of our applications when accessing some particular form .

Then we tried to find the table on which that particular form is been accessing,
and we manually quried a simple statement on tht table:

SQL> select * from Tabular_data;
select * from Tabular_data
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [19004], [], [], [], [], [], [], []

After some search about the argument [19004] we finally understood that it is as a Bug .

This bug is due to the miscalculation of the Oracle’S Automatic Historgram collection on the table
columns .

since we dint mention any method_opt parameter on the above statement , it leads to its default value

method_opt=>’FOR ALL COLUMNS SIZE AUTO’ (Oracle 10g’s Default value)

So we decided to include the method_opt parameter with the size 1 which is the default value in
Oracle 9i.

method_opt=>’FOR ALL COLUMNS SIZE 1′ (Oracle 9i’s Default value)

This method will disable the collection of Histograms.

if we cant loose histograms , Ofcourse the Another way to escape from this error is to lock the

Statistics for that particular table and to proceed with the older approach .
SQL> exec dbms_stats.lock_table_stats(‘USER01′, ‘TABULAR_DATA’);

PL/SQL procedure successfully completed.

SQL> SELECT stattype_locked FROM dba_tab_statistics

WHERE table_name=’TABULAR_DATA’;

STATTYPE_LOCKED
——————–
ALL

So you cant able to gather statistics on the locked table.

Yes . Because the table and index resides in the different namespaces.

A namespace defines a group of object types, within which all names must be uniquely identified—by schema and name. Objects in different namespaces can share the same name.

These object types all share the same namespace:
• Tables
• Views
• Sequences
• Private synonyms
• Stand-alone procedures
• Stand-alone stored functions
• Packages
• Materialized views
• User-defined types

So  it is impossible to create a view with the same name as a table; at least, it
is impossible if they are in the same schema.

These object types each have their own namespace:
• Indexes
• Constraints
• Clusters
• Database triggers
• Private database links
• Dimensions
Thus it is possible for an index to have the same name as a table, even within the
same schema.

SQL> select namespace from v$librarycache;

NAMESPACE
———————————————
SQL AREA
TABLE/PROCEDURE
BODY
TRIGGER
INDEX
CLUSTER
OBJECT
PIPE
JAVA SOURCE
JAVA RESOURCE
JAVA DATA

11 rows selected.

Here there is an small test:

SQL> create table t1 as select *  from user_objects;

Table created.

SQL> create index t1 on t1(object_id);

Index created.

SQL>  CREATE OR REPLACE package t1 as (ENO VARCHAR2);
2  /
CREATE OR REPLACE package t1 as (ENO VARCHAR2);
*
ERROR at line 1:
ORA-00955: name is already used by an existing object

Here we are getting the error because the packages and tables resides in the same namespace.

With Oracle Database 10g, Oracle rationalizes SQL tracing through a new built-in package, DBMS_MONITOR,
which encompasses the functionality of previously undocumented trace tools, such as the DBMS_SUPPORT package.
Now you can easily trace any user’s session from beginning to end—from client machine to middle tier to back end—and generate trace
files based on specific client ID, module, or action.

Now you can add your own reference to the trace file for your easy identification,

alter session set
tracefile_identifier =”webapp”;

Trace files generated by this command have the string value with “webapp”

The DBMS_MONITOR package has routines for enabling and disabling statistics aggregation as well as for tracing by session ID,
or tracing based upon a combination of service name, module name, and action name.

PL/SQL developers can embed calls into their applications by using the DBMS_APPLICATION_INFO package to set module and action names

The service name is determined by the connect string used to connect to a service. User sessions not associated with a specific service are handled by sys$users (sys$background is the default service for the background processes).
Since we have a service and a module name, we can turn on tracing for this module as follows:

SQL> exec dbms_monitor.serv_mod_act_trace_enable(service_name=>’test’, module_name=>’w3link’);

PL/SQL procedure successfully completed.

To Disable:

SQL>exec dbms_monitor.serv_mod_act_trace_disable(service_name=>’test’, module_name=>’w3link’);

PL/SQL procedure successfully completed.
Tracing For a particular session:
 
SQL> select sid, serial#, username
from v$session;

   SID     SERIAL#  USERNAME
     ——    ——-  ————
       103       4152  SYS
       107       2418  SYSMAN
       129         53  TEST
       130        561  HR
       141          4  DBSNMP
. . .
       168          1
       169          1
       170          1
15 rows selected.
SQL> exec dbms_monitor.session_trace_enable
(session_id=>129, serial_num=>53, waits=>true, binds=>TRUE);
PL/SQL procedure successfully completed.
SQL> exec dbms_monitor.session_trace_disable(129);
PL/SQL procedure successfully completed.

Few are the well known rules

-Enabling indexes to eliminate the need for full table scans

-Avoid Cartesian joins

–Use UNION ALL instead of UNION – if possible

–Use EXIST clause instead of IN – (Wherever appropiate)

–Use order by when you really require it – Its very costly

–When joining 2 views that themselves select from other views, check that the 2 views that you are using do not join the same tables!

–Avoid NOT in or NOT = on indexed columns. They prevent the optimizer from using indexes. Use where amount > 0 instead of where amount != 0

- Avoid writing where is not null. nulls can prevent the optimizer from using an index

- Avoid calculations on indexed columns. Write WHERE amount > 26000/3 instead of WHERE approved_amt/3 > 26000

Some important ASM key features are:

· Volume Management
· Database File System with performance of RAW I/O
· Supports clustering (RAC) and single instance
· Automatic data distribution
· Online add/drop/resize disk with automated data relocation
· Automatic file management
· Flexible mirror protection

Basically, ASM is a storage manager designed to manage Oracle Database files with Volume Manager (1MB/128KB striping, Flexible mirroring and Online disk reconfigurations and automatic rebalancing), File System (Even data distribution with optimal performance) and Automatic file management using Oracle Managed Files (OMF).

Files supported by ASM

Only Oracle files are supported:

Data files
Control files
Online redo log files
Archived redo log files
Flash recovery area files
RMAN files (image copy and backup)

 Files not Supported:

ORACLE_BASE files( including alert log, trace files, etc)
CRS voting disk and OCR files
Output data from UTL_FILE
Any user or application specific files(e.g. XML or Java files)
Oracle 9i external table files

Here is the complete SQL Statement:

“update seq$ set increment$=:2, minvalue=:3, maxvalue=:4, cycle#=:5, order$=:6, cache=:7, highwater=:8, audit$=:9, flags=:10 where obj#=:1”

Immediately, I queried Oracle data dictionary for a list of sequences of one of our most important schema. Following is the query and its output:

sql>select sequence_name, cache_size, last_number from dba_sequences

where sequence_owner = ‘OM_TEST’;

SEQUENCE_NAME                  CACHE_SIZE       LAST_NUMBER

—————————— ———-                         ———–

SEQ_AUDIT_DETAILS             0                                     6728991
SEQ_MTR_LOG                             0                                    1
SEQ_TRANS_LOG                        20                                  991

Sequence “SEQ_AUDIT_DETAILS” seems to be a culprit here, it has been used for more than 6 Million times and is not cached.

Upon further investigation, it was revealed that this sequence is used by an audit detail table to generate unique serial.

I altered the sequence definition to cache 1000 values. Caching instructs Oracle to pre-allocate (in my case 1000) values in the memory for faster access.

SQL> alter sequence seq_audit_details cache 1000;

The above ALTER command did a magic and the UPDATE statement vanished from the AWR reports.

We need to cache sequences whenever possible to avoid extra physical I/O.

I Have taken an export of a particular user  which dump size is nearly to 14 gb.

While I am importing it  , i got an import error which says ,

illegal lob length marker 65279
bytesread = 00000000000
TABLE =cm_test
IMP-00098: INTERNAL ERROR: impgst2
IMP-00018: partial import of previous table completed: 2031183 rows imported
IMP-00008: unrecognized statement in the export file:
ÿþÿþÿþÿ
IMP-00008: unrecognized statement in the export file:
IMP-00008: unrecognized statement in the export file:
IMP-00008: unrecognized statement in the export file:
IMP-00008: unrecognized statement in the export file:
IMP-00008: unrecognized statement in the export file:

All the  googles and forums mentioned that the export dump file is corrupted .

So  later i have taken an export once again with the large buffer size (buffer=300000000)

And then the export has been taken successfully ,

Later i try to import it by setting the same buffer parameter (buffer=300000000) and the import error message seems to be vanished .

This  same issue is been reported as a Bug by oracle support in 10.1.0.3, But this  bug has been fixed in 10.1.0.4 and Later.

Bug no: 3890213  IMP-98 possible importing zero length Lobs with CHUNKSIZE > 32767

Here is a small test I performed to see how index existence would affect the DML statements. For the test case, I create a small table without indexes, inserted 100,000 records and measure the time taken. I repeat the same test but this time with indexes on all columns. The difference in timing will show us, how much expensive are our indexes.

Test 1: Without Indexes

SQL> set serveroutput on
SQL> create table t(a number, b varchar2(30), c date);

Table created.

SQL> declare
2     x number;
3   begin
4     x := dbms_utility.get_time;
5     for i in 1..100000 loop
6       insert into t values(i, ‘value = ‘ || i, sysdate + mod(i,365));
7     end loop;
8   dbms_output.put_line(‘Time taken WITHOUT indexes : ‘ ||to_char(dbms_utility.get_time – x));
9  end;
10  /
Time taken WITHOUT indexes : 1200

PL/SQL procedure successfully completed.

Now, repeat the same test by creating indexes on all the three columns.

Test 2: With Indexes:

SQL> drop table t purge;

Table dropped.

SQL> create table t(a number, b varchar2(30), c date);

Table created.

SQL> create index t_idx1 on t(a);

Index created.

SQL> create index t_idx2 on t(b);

Index created.

SQL> create index t_idx3 on t(c);

Index created.

SQL>  declare
2   x number;
3   begin
4     x := dbms_utility.get_time;
5     for i in 1..100000 loop
6       insert into t values(i, ‘value = ‘ || i, sysdate + mod(i,365));
7     end loop;
8     dbms_output.put_line(‘Time taken WITH indexes : ‘ ||to_char(dbms_utility.get_time – x));
9   end;
10 /
Time taken WITH indexes : 4772

PL/SQL procedure successfully completed.

Well, it’s evident from the above tests that having too many indexes surely affects performance of DML statements. When I had three indexes, time taken to process 100,000 records was more than double compared to process the same number of records without indexes. Moral of the test is to create indexes when required and avoid over-creating them

GATHER_FIXED_OBJECT_STATS

GATHER_DICTIONARY_STATS
GATHER_FIXED_OBJECT_STATS collects statistics for fixed X$ and K$ objects. It needs to be run whenever any init.ora parameter is changed. Fixed objects are the magic tables that are not tables – they are not “dictionary” tables. The x$ tables would change size in response to init.ora setting changes generally. Setting processes higher will add rows to various x$ views for example.

So, they could be considered a one time thing unless you make a big change to your parameter
settings.

GATHER_DICTIONARY_STATS collects statistics for SYS schema. It needs to be run whenever you do “big things” to the dictionary (loaded a schema – not put data into the schema, but rather did things in the schema that affect the dictionary like creating and dropping objects…) – you would consider gathering statistics.

Look at last_analyzed for the sys tables to see when the dictionary was gathered against. Metalink Note 281793.1 states that the DBA_OPTSTAT_OPERATIONS view may be used to determine the start and end time of all DBMS_STATS operations executed at the schema and database level.

Today the refresh job of one of the mviews we use for this purpose started getting “ORA-00001 unique constraint violated” error. This was an mview with a unique index on it. After a simple search in Metalink I have found the reason of this behavior.

I will provide a simple test case to reproduce the problem.

SQL> select * from v$version;

BANNER
—————————————————————-
Oracle9i Enterprise Edition Release 9.2.0.8.0 – 64bit Production
PL/SQL Release 9.2.0.8.0 – Production
CORE    9.2.0.8.0       Production
TNS for Solaris: Version 9.2.0.8.0 – Production
NLSRTL Version 9.2.0.8.0 – Production

SQL> create table master as select rownum r,’ROW’||rownum line from all_objects where rownum<=5;
Table created.

SQL> alter table master add primary key(r);

Table altered.

SQL> create unique index master_ind on master(line);

Index created.

SQL> create materialized view log on master with primary key;

Materialized view log created.

SQL> create materialized view snap refresh fast with primary key as select * from master;

Materialized view created.

SQL> create unique index snap_ind on snap(line);

Index created.

SQL> select * from master;

R LINE
———- ——————————————-
1 ROW1
2 ROW2
3 ROW3
4 ROW4
5 ROW5

After these steps we have now one master table, an mview log on it and a fast refreshable mview of the master table. Now we make some updates to the master table to switch the LINE column’s data of two rows.

SQL> update master set line=’DUMMY’ where r=1;

1 row updated.

SQL> update master set line=’ROW1′ where r=2;

1 row updated.

SQL> update master set line=’ROW2′ where r=1;

1 row updated.

SQL> commit;

Commit complete.

SQL> select * from master;

R LINE
———- ——————————————-
1 ROW2
2 ROW1
3 ROW3
4 ROW4
5 ROW5

Now when we try to refresh the mview we get the error.

SQL> exec dbms_mview.refresh(‘SNAP’);
BEGIN dbms_mview.refresh(‘SNAP’); END;

*
ERROR at line 1:
ORA-12008: error in materialized view refresh path
ORA-00001: unique constraint (YAS.SNAP_IND) violated
ORA-06512: at “SYS.DBMS_SNAPSHOT”, line 820
ORA-06512: at “SYS.DBMS_SNAPSHOT”, line 877
ORA-06512: at “SYS.DBMS_SNAPSHOT”, line 858
ORA-06512: at line 1

If we drop the unique index and recreate it as nonunique we can refresh the mview without errors.

SQL> drop index snap_ind;

Index dropped.

SQL> create index snap_ind on snap(line);

Index created.

SQL> exec dbms_mview.refresh(‘SNAP’);

PL/SQL procedure successfully completed.

SQL> select * from snap;

R LINE
———- ——————————————-
1 ROW2
2 ROW1
3 ROW3
4 ROW4
5 ROW5

The reason of this error is explained in Metalink note 284101.1. According to that note the refresh mechanism may temporarily leave the data in an inconsistent state during the refresh. The modifications are not made with the same order as the modifications to the master table. Because of this creating unique indexes, foreign keys or primary keys on mviews can cause problems in the refresh process. This totally makes sense as it is better to keep the integrity checks on the master table rather than the mview. An mview is just a copy of the master table, so if we define the integrity constraints on the master table the mview will take care of itself.

This behaviour reproduces in 10G also.

It is important to make sure that index monitoring is performed over a representative time period. If you only monitor indexes during specific time frames you may incorrectly highlight indexes as being unused. The safest method is to use a monitoring period which spans the whole lifecycle of your application, including any OLTP and batch operations. In a Decision Support System (DSS) this may involve a period of weeks or months, while OLTP systems typically have shorter cycles.

ALTER INDEX

Index monitoring is started and stopped using the ALTER INDEX syntax shown below.

ALTER INDEX my_index_i MONITORING USAGE;
ALTER INDEX my_index_i NOMONITORING USAGE;

Information about the index usage can be displayed using the V$OBJECT_USAGE view.

SELECT index_name,
       table_name,
       monitoring,
       used,
       start_monitoring,
       end_monitoring
FROM   v$object_usage
WHERE  index_name = 'MY_INDEX_I'
ORDER BY index_name;

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

SET PAGESIZE 0
SET FEEDBACK OFF
SET VERIFY OFF
SPOOL temp.sql

SELECT 'ALTER INDEX "' || i.owner || '"."' || i.index_name || '" MONITORING USAGE;'
FROM   dba_indexes i
WHERE  owner      = UPPER('&1')
AND    table_name = DECODE(UPPER('&2'), 'ALL', table_name, UPPER('&2'));

SPOOL OFF

SET PAGESIZE 18
SET FEEDBACK ON

@temp.sql

-----------------------------------------------
SET PAGESIZE 0
SET FEEDBACK OFF
SET VERIFY OFF
SPOOL temp.sql

SELECT 'ALTER INDEX "' || i.owner || '"."' || i.index_name || '" NOMONITORING USAGE;'
FROM   dba_indexes i
WHERE  owner      = UPPER('&1')
AND    table_name = DECODE(UPPER('&2'), 'ALL', table_name, UPPER('&2'));

SPOOL OFF

SET PAGESIZE 18
SET FEEDBACK ON

@temp.sql

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

Foreign Key Indexes

To quote the Oracle Database Concepts manual:

“You should almost always index foreign keys. The only exception is when the matching unique or primary key is never updated or deleted.”

When a foreign key is unindexed, DML on the parent primary key results in a share row exclusive table lock (or share-subexclusive table lock, SSX) on the child table, preventing DML from other transactions against the child table. If the DML affects several rows in the parent table, the lock on the child table is obtained and released immediately for each row in turn. Despite the speed of the lock-release process, this can cause significant amounts of contention on the child table during periods of heavy update/delete activity on the parent table.

When a foreign key is indexed, DML on the parent primary key results in a row share table lock (or subshare table lock, SS) on the child table. This type of lock prevents other transactions from issuing whole table locks on the child table, but does not block DML on either the parent or the child table. Only the rows relating to the parent primary key are locked in the child table.

Resumable space allocation, introduced in Oracle 9i, is for all tablespaces at the session level. Database operations are suspended when an out-of-space condition is encountered. These suspended operations automatically resume when the error condition disappears. In Oracle Database 10g, this can be enabled at the instance level. Besides this improvement, automatic alert notification is sent when an operation is suspended.

In  Oracle 10gR1 the parameter RESUMABLE_TIMEOUT
can also be set on system level for all sessions.
SQL*Plus: Release 10.2.0.4.0 – Production on Tue Mar 31 11:58:08 2009

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

Enter user-name: / as sysdba

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 – Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> create user test identified by test
  2  default tablespace example
  3  quota 1m on example;

User created.

SQL> grant create session ,create table to test;

Grant succeeded.

SQL> conn test
Enter password:
Connected.
SQL> create table t1 (eno number);

Table created.
SQL> BEGIN FOR i IN 1..10000 LOOP
  2   INSERT INTO t1 VALUES(i);
  3  END LOOP;
  4   COMMIT;
  5   END;
  6  /

PL/SQL procedure successfully completed.
SQL>  insert into t1 select * from t1;

10000 rows created.

SQL>  insert into t1 select * from t1;

20000 rows created.

SQL>  insert into t1 select * from t1;
 insert into t1 select * from t1
*
ERROR at line 1:
ORA-01536: space quota exceeded for tablespace ‘EXAMPLE’

SQL> SELECT COUNT(*) FROM t1;

  COUNT(*)
———-
     40000

SQL> ALTER SESSION ENABLE RESUMABLE TIMEOUT 600;
ERROR:
ORA-01031: insufficient privileges
SQL> conn sys as sysdba
Enter password:
Connected.
SQL> grant resumable to test;

Grant succeeded.
SQL> conn test
Enter password:
Connected.
SQL>  insert into t1 select * from t1;
 insert into t1 select * from t1
*
ERROR at line 1:
ORA-01536: space quota exceeded for tablespace ‘EXAMPLE’
SQL> ALTER SESSION ENABLE RESUMABLE TIMEOUT 600;

Session altered.

SQL>  insert into t1 select * from t1;(this statement will wait )

————————from Another session (session 2) ——————-

SQL*Plus: Release 10.2.0.4.0 – Production on Tue Mar 31 12:19:46 2009

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.
Enter user-name: / as sysdba
SQL> select sid,state,event from v$session_wait where sid=159;

       SID STATE         EVENT
———- ———– ——————————————-

       159 WAITING     statement suspended, wait error to be cleared

SQL> alter user test quota unlimited on example;

User altered.
————————Now check the SESSION 1—————————-
SQL>  insert into t1 select * from t1;

40000 rows created.

In our Production database(10.2.0.4) , currently we are using a backup  stratergy with
a full backup once a month and an incremental backup each week and the archived logs are backed up once a day.
All backups are directly taken in the  tape drives through a network , These tape drives are located in the different server…

In case of any recovery issues we need to transfer the backup sets from the tape to the disk through the network,so we found that there is some increase in the  recovery time .
And we decided to increase the frequency of the incremental backup in order to reduce its size .So we decided to use the Oracle 10g new feature of Block Change Tracking .

Block change tracking causes the changed database blocks to be flagged in a file.As data blocks change, the Change Tracking Writer (CTWR) background process tracks the changed blocks in a private area of memory. When a commit is issued against the data block, the block change tracking information is copied to a shared area in Large Pool called the CTWR buffer. During the checkpoint, the CTWR process writes the information from the CTWR RAM buffer to the change-tracking file.To achive this we need to enable the block change traking in our database:

SQL> conn sys as sysdba;
connected.

SQL> SELECT status FROM v$block_change_tracking;

STATUS
—————————————-
DISABLED

To enable this you need to create a new file for block change traking.

SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
  2  using file ‘D:\ORACLE\PRODUCT\10.2.0\ORADATA\PRD\change_track_file.dbf’ reuse;

Database altered.

SQL> SELECT status FROM v$block_change_tracking;

STATUS
—————————————-
ENABLED

If a block is changed in the database, the fact is recorded in this  file:D:\ORACLE\PRODUCT\10.2.0\ORADATA\PRD\change_track_file.dbf.
During incremental backup, RMAN checks this file to see which blocks need to be backed up instead of checking all the blocks of a data file.

It dramatically reduces CPU cycles and speeds up incremental backup in the process.
The block change tracking file, if present, is used automatically by the incremental backup; no special RMAN syntax is required. Using a block change tracking file saves enough time and CPU cycles  to take incremental backups every  night instead of taking once a week.

In case if you want to disable it ,you can use the below syntax.

SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
 
Database altered.