Showing posts with label Index. Show all posts
Showing posts with label Index. Show all posts

Thursday, 20 October 2016

How to Drop Indexes/ Unique Indexes in Oracle?

There can be multiple situations where we don’t require indexes and have to drop them.

  • Sometimes it’s better to drop the indexes when there is not much performance gain for your table with indexes.
  • Once the indexes becomes invalid, you must first drop the indexes before rebuilding it.
  • If your indexes are too fragmented, it’s better to drop the indexes and create a new index since rebuilding an index requires twice the space of the index.

All the extents of the index segment are restored to the containing table
space once you drop the index so that it becomes available to other objects in the table space.

Below is the command to drop indexes:
SYNTAX : DROP INDEX [OWNER.]INDEXNAME [FROM [OWNER.]TABLENAME]
EXAMPLE:
SQL> DROP INDEX EMP_NAME_IDX;
INDEX DROPPED
 SQL>


Conversely, you can't drop any implicitly created index, such as those created by defining a UNIQUE key constraint on a table, with the drop index command. If you try to do so it will throw an error.

SQL> DROP INDEX EMP_NAME_IDX ;
 DROP INDEX EMP_NAME_IDX *
ERROR AT LINE 1: ORA-02429: CANNOT DROP INDEX USED FOR ENFORCEMENT OF UNIQUE/PRIMARY KEY


If you want to drop such an index you have to first drop the constraint defined on the table. In order to drop a constraint, issue the drop constraint command, as shown here:

SQL> ALTER TABLE EMP DROP CONSTRAINT emp_name_PK1;
TABLE ALTERED.
SQL>


You can query the ALL_CONSTRAINTS performance view to understand which constraint the index is used by,


SELECT OWNER, CONSTRAINT_NAME, CONSTRAINT_TYPE,
 TABLE_NAME, INDEX_OWNER, INDEX_NAME
FROM ALL_CONSTRAINTS
WHERE INDEX_NAME = 'EMP_NAME_IDX';





If you like this post, please share it on google by clicking on the Google +1 button.

Please go through similar Oracle Posts @DWHLAUREATE:



Saturday, 1 October 2016

Oracle Indexes Performance and Creation Guidelines

These guidelines will help you create and manage indexes and help improving the performance by correct usage of indexes.

DON’T ADD INDEXES WORTHLESSLY:
Addition of indexes increases performance but also ingest disk space.Based on the performance improvement add as many indexes as required sensibly.

MARK INDEXES AS UNUSABLE OR INVISIBLE RATHER THAN DROPPING
Before dropping an index think over marking the indexes as unusable and invisible. This give us an extra option to check for any performance issues before dropping the index. If there are any performance issues we can revert back by rebuilding or re-enable the index without requiring the data definition language (DDL) creation statement.

You can read more about Invisible Indexes here:

It’s better to drop the indexes that are not used by any database objects as it would free up the physical space and improve the performance.

INDEXING METHODOLOGY:
Indexing the columns that are used in queries executed against a table will help improve the performance.

CREATE PRIMARY /UNIQUE CONSTARINTS:
Build primary constraints on all tables and unique constraints wherever applicable. This will automatically create a B-tree index if the columns are not already indexed.

USING SEPARATE TABLESPACE FOR INDEXES
Using distinct table space helps in managing indexes separately from tables. Table and index data may have different storage and/or backup and recovery requirements.

USE BITMAP INDEXES IN DATAWAREHOUSE ENVIRONMENT
Bitmap indexes are used for complex queries in a data warehouse environment to prevent spending long time to access and retrieve answers for the queries. B-Tree index technique is used for high cardinality column and Bitmap Indexes have predominantly been used for low cardinality columns.

Bitmap indexes achieve important functions in answering data warehouse’s queries because they have capability to perform operations at the index level before fetching data

To learn more about Bitmap & B-tree indexes check our previous post


USE APPROPRIATE NAMING STANDARDS
Correct naming standards would help in the maintenance and troubleshooting easier.



If you like this post, please share it on google by clicking on the Google +1 button.

Please go through similar Oracle Posts @DWHLAUREATE:




Tuesday, 14 August 2012

What is a PARTITION in Oracle?Why to use Partition And Types of Partitions

PARTITIONS

Partitioning allows tables, indexes, and index-organized tables to be subdivided into smaller pieces, enabling these database objects to be managed and accessed at a finer level of granularity.


When to Partition a Table??
  • Tables greater than 2 GB should always be considered as candidates for partitioning.
  • Tables containing historical data, in which new data is added into the newest partition. A typical example is a historical table where only the current month's data is updatable and the other 11 months are read only.
  • When the contents of a table need to be distributed across different types of storage devices.
TYPES

1     Range partitions
2     List partitions
3     Hash partitions
4     Sub partitions
  
ADVANTAGES OF PARTITIONS
  • Reducing downtime for scheduled maintenance, which allows maintenance operations to be carried out on selected partitions while other partitions are available to users.
  • Reducing downtime due to data failure, failure of a particular partition will no way affect other partitions.
  • Partition independence allows for concurrent use of the various partitions for various purposes.
 What is the advantage of partitions, by storing them in different Tablespaces??

1     Reduces the possibility of data corruption in multiple partitions.
2     Back up and recovery of each partition can be done independently.
 
Partitioning Key
Each row in a partitioned table is unambiguously assigned to a single partition. The partitioning key is comprised of one or more columns that determine the partition where each row will be stored


1.RANGE PARTITIONS

Definition: A table that is partitioned by range is partitioned in such a way that each partition contains rows for which the partitioning expression value lies within a given range.
 Creating range partitioned table
 SQL> Create table Employee(emp_no number(2),emp_name varchar(2)) partition by range(emp_no) (partition p1 values less than(100), partition p2 values less than(200), partition p3 values less than(300),partition p4 values less than(maxvalue)); 
Inserting records into range partitioned table
     SQL> Insert into Employee values(101,’a’);      -- this will go to p1
     SQL> Insert into Employee values(201,’b’);     -- this will go to p2
     SQL> Insert into Employee values(301,’c’);      -- this will go to p3
     SQL> Insert into Employee values(401,’d’);     -- this will go to p4
 Selecting records from range partitioned table
     SQL> Select *from Employee;
     SQL> Select *from Employee partition(p1);
 Adding a partition
     SQL> Alter table Employee add partition p5 values less than(400);
 Dropping a partition
    SQL> Alter table Employee drop partition p1;
 Renaming a partition
     SQL> Alter table Employee rename partition p3 to p6;
 Truncate a partition
     SQL> Alter table Employee truncate partition p5;
 Splitting a partition
    SQL> Alter table Employee split partition p2 at(120) into (partition p21,partition p22);
 Exchanging a partition
  SQL> Alter table Employee exchange partition p2 with table Employee_x;
 Moving a partition
     SQL> Alter table Employee move partition p21 tablespace ABC_TBS;


 2. LIST PARTITIONS

Definition: List partitioning enables you to explicitly control how rows map to partitions by specifying a list of discrete values for the partitioning key in the description for each partition.
 Creating list partitioned table
SQL> Create table Employee (Emp_no number(2),Emp_name varchar(2)) partition by list(Emp_no)  (partition p1 values(1,2,3,4,5), partition p2 values(6,7,8,9,10),partition p3             values(11,12,13,14,15), partition p4 values(16,17,18,19,20));
 Inserting records into list partitioned table
      SQL> Insert into Employee values(4,’xxx’);     -- this will go to p1
      SQL> Insert into Employee values(8,’yyy’);     -- this will go to p2
      SQL> Insert into Employee values(14,’zzz’);    -- this will go to p3
      SQL> Insert into Employee values(19,’bbb’);  -- this will go to p4
 Selecting records from list partitioned table
     SQL> Select *from Employee;
     SQL> Select *from Employee partition(p1);
 Adding a partition
     SQL> Alter table Employee add partition p5 values(21,22,23,24,25);
 Dropping a partition
     SQL> Alter table Employee drop partition p5;
 Renaming a partition
     SQL> Alter table Employee rename partition p5to p1;
 Truncate a partition
     SQL> Alter table Employee truncate partition p5;
 Exchanging a partition
    SQL> Alter table Employee exchange partition p1 with table Employee_x;
 Moving a partition
    SQL> Alter table Employee move partition p2 tablespace ABC_TBS;


3. HASH PARTITIONS

Definition:Hash partitioning maps data to partitions based on a hashing algorithm that Oracle applies to the partitioning key that you identify.
Creating hash partitioned table
     SQL> Create table Employee(emp_no number(2),emp_name varchar(2)) partition by      hash(emp_no) partitions 5;
     Here oracle automatically gives partition names like
                                                SYS_P1
                                                SYS_P2
                                                SYS_P3
                                                SYS_P4
                                                SYS_P5

 Inserting records into hash partitioned table(based on hash function)
     SQL> Insert into Employee values(5,’a’);      
     SQL> Insert into Employee values(8,’b’);      
     SQL> Insert into Employee values(14,’c’);    
     SQL> Insert into Employee values(19,’d’);   
 Selecting records from hash partitioned table
     SQL> Select *from Employee;
     SQL> Select *from Employee partition(SYS_P2);
 Adding a partition
     SQL> Alter table Employee add partition p9;
 Renaming a partition
    SQL> Alter table Employee rename partition p9 to p10;
 Truncate a partition
     SQL> Alter table Employee truncate partition p9;
 Exchanging a partition
 SQL> Alter table Employee exchange partition SYS_P1 with table Employee_X;
 Moving a partition
     SQL> Alter table Employee move partition SYS_P1 tablespace ABC_TBS;

What are Global and Local Indexes?

LOCAL INDEXES
Local partitioned indexes are easier to manage than other types of partitioned indexes. They also offer greater availability and are common in DSS environments.
In the local prefixed index the partition key is specified on the left prefix. Local keyword tells oracle to create a separte index for each partition.Local prefixed indexes can be unique or non unique and is easier to manage
Ex:CREATE INDEX invoices_idx ON invoices (invoice_date)
LOCAL (PARTITION invoices_q1 TABLESPACE users,  
PARTITION invoices_q2 TABLESPACE users);

GLOBAL INDEXES
A global Index in a single partition may correspond to multiple table partitions. They are created with the GLOBAL keyword and this the global clause allows you to create a non-partitioned index.
Global indexes may perform uniqueness checks faster than local (partitioned) indexes.Also you cannot create global indexes for hash partitions or subpartitions.
Ex:
SQL> CREATE INDEX invoices_idx
ON COST_TABLE(invoice_date) 
GLOBAL PARTITION BY RANGE (invoice_date)
(PARTITION invoices01 VALUES LESS THAN 
(TO_DATE('01/04/2001', 'DD/MM/YYYY')) TABLESPACE users,
PARTITION invoices02 VALUES LESS THAN 
(TO_DATE('01/07/2001', 'DD/MM/YYYY')) TABLESPACE users);

Similar to table partitions, it is possible to move them from one device to another. But unlike table partitions, movement of index partitions requires individual reconstruction of the index or each partition (only in the case of global index).
Ex:
SQL> alter index stud_ind rebuild partition p2
Index partitions cannot be dropped manually.They are dropped implicitly when the data they refer to is dropped from the partitioned table.
Related Posts Plugin for WordPress, Blogger...

ShareThis