Each time you add a new row, MySQL increments the value automatically and persist it to table. But sometime you may want to reset the Autoincrement column value to 1. Say you writing a sample application and you have inserted few rows already in the table. Now you want to delete these rows and reset the autoincrement column to 1 so that new row which you insert will have primary key value 1.

There are few methods to achieve this.

1. Directly Reset Autoincrement Value

Alter table syntax provides a way to reset autoincrement column. Take a look at following example.

ALTER TABLE table_name AUTO_INCREMENT = 1;

Note that you cannot reset the counter to a value less than or equal to any that have already been used. For MyISAM, if the value is less than or equal to the maximum value currently in the AUTO_INCREMENT column, the value is reset to the current maximum plus one. For InnoDB, if the value is less than the current maximum value in the column, no error occurs and the current sequence value is not changed.

2. Truncate Table

Truncate table automatically reset the Autoincrement values to 0.

TRUNCATE TABLE table_name;

Use this with caution. When Truncation is used, it resets any AUTO_INCREMENT counter to zero. From MySQL 5.0.13 on, the AUTO_INCREMENT counter is reset to zero by TRUNCATE TABLE, regardless of whether there is a foreign key constraint.

Once TRUNCATE is fired, the table handler does not remember the last used AUTO_INCREMENT value, but starts counting from the beginning. This is true even for MyISAM and InnoDB, which normally do not reuse sequence values.

3. Drop & Recreate Table

This is another way of reseting autoincrement index. Although not very desirable.

DROP TABLE table_name;
CREATE TABLE table_name { ... };

All these techniques are value techniques to reset autoincrement column number. Use whatever suits your requirement.

Disclaimer: The above commands can delete all your data! Be very very cautious.

Tools and technologies used in this article:

1. Java JDK 1.5 above
2. MySQL 5 above
3. Eclipse 3.2 above
4. Hibernate 3 above
5. Maven 3 above

1. Create Database

We will use MySQL in our example. Create two tables “employee” and “employeedetail” with One-to-one relationship. Following is the SQL script for same.

/* EMPLOYEE table */
CREATE TABLE `employee` (
	`employee_id` BIGINT(10) NOT NULL AUTO_INCREMENT,
	`firstname` VARCHAR(50) NULL DEFAULT NULL,
	`lastname` VARCHAR(50) NULL DEFAULT NULL,
	`birth_date` DATE NOT NULL,
	`cell_phone` VARCHAR(15) NOT NULL,
	PRIMARY KEY (`employee_id`)
)
COLLATE='latin1_swedish_ci'
ENGINE=InnoDB
ROW_FORMAT=DEFAULT
AUTO_INCREMENT=216

/* EMPLOYEEDETAIL table */
CREATE TABLE `employeedetail` (
	`employee_id` BIGINT(20) NOT NULL AUTO_INCREMENT,
	`street` VARCHAR(50) NULL DEFAULT NULL,
	`city` VARCHAR(50) NULL DEFAULT NULL,
	`state` VARCHAR(50) NULL DEFAULT NULL,
	`country` VARCHAR(50) NULL DEFAULT NULL,
	PRIMARY KEY (`employee_id`),
	CONSTRAINT `FKEMPL` FOREIGN KEY (`employee_id`) REFERENCES `employee` (`employee_id`)
)
COLLATE='latin1_swedish_ci'
ENGINE=InnoDB
ROW_FORMAT=DEFAULT
AUTO_INCREMENT=216

Note that a one-to-one relationships occurs when one entity is related to exactly one occurrence in another entity. Thus, there will be one primary key which will be mapped with both the entities.

2. Hibernate Maven dependency

Following dependencies we will use in Maven which will add Hibernate support.

File: /pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>net.viralpatel.hibernate</groupId>
	<artifactId>HibernateHelloWorldXML</artifactId>
	<packaging>jar</packaging>
	<version>1.0-SNAPSHOT</version>
	<name>HibernateHelloWorldXML</name>
	<url>http://maven.apache.org</url>
	<dependencies>
		<dependency>
			<groupId>mysql</groupId>
			<artifactId>mysql-connector-java</artifactId>
			<version>5.1.10</version>
		</dependency>
		<dependency>
			<groupId>org.hibernate</groupId>
			<artifactId>hibernate</artifactId>
			<version>3.2.6.ga</version>
		</dependency>
	</dependencies>
</project>

3. Hibernate Model class

For this example we will create two Model class: Employee.java and EmployeeDetail.java. Add following in your project.

File: /src/main/java/net/viralpatel/hibernate/Employee.java

package net.viralpatel.hibernate;

import java.sql.Date;

public class Employee {

	private Long employeeId;
	private String firstname;
	private String lastname;
	private Date birthDate;
	private String cellphone;
	private EmployeeDetail employeeDetail;

	public Employee() {

	}

	public Employee(String firstname, String lastname, Date birthdate,
			String phone) {
		this.firstname = firstname;
		this.lastname = lastname;
		this.birthDate = birthdate;
		this.cellphone = phone;
	}

	// Getter and Setter methods
}

File: /src/main/java/net/viralpatel/hibernate/EmployeeDetail.java

package net.viralpatel.hibernate;

public class EmployeeDetail {

	private Long employeeId;
	private String street;
	private String city;
	private String state;
	private String country;

	private Employee employee;

	public EmployeeDetail() {

	}

	public EmployeeDetail(String street, String city, String state, String country) {
		this.street = street;
		this.city = city;
		this.state = state;
		this.country = country;
	}

	// Getter and Setter methods	

}

Note that in above model classes, employeeId is common. This is the primary key of Employee table that exhibits One-to-one relationship with EmployeeDetail table.

4. Hibernate XML Mapping (HBM)

Add following hibernate mapping (hbm) files Employee.hbm.xml and EmployeeDetail.hbm.xml for the model classes created in above steps.

File: /src/main/java/net/viralpatel/hibernate/Employee.hbm.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-mapping PUBLIC
        "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
        "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping package="net.viralpatel.hibernate">

	<class name="Employee" table="EMPLOYEE">
		<id name="employeeId" column="EMPLOYEE_ID">
			<generator class="native" />
		</id>
		<one-to-one name="employeeDetail" class="net.viralpatel.hibernate.EmployeeDetail"
			cascade="save-update"></one-to-one>

		<property name="firstname" />
		<property name="lastname" column="lastname" />
		<property name="birthDate" type="date" column="birth_date" />
		<property name="cellphone" column="cell_phone" />

	</class>
</hibernate-mapping>

File: /src/main/java/net/viralpatel/hibernate/EmployeeDetail.hbm.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-mapping PUBLIC
        "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
        "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping package="net.viralpatel.hibernate">

    <class name="EmployeeDetail" table="EMPLOYEEDETAIL">

 		<id name="employeeId" type="java.lang.Long">
			<column name="EMPLOYEE_ID" />
			<generator class="foreign">
				<param name="property">employee</param>
			</generator>
		</id>
		<one-to-one name="employee" class="net.viralpatel.hibernate.Employee"
			constrained="true"></one-to-one>

        <property name="street" column="STREET"/>
        <property name="city" column="CITY"/>
        <property name="state" column="STATE"/>
        <property name="country" column="COUNTRY"/>
	</class>

</hibernate-mapping>

Note that in above hibernate mapping we are implementing One-to-one relationship. For both the model classes we are using a single primary key EmployeeId. In EmployeeDetail hbm file we have defined a foreign identifier generator so that primary it uses primary key of Employee table.

5. Hibernate Configuration

Following is the hibernate configuration hibernate.cfg.xml file. Add this in your project.

File: /src/main/resources/hibernate.cfg.xml

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE hibernate-configuration PUBLIC
        "-//Hibernate/Hibernate Configuration DTD 3.0//EN"
        "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">

<hibernate-configuration>
    <session-factory>
        <property name="connection.driver_class">com.mysql.jdbc.Driver</property>
        <property name="connection.url">jdbc:mysql://localhost:3306/tutorial</property>
        <property name="connection.username">root</property>
        <property name="connection.password"></property>

        <property name="connection.pool_size">1</property>
        <property name="dialect">org.hibernate.dialect.MySQLDialect</property>
        <property name="current_session_context_class">thread</property>
        <property name="cache.provider_class">org.hibernate.cache.NoCacheProvider</property>
        <property name="show_sql">true</property>
        <property name="hbm2ddl.auto">validate</property>

        <mapping resource="net/viralpatel/hibernate/EmployeeDetail.hbm.xml"/>
        <mapping resource="net/viralpatel/hibernate/Employee.hbm.xml"/>

    </session-factory>
</hibernate-configuration>

6. Hibernate Utility class

File:/src/main/java/net/viralpatel/hibernate/HibernateUtil.java

package net.viralpatel.hibernate;

import org.hibernate.SessionFactory;
import org.hibernate.cfg.Configuration;

public class HibernateUtil {

    private static final SessionFactory sessionFactory = buildSessionFactory();

    private static SessionFactory buildSessionFactory() {
        try {
            // Create the SessionFactory from hibernate.cfg.xml
            return new Configuration()
            		.configure()
                    .buildSessionFactory();
        } catch (Throwable ex) {
            System.err.println("Initial SessionFactory creation failed." + ex);
            throw new ExceptionInInitializerError(ex);
        }
    }

    public static SessionFactory getSessionFactory() {
        return sessionFactory;
    }
}

7. Main class to test One-to-one mapping

Add following Main.java class in your project to test One-to-one relationship mapping functionality.

File:/src/main/java/net/viralpatel/hibernate/Main.java

package net.viralpatel.hibernate;

import java.sql.Date;
import java.util.List;

import org.hibernate.Session;
import org.hibernate.SessionFactory;

public class Main {

	public static void main(String[] args) {

		SessionFactory sf = HibernateUtil.getSessionFactory();
		Session session = sf.openSession();
		session.beginTransaction();

		EmployeeDetail employeeDetail = new EmployeeDetail("10th Street", "LA", "San Francisco", "U.S.");

		Employee employee = new Employee("Nina", "Mayers", new Date(121212),
				"114-857-965");
		employee.setEmployeeDetail(employeeDetail);
		employeeDetail.setEmployee(employee);

		session.save(employee);

		List<Employee> employees = session.createQuery("from Employee").list();
		for (Employee employee1 : employees) {
			System.out.println(employee1.getFirstname() + " , "
					+ employee1.getLastname() + ", "
					+ employee1.getEmployeeDetail().getState());
		}

		session.getTransaction().commit();
		session.close();

	}
}

8. Review Project Structure

Below is the final project structure with all the source files.

8. Execute the example

Execute the Main class. Hibernate will insert a row in Employee and EmployeeDetail table.

Output:

Hibernate: insert into EMPLOYEE (firstname, lastname, birth_date, cell_phone) values (?, ?, ?, ?)
Hibernate: insert into EMPLOYEEDETAIL (STREET, CITY, STATE, COUNTRY, EMPLOYEE_ID) values (?, ?, ?, ?, ?)
Hibernate: select employee0_.EMPLOYEE_ID as EMPLOYEE1_1_, employee0_.firstname as firstname1_, employee0_.lastname as lastname1_, employee0_.birth_date as birth4_1_, employee0_.cell_phone as cell5_1_ from EMPLOYEE employee0_
Hibernate: select employeede0_.EMPLOYEE_ID as EMPLOYEE1_0_0_, employeede0_.STREET as STREET0_0_, employeede0_.CITY as CITY0_0_, employeede0_.STATE as STATE0_0_, employeede0_.COUNTRY as COUNTRY0_0_ from EMPLOYEEDETAIL employeede0_ where employeede0_.EMPLOYEE_ID=?
Nina , Mayers, San Francisco

That’s All Folks

Today we saw how to write Hibernate program and implements One-to-one relationship mapping using XML mappings. We used Maven to generate Java project and added Hibernate dependencies into it.

Download Source

Hibernate-One-to-one-tutorial-XML-Mapping.zip (9 kb)

Following are the tools and technologies used in this project.

1. Java JDK 5 or above
2. Eclipse IDE 3.2 or above
3. Maven 3.0 or above
4. Hibernate 3.0 or above
5. MySQL 5.0 or above

1. Database Creation

For this tutorial, we will create a simple table “employe” in MySQL. Use following script to create the table.

CREATE TABLE `employee` (
	`id` BIGINT(10) NOT NULL AUTO_INCREMENT,
	`firstname` VARCHAR(50) NULL DEFAULT NULL,
	`lastname` VARCHAR(50) NULL DEFAULT NULL,
	`birth_date` DATE NOT NULL,
	`cell_phone` VARCHAR(15) NOT NULL,
	PRIMARY KEY (`id`)
)
COLLATE='latin1_swedish_ci'
ENGINE=InnoDB
ROW_FORMAT=DEFAULT
AUTO_INCREMENT=606

Thus, following will be the connection string to connect with MySQL.

Connection URL:	jdbc:mysql://localhost:3306/tutorial
DB Username:	root
DB Password:	

2. Generate Maven Java project compatible with Eclipse

Open a command prompt and execute following code to generate a Maven Java project.

mvn archetype:generate \
	-DgroupId=net.viralpatel.hibernate \
	-DartifactId=HibernateHelloWorldXML \
	-DarchetypeArtifactId=maven-archetype-quickstart \
	-DinteractiveMode=false

Once you execute above command, a project “HibernateHelloWorldXML” is created. Note that this is a Java project which already has folder structures compatible to Maven.

Once this is done, we will convert it to be compatible with Eclipse. For that executes following command on command prompt.

mvn eclipse:eclipse

3. Import project in Eclipse

Open Eclipse and import the above Java project.

File > Import... > General > Existing Projects into Workspace > Choose above Java project

Once imported, the folder structure will look like following:

Important:

In case you get following error after importing project in Eclipse:

If you are getting this Hibernate Maven Repo error, then you need to define M2_REPO environment variable in eclipse pointing to your local maven repository.

Goto Window > Preferences… > Java > Build Path > Classpath Variables > Define new variable M2_REPO pointing to your local maven repository.

Once you will define this variable and rebuild the project, the above error will go.

4. Add Hibernate Dependency to Maven pom.xml

Add following dependencies to Maven pom.xml.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>net.viralpatel.hibernate</groupId>
  <artifactId>HibernateHelloWorldXML</artifactId>
  <packaging>jar</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>HibernateHelloWorldXML</name>
  <url>http://maven.apache.org</url>
  <dependencies>
    <dependency>
      <groupId>mysql</groupId>
      <artifactId>mysql-connector-java</artifactId>
      <version>5.1.10</version>
    </dependency>
    <dependency>
      <groupId>org.hibernate</groupId>
      <artifactId>hibernate</artifactId>
      <version>3.2.6.ga</version>
    </dependency>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

Once we have added these dependencies, we will execute following command so that maven will download required Jar files and add the same to eclipse classpath.

mvn eclipse:eclipse

The above step is not mandatory. If you have Maven plugin for Eclipse installed in your IDE (Latest eclipse comes with this plugin built-in) you can just enable Maven dependencies by doing
Right click on project > Maven > Enable Dependency Management.

5. Add Hibernate Configuration XML

Now our project setup is ready. We will add following Hibernate configuration xml file in /src/main/resources folder. Note that this folder is not present in your project structure.

Create a source folder:
Right click on Project > New > Source Folder > Give folder name “/src/main/resources/” and click Finish.

Copy following file in your project.

File: /src/main/resources/hibernate.cfg.xml

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE hibernate-configuration PUBLIC
        "-//Hibernate/Hibernate Configuration DTD 3.0//EN"
        "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">

<hibernate-configuration>
    <session-factory>
        <!-- Database connection settings -->
        <property name="connection.driver_class">com.mysql.jdbc.Driver</property>
        <property name="connection.url">jdbc:mysql://localhost:3306/tutorial</property>
        <property name="connection.username">root</property>
        <property name="connection.password"></property>

        <!-- JDBC connection pool (use the built-in) -->
        <property name="connection.pool_size">1</property>

        <!-- SQL dialect -->
        <property name="dialect">org.hibernate.dialect.MySQLDialect</property>

        <!-- Enable Hibernate's automatic session context management -->
        <property name="current_session_context_class">thread</property>

        <!-- Disable the second-level cache  -->
        <property name="cache.provider_class">org.hibernate.cache.NoCacheProvider</property>

        <!-- Echo all executed SQL to stdout -->
        <property name="show_sql">false</property>

        <property name="hbm2ddl.auto">validate</property>

        <mapping resource="net/viralpatel/hibernate/Employee.hbm.xml"/>

    </session-factory>
</hibernate-configuration>

One thing we need to make sure in Eclipse is that the Java build path must reflect **/*.xml.
Right click on project > Properties > Java Build Path > Source > Add **/*.xml as follow:

6. Add Java source code

File: /src/main/java/net/viralpatel/hibernate/Employee.java

package net.viralpatel.hibernate;

import java.sql.Date;

public class Employee {

	private Long id;

	private String firstname;

	private String lastname;

	private Date birthDate;

	private String cellphone;

	public Employee() {

	}

	public Employee(String firstname, String lastname, Date birthdate, String phone) {
		this.firstname = firstname;
		this.lastname = lastname;
		this.birthDate = birthdate;
		this.cellphone = phone;

	}

	// Getter and Setter methods

}

Above is the Employee POJO class that we will use to fetch data from Employee table. This Java class will be mapped by Hiberate with Employee table. Note that we have define two constructors first default and second with arguements. The second constructor is optional. But note that you must define a default (No-arguement) constructor in your mapping class.

File: /src/main/java/net/viralpatel/hibernate/HibernateUtil.java

package net.viralpatel.hibernate;

import org.hibernate.SessionFactory;
import org.hibernate.cfg.Configuration;

public class HibernateUtil {

    private static final SessionFactory sessionFactory = buildSessionFactory();

    private static SessionFactory buildSessionFactory() {
        try {
            // Create the SessionFactory from hibernate.cfg.xml
            return new Configuration()
            		.configure()
                    .buildSessionFactory();
        } catch (Throwable ex) {
            System.err.println("Initial SessionFactory creation failed." + ex);
            throw new ExceptionInInitializerError(ex);
        }
    }

    public static SessionFactory getSessionFactory() {
        return sessionFactory;
    }
}

As discussed in previous article Introduction to Hibernate framework, we have to create SessionFactory instance in order to communicate with Database in Hibernate. We will use a Utility class called HibernateUtil to instantiate SessionFactory.

File: /src/main/java/net/viralpatel/hibernate/Employee.hbm.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-mapping PUBLIC
        "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
        "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping package="net.viralpatel.hibernate">

    <class name="Employee" table="EMPLOYEE">
 		<id name="id" column="ID">
            <generator class="native"/>
        </id>
        <property name="firstname" />
        <property name="lastname" column="lastname"/>
        <property name="birthDate" type="date" column="birth_date"/>
        <property name="cellphone" column="cell_phone"/>
	</class>

</hibernate-mapping>

7. CRUD operations in Hibernate

Let us see the basic CRUD operation in Hibernate. We will use Employee table for this.

7.1 Writing (Create) data in Hibernate

Following is the code snippet that insert a row in database.

private static Employee save(Employee employee) {
	SessionFactory sf = HibernateUtil.getSessionFactory();
	Session session = sf.openSession();
	session.beginTransaction();

	Long id = (Long) session.save(employee);
	employee.setId(id);

	session.getTransaction().commit();

	session.close();

	return employee;
}

...
...
...

// Call the save() method to insert a record in database.
System.out.println("******* WRITE *******");
Employee empl = new Employee("Jack", "Bauer", new Date(System.currentTimeMillis()), "911");
empl = save(empl);

7.2 Reading (Read) data in Hibernate

Below code snippet demos read functionality in Hibernate. Note that there are two methods one to list all the employees and other to read details about just one.

private static List list() {
	SessionFactory sf = HibernateUtil.getSessionFactory();
	Session session = sf.openSession();

	List employees = session.createQuery("from Employee").list();
	session.close();
	return employees;
}
private static Employee read(Long id) {
	SessionFactory sf = HibernateUtil.getSessionFactory();
	Session session = sf.openSession();

	Employee employee = (Employee) session.get(Employee.class, id);
	session.close();
	return employee;
}

7.3 Updating (Update) data in Hibernate

Following is the code snippet to update a record in Hibernate.

private static Employee update(Employee employee) {
	SessionFactory sf = HibernateUtil.getSessionFactory();
	Session session = sf.openSession();

	session.beginTransaction();

	session.merge(employee);

	session.getTransaction().commit();

	session.close();
	return employee;

}

7.4 Remove (Delete) data in Hibernate

Following is code snippet to remove a record in Hibernate.

private static void delete(Employee employee) {
	SessionFactory sf = HibernateUtil.getSessionFactory();
	Session session = sf.openSession();

	session.beginTransaction();

	session.delete(employee);

	session.getTransaction().commit();

	session.close();
}

We have created a file Main.java which will test all these functionality. Following is the complete source code of Main.java.
File: /src/main/java/net/viralpatel/hibernate/Main.java

package net.viralpatel.hibernate;

import java.sql.Date;
import java.util.List;

import org.hibernate.Session;
import org.hibernate.SessionFactory;

public class Main {

	public static void main(String[] args) {

		// Read
		System.out.println("******* READ *******");
		List employees = list();
		System.out.println("Total Employees: " + employees.size());

		// Write
		System.out.println("******* WRITE *******");
		Employee empl = new Employee("Jack", "Bauer", new Date(System.currentTimeMillis()), "911");
		empl = save(empl);
		empl = read(empl.getId());
		System.out.printf("%d %s %s \n", empl.getId(), empl.getFirstname(), empl.getLastname());

		// Update
		System.out.println("******* UPDATE *******");
		Employee empl2 = read(1l); // read employee with id 1
		System.out.println("Name Before Update:" + empl2.getFirstname());
		empl2.setFirstname("James");
		update(empl2);	// save the updated employee details

		empl2 = read(1l); // read again employee with id 1
		System.out.println("Name Aftere Update:" + empl2.getFirstname());

		// Delete
		System.out.println("******* DELETE *******");
		delete(empl);
		Employee empl3 = read(empl.getId());
		System.out.println("Object:" + empl3);
	}

	private static List list() {
		SessionFactory sf = HibernateUtil.getSessionFactory();
		Session session = sf.openSession();

		List employees = session.createQuery("from Employee").list();
		session.close();
		return employees;
	}
	private static Employee read(Long id) {
		SessionFactory sf = HibernateUtil.getSessionFactory();
		Session session = sf.openSession();

		Employee employee = (Employee) session.get(Employee.class, id);
		session.close();
		return employee;
	}
	private static Employee save(Employee employee) {
		SessionFactory sf = HibernateUtil.getSessionFactory();
		Session session = sf.openSession();

		session.beginTransaction();

		Long id = (Long) session.save(employee);
		employee.setId(id);

		session.getTransaction().commit();

		session.close();

		return employee;
	}

	private static Employee update(Employee employee) {
		SessionFactory sf = HibernateUtil.getSessionFactory();
		Session session = sf.openSession();

		session.beginTransaction();

		session.merge(employee);

		session.getTransaction().commit();

		session.close();
		return employee;

	}

	private static void delete(Employee employee) {
		SessionFactory sf = HibernateUtil.getSessionFactory();
		Session session = sf.openSession();

		session.beginTransaction();

		session.delete(employee);

		session.getTransaction().commit();

		session.close();
	}

}

8. Final project structure

Once you have created all these source files, your project structure should look like following. Note that we have removed the default App.java and AppTest.java generated by Maven as we dont these files.

9. Execute project

Execute the Main.java class and see output.

******* READ *******
Total Employees: 200
******* WRITE *******
201 Jack Bauer
******* UPDATE *******
Name Before Update:Paula
Name Aftere Update:James
******* DELETE *******
Object:null

That’s All Folks

Today we saw how to write our first Hibernate hello world example using XML Configuration. We used Maven to generate Java project and added Hibernate dependencies into it. Also we saw how to do different CRUD operations in Hibernate.

Download Source

HibernateHelloWorldXML.zip (8 kb)

• They are defined by an expression. The result of evaluation of this expression becomes the value of the column.
• The values of the virtual column are not stored in the database. Rather, it’s computed at run-time when you query the data.
• You can’t update (in SET clause of update statement) the values of virtual column. These are read only values, that are computed dynamically and any attempt to modify them will result into oracle error.

The syntax for defining a virtual column is:

column_name [datatype] [GENERATED ALWAYS] AS [expression] [VIRTUAL]

where the parameters within [] are optional and can be omitted. If you don’t mention the datatype, Oracle will decide it based on the result of the expression.

Excepting the above points, a virtual column, exists just like any other column of a normal table and the following points apply to it:

1. Virtual columns can be used in the WHERE clause of UPDATE and DELETE statement but they can’t be modified by DML.
2. Statistics can be collected on them.
3. They can be used as a partition key in virtual column based partitioning.
4. Indexes can be created on them. As you might have guessed, oracle would create function based indexes as we create on normal tables.
5. Constraints can be created on them.

Create table with Virtual Column

For creating a virtual column, use the syntax mentioned above. Consider the following example:

CREATE TABLE EMPLOYEE
(
	empl_id        NUMBER,
	empl_nm        VARCHAR2(50),
	monthly_sal    NUMBER(10,2),
	bonus          NUMBER(10,2),
	total_sal      NUMBER(10,2) GENERATED ALWAYS AS (monthly_sal*12 + bonus)
);

Here we have defined a virtual column “total_sal” whose value would be dynamically calculated using the expression provided after the “generated always as” clause. Please note that this declaration is different than using “default” clause for a normal column as you can’t refer column names with “default” clause.

Lets check the data dictionary view:

SELECT column_name, data_type, data_length, data_default, virtual_column
  FROM user_tab_cols
 WHERE table_name = 'EMPLOYEE';

COLUMN_NAME | DATA_TYPE | DATA_LENGTH | DATA_DEFAULT             | VIRTUAL_COLUMN
EMPL_ID     | NUMBER    | 22          | null                     | NO
EMPL_NM     | VARCHAR2  | 50          | null                     | NO
MONTHLY_SAL | NUMBER    | 22          | null                     | NO
BONUS       | NUMBER    | 22          | null                     | NO
TOTAL_SAL   | NUMBER    | 22          | "MONTHLY_SAL"*12+"BONUS" | YES

The value “YES” for the column “virtual_column” tells us that this is a virtual column. Another optional keyword “VIRTUAL” can also be added to make it syntactically complete.

DROP TABLE EMPLOYEE PURGE;

CREATE OR REPLACE FUNCTION get_empl_total_sal ( p_monthly_sal   NUMBER,
                                                p_bonus         NUMBER)
   RETURN NUMBER
DETERMINISTIC
IS
BEGIN
   RETURN p_monthly_sal * 12 + p_bonus;
END;

CREATE TABLE EMPLOYEE
(empl_id     NUMBER,
 empl_nm     VARCHAR2(50),
 monthly_sal NUMBER(10,2),
 bonus       NUMBER(10,2),
 total_sal   NUMBER(10,2) AS (get_empl_total_sal(monthly_sal, bonus)) VIRTUAL
);

We have included the “VIRTUAL” clause in the table definition. Please note that instead of using an expression, I have used a deterministic function. A deterministic function, when passed certain inputs, will always return the exact same output. “DETERMINISTIC” keyword is needed in order to mark a function as a candidate to be used in a function based index.

You can also create indexes on the virtual columns. Here is an example:

CREATE INDEX idx_total_sal ON employee(total_sal);

SELECT index_name, index_type
  FROM user_indexes
 WHERE table_name = 'EMPLOYEE';

INDEX_NAME     INDEX_TYPE
IDX_TOTAL_SAL  FUNCTION-BASED NORMAL

Note that even this function is used as part of table definition, you can still drop it. But this in turn will make the table inaccessible.

DROP FUNCTION get_empl_total_sal;

SELECT * FROM employee;
*
Error at line 0
ORA-00904: "schema"."GET_EMPL_TOTAL_SAL": invalid identifier

You can alter the table with virtual column as you would modify a table with normal columns. Lets add the same column using the ALTER command:

DROP TABLE EMPLOYEE PURGE;

CREATE TABLE EMPLOYEE
(empl_id     NUMBER,
 empl_nm     VARCHAR2(50),
 monthly_sal NUMBER(10,2),
 bonus       NUMBER(10,2)
);

ALTER TABLE EMPLOYEE ADD (total_sal AS (monthly_sal * 12 + bonus));

Note that the datatype of the new column is not declared. It will be assigned a datatype based on the result of the expression (in this case, it would be NUMBER). Now let’s insert some data in the table:

INSERT INTO employee (empl_id, empl_nm, monthly_sal, bonus)
   WITH DATA AS
        (SELECT 100 empl_id, 'AAA' empl_nm, 20000 monthly_sal, 3000 bonus
           FROM DUAL
         UNION
         SELECT 200, 'BBB', 12000, 2000
           FROM DUAL
         UNION
         SELECT 300, 'CCC', 32100, 1000
           FROM DUAL
         UNION
         SELECT 400, 'DDD', 24300, 5000
           FROM DUAL
         UNION
         SELECT 500, 'EEE', 12300, 8000
           FROM DUAL)
   SELECT *
     FROM DATA;

SELECT * FROM employee;

EMPL_ID | EMPL_NM | MONTHLY_SAL | BONUS | TOTAL_SAL
100     | AAA     | 20000       | 3000  | 243000
200     | BBB     | 12000       | 2000  | 146000
300     | CCC     | 32100       | 1000  | 386200
400     | DDD     | 24300       | 5000  | 296600
500     | EEE     | 12300       | 8000  | 155600

Here we have populated the table columns except the virtual column with some values. Upon selecting the data, we get the value for “total_sal”. Remember that this data is not actually stored in the database but evaluated dynamically. Lets try updating this value of this virtual column:

UPDATE employee
   SET total_sal = 2000;

ORA-54017: UPDATE operation disallowed on virtual columns

As mentioned before, the statistics can also be gathered for the virtual columns.

EXEC DBMS_STATS.GATHER_TABLE_STATS(user, 'EMPLOYEE');

SELECT column_name, num_distinct,
       display_raw (low_value, data_type)  low_value,
       display_raw (high_value, data_type) high_value
  FROM dba_tab_cols
 WHERE table_name = 'EMPLOYEE';

COLUMN_NAME | NUM_DISTINCT | LOW_VALUE | HIGH_VALUE
TOTAL_SAL   | 5            | 146000    | 386200
BONUS       | 5            | 1000      | 8000
MONTHLY_SAL | 5            | 12000     | 32100
EMPL_NM     | 5            | AAA       | EEE
EMPL_ID     | 5            | 100       | 500

Limitations on Virtual Columns

**The query above uses a wonderful function “display_raw” by “Greg Rahn” to display the high/low values. Please check the references at the last to see it’s definition.

1. A virtual column can only be of scalar datatype or XMLDATATYE. It can’t be a user defined type, LOB or RAW.
2. All columns mentioned as part of the virtual column expression should belong to the same table.
3. No DMLs are allowed on the virtual columns.
4. The virtual column expression can’t reference any other virtual column.
5. Virtual columns can only be created on ordinary tables. They can’t be created on index-organized, external, object, cluster or temporary tables.
6. If a deterministic function is used as virtual column expression, that virtual column can’t be used as a partitioning key for virtual column-based partitioning.

Virtual Column-Based Partitioning

Prior releases of Oracle only allowed a table to be partitioned based on a physical column. Oracle 11g, with the addition of virtual columns, now allows a partition key based on an expression, using one or more existing columns of the table. A virtual column can now be used as a partitioning key. Lets partition our table based on the virtual column “total_sal”:

DROP TABLE EMPLOYEE PURGE;

CREATE TABLE employee
(empl_id     NUMBER,
 empl_nm     VARCHAR2(50),
 monthly_sal NUMBER(10,2),
 bonus       NUMBER(10,2),
 total_sal   NUMBER(10,2) AS (monthly_sal*12 + bonus)
)
PARTITION BY RANGE (total_sal)
    (PARTITION sal_200000 VALUES LESS THAN (200000),
     PARTITION sal_400000 VALUES LESS THAN (400000),
     PARTITION sal_600000 VALUES LESS THAN (600000),
     PARTITION sal_800000 VALUES LESS THAN (800000),
     PARTITION sal_default VALUES LESS THAN (MAXVALUE));

INSERT INTO employee (empl_id, empl_nm, monthly_sal, bonus)
   WITH DATA AS
        (SELECT 100 empl_id, 'AAA' empl_nm, 20000 monthly_sal, 3000 bonus
           FROM DUAL
         UNION
         SELECT 200, 'BBB', 12000, 2000
           FROM DUAL
         UNION
         SELECT 300, 'CCC', 32100, 1000
           FROM DUAL
         UNION
         SELECT 400, 'DDD', 24300, 5000
           FROM DUAL
         UNION
         SELECT 500, 'EEE', 12300, 8000
           FROM DUAL)
   SELECT *
     FROM DATA;

EXEC DBMS_STATS.GATHER_TABLE_STATS(user,'EMPLOYEE',granularity => 'PARTITION');

SELECT   table_name, partition_name, num_rows
    FROM user_tab_partitions
   WHERE table_name = 'EMPLOYEE'
ORDER BY partition_name;

TABLE_NAME | PARTITION_NAME | NUM_ROWS
EMPLOYEE   | SAL_200000     | 2
EMPLOYEE   | SAL_400000     | 3
EMPLOYEE   | SAL_600000     | 0
EMPLOYEE   | SAL_800000     | 0
EMPLOYEE   | SAL_DEFAULT    | 0

So far, everything looks fine, lets now try to update monthly salary of one employee and in turn the value of total_sal.

UPDATE employee
   SET monthly_sal = 30000
 WHERE empl_id = 500;

ORA-14402: updating partition key column would cause a partition change

What happened? The reason is simple, updating the “monthly_sal” would result into change in “total_sal” of the employee and thus a partition change is required. This can be handled by enabling the row movement in the current definition of the table.

ALTER TABLE employee ENABLE ROW MOVEMENT;

UPDATE employee
   SET monthly_sal = 80000
 WHERE empl_id = 500;

1 row updated.

The update works fine. As mentioned before, a deterministic function can’t be used as virtual column expression which is to be used as a partitioning key. It has to be an expression defined on the columns of the table as done in the previous example. The following syntax will result in oracle error:

CREATE TABLE employee_new
(empl_id     NUMBER,
 empl_nm     VARCHAR2(50),
 monthly_sal NUMBER(10,2),
 bonus       NUMBER(10,2),
 total_sal   NUMBER(10,2) AS (get_empl_total_sal(monthly_sal, bonus))
)
PARTITION BY RANGE (total_sal)
    (PARTITION sal_200000 VALUES LESS THAN (200000),
     PARTITION sal_400000 VALUES LESS THAN (400000),
     PARTITION sal_600000 VALUES LESS THAN (600000),
     PARTITION sal_800000 VALUES LESS THAN (800000),
     PARTITION sal_default VALUES LESS THAN (MAXVALUE));

ORA-54021: Cannot use PL/SQL expressions in partitioning or subpartitioning columns

References:

Greg Rahn’s display_raw function
Oracle Documentation

So, How do we do the multiplication then? I tried it but just couldn’t do it in SQL. So, I asked this question on our internal self help channel and I got a pretty impressive reply:

“Using a mathematical approach…”

After understanding the solution, I was surprisingly happy with the simplicity of the approach and found it worth sharing. Let’s assume that we have a table “tbl” with one column “num”. This table has three rows having values 2, 3 & 4 for column “num”.

WITH tbl AS
     (SELECT 2 num
        FROM DUAL
      UNION
      SELECT 3 num
        FROM DUAL
      UNION
      SELECT 4 num
        FROM DUAL)
SELECT num
  FROM tbl;

We need the multiplication of row’s data for this column. So essentially, we are looking for an aggregate function MUL (num).

There is no such function as MUL () in Oracle (I actually tried using it). Here comes the computational part of the puzzle. A multiplication operation can be mathematically expressed as:

MUL (num) = EXP (SUM (LN (num)))

Not very clear at first, I agree. Lets review the maths behind it:

x = (2 * 3 * 4)
ln(x) = ln(2 * 3 * 4)
ln(x) = ln(2) + ln(3) + ln(4) => SUM(LN(num))
ln(x) = .693 + 1.098 + 1.386
ln(x) = 3.178
x = e (3.178) => EXP(SUM(LN(num)))
x = 24

And that’s it. We just created our own multiplication function and now the result can be calculated as:

  WITH tbl AS
     (SELECT 2 num
        FROM DUAL
      UNION
      SELECT 3 num
        FROM DUAL
      UNION
      SELECT 4 num
        FROM DUAL)
SELECT EXP (SUM (LN (num))) MUL
  FROM tbl;

Result: 24

Everything looks perfect. But hey, I have got negative values. The moment you put a negative value in the dataset, you are bound to get the following Oracle error:

“ORA-01428: argument ‘x’ is out of range”

This is because the range for LN () argument is > 0. But this is now easy to handle, here is how:

WITH tbl AS
     (SELECT -2 num
        FROM DUAL
      UNION
      SELECT -3 num
        FROM DUAL
      UNION
      SELECT -4 num
        FROM DUAL),
     sign_val AS
     (SELECT CASE MOD (COUNT (*), 2)
                WHEN 0 THEN 1
                ELSE -1
             END val
        FROM tbl
       WHERE num < 0)
SELECT   EXP (SUM (LN (ABS (num)))) * val
    FROM tbl, sign_val
GROUP BY val

Result: -24

So, we first counted the negative records in the table. If the count is odd, the final result should be negative and vice versa. We then multiplied this signed value with the multiplication of the absolute values. A subquery can also be used instead of GROUP BY but that’s trivial. Now the solution is complete and we are able to handle the negative values too.

I was so impressed by this approach that I haven’t given a thought about any other solution. But I am sure there would be. If you find a different approach, please share.

SELECT ROWNUM
FROM DUAL
CONNECT BY LEVEL < 10000;

Now, to generate the random data, the oracle build in package “dbms_random” comes handy. I am referring to the version 10GR2, there might be additional features available on 11G . Other build in functions can also be used. Here is a sample sql:

SELECT     LEVEL                                                       empl_id,
           MOD (ROWNUM, 50000)                                         dept_id,
           TRUNC (DBMS_RANDOM.VALUE (1000, 500000), 2)                 salary,
           DECODE (ROUND (DBMS_RANDOM.VALUE (1, 2)), 1, 'M', 2, 'F')   gender,
           TO_DATE (   ROUND (DBMS_RANDOM.VALUE (1, 28))
                    || '-'
                    || ROUND (DBMS_RANDOM.VALUE (1, 12))
                    || '-'
                    || ROUND (DBMS_RANDOM.VALUE (1900, 2010)),
                    'DD-MM-YYYY'
                   )                                                   dob,
           DBMS_RANDOM.STRING ('x', DBMS_RANDOM.VALUE (20, 50))        address
      FROM DUAL
CONNECT BY LEVEL < 10000;

You can create a table using this sql and that will give you some random test data to work on. The output looks something like:

EMPL_ID | DEPT_ID | SALARY    | GENDER | DOB       | ADDRESS
1       | 1       | 385433.6  | M      | 2/25/1903 | VVGJOPVIHD8HZELHK1SXWQ1RTNK84NT6
2       | 2       | 363024.64 | F      | 5/24/2010 | E4IOCU42LM7K2SS36OI0STDOO7A2UZ50L2Q5R1SME07
3       | 3       | 320010.48 | M      | 9/26/2009 | 8XM6CG3CSR6UA26PXPUTLPLPQNSQ3OJG7P0CL4XVHBMCVT
4       | 4       | 64230.96  | F      | 6/26/1991 | GLKYLEWG4NS0G67W64LF1G5GJPON5L8K93F
5       | 5       | 414134.44 | M      | 10/26/1981| QWXIT92XPEYYZZ0A8MR050ER8UJ30NYUHDJAEJHF2M3
...
...

There are numerous functions which can be used to generate randomized data in different ways. Best is to create a wrapper package which can generate number, string, date etc based on the parameter passed and then call that package. I will share it as soon as I am done writing it.

CREATE TABLE tbl_test(
	 SER_NO NUMBER,
 	 FST_NM VARCHAR2(30),
 	 DEPTID	NUMBER,
 	 CMNT   VARCHAR2(30));

INSERT INTO tbl_test VALUES(1, 'aaaaa', 2004, 'xxx');
INSERT INTO tbl_test VALUES(2, 'bbbbb', 2005, 'yyy');
INSERT INTO tbl_test VALUES(1, 'aaaaa', 2004, 'xxx');
INSERT INTO tbl_test VALUES(1, 'aaaaa', 2004, 'xxx');
INSERT INTO tbl_test VALUES(3, 'ccccc', 2005, 'zzz');
INSERT INTO tbl_test VALUES(2, 'bbbbb', 2005, 'yyy');

1. Using MIN(rowid) : The most common method of removing duplicate rows.

DELETE FROM tbl_test
      WHERE ROWID NOT IN (SELECT   MIN (ROWID)
                              FROM tbl_test
                          GROUP BY ser_no, fst_nm, deptid, cmnt);

Comment: This will take hours & hours if the table is large (records in million).

2. Using MIN(rowid) & Join: More or less the same as first one

DELETE FROM tbl_test t
      WHERE t.ROWID NOT IN (SELECT MIN (b.ROWID)
                              FROM tbl_test b
                             WHERE b.ser_no = t.ser_no
                               AND b.fst_nm = t.fst_nm
                               AND b.deptid = t.deptid
                               AND b.cmnt   = t.cmnt);

3. Using Subquery: This is an interesting one

DELETE FROM tbl_test
      WHERE ser_no IN (SELECT ser_no FROM tbl_test GROUP BY ser_no, fst_nm, deptid, cmnt HAVING COUNT (*) > 1)
        AND fst_nm IN (SELECT fst_nm FROM tbl_test GROUP BY ser_no, fst_nm, deptid, cmnt HAVING COUNT (*) > 1)
        AND deptid IN (SELECT deptid FROM tbl_test GROUP BY ser_no, fst_nm, deptid, cmnt HAVING COUNT (*) > 1)
        AND cmnt   IN (SELECT cmnt   FROM tbl_test GROUP BY ser_no, fst_nm, deptid, cmnt HAVING COUNT (*) > 1)
        AND ROWID NOT IN (SELECT   MIN (ROWID)
                              FROM tbl_test
                          GROUP BY ser_no, fst_nm, deptid, cmnt
                            HAVING COUNT (*) > 1)

Comment: A complicated way of performing the same task. Not efficient.

4. Using Nested Subqueries:

DELETE FROM tbl_test a
      WHERE (a.ser_no, a.fst_nm, a.deptid, a.cmnt) IN (SELECT b.ser_no, b.fst_nm, b.deptid, b.cmnt
                                                     FROM tbl_test b
                                                    WHERE a.ser_no = b.ser_no
                                                      AND a.fst_nm = b.fst_nm
                                                      AND a.deptid = b.deptid
                                                      AND a.cmnt   = b.cmnt
                                                      AND a.ROWID  > b.ROWID);

Comment: Will work but for large tables, this is not efficient.

5. Using Analytic Fucntions:

DELETE FROM tbl_test
      WHERE ROWID IN (
               SELECT rid
                 FROM (SELECT ROWID rid,
                              ROW_NUMBER () OVER (PARTITION BY ser_no, fst_nm, deptid, cmnt ORDER BY ROWID) rn
                         FROM tbl_test)
                WHERE rn <> 1);

Comments: This is by far one of the best solutions if the table is really really large. Using the invaluable power of Analytics.

6. CREATE-DROP-RENAME:  This one is a more appropriate solution in terms of resource usage in the sense that if we have a really large table, then with delete option we are generating a huge amount of UNDO information.(if we want to rollback for any reason). Even worst, the rollback segment may not be large enough to hold your UNDO information and give error. CTAS comes handy in this case.
Step 1.

CREATE  TABLE tbl_test1 NOLOGGING
   AS
   SELECT tbl_test .*
     FROM tbl_test tbl_test
    WHERE ROWID IN (SELECT rid
                      FROM (SELECT ROWID rid, ROW_NUMBER() OVER (PARTITION BY ser_no, fst_nm, deptid, cmnt ORDER BY ROWID) rn
                              FROM tbl_test)
                     WHERE rn=1);

Step 2.

DROP TABLE tbl_test; --drop the original table with lots of duplicate

Step 3.

RENAME tbl_test1 TO tbl_test; -- your original table without duplicates.

In case you have some other method of deleting duplicate data, please share it.

One of the older solutions is to determine the effective usage of indexes in the database. Once the monitoring usage clause for the index is enabled, we can determine the usage of the index by querying v$object_usage data dictionary view. The index monitoring time again depends on the application, database usage and business hours. It varies from case to case. Some applications might require a few hours for monitoring the usage of indexes. Some might require even months to determine the perfect indexes that need to be retained and the ones that need to be detained.

If the usage of the index is at all, or it results a bad performance to other queries, one can easily drop the index. However in future, if some adhoc queries require the index badly (where the index dropped would have increased the performance dramatically), we need to think reinstating the index again. The recreation of an index is a very expensive one and requires a lot of database resources and consumes a lot of time as well.

One of the new features of oracle 11g, Invisible indexes is a perfect solution to the above problem. An index can be made invisible to the Optimizer, so that the optimizer can’t see it. If an adhoc query requires the usage of the index it can explicitly specify the index as a part of hint.

The following example demonstrates invisible index better.

SQL> desc employee;
 Name                                      Null?    Type
 ----------------------------------------- -------- ---------

 EMPID                                              NUMBER
 DEPTNO                                             NUMBER
 EMPNAME                                            VARCHAR2(30)
 MGR_NAME                                           VARCHAR2(30)
 ADDRESS                                            VARCHAR2(100)

Let us create an index on EMPID column of the employee table.

SQL> create index idx_empid on employee(empid);

Index created.

After creating the index let us fire this simple query:

SQL> select * from employee where empid = 1001;

Execution Plan
-----------------------------------------------------------------------------------------
| Id  | Operation                   | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |           |     1 |   112 |     2   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS BY INDEX ROWID| EMPLOYEE  |     1 |   112 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | IDX_EMPID |     1 |       |     1   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------

The above execution plan confirms the usage of the index which we created on the empid column. Now let us make this index invisible to the optimizer. An index can be made invisible using the simple ALTER statement.

SQL> alter index idx_empid invisible;

Index altered.

The invisibility status of the index can be checked by using the following query:

SQL> select visibility from user_indexes where index_name = 'IDX_EMPID';

VISIBILITY
---------
INVISIBLE

Now let us fire the same query on the employee table. The below explain plan shows the index became invisible to the optimizer and a full table scan is performed instead of index scan.

SQL> select * from employee where empid = 1001;

Execution Plan

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

Let us now try to give an index hint in our above query.

SQL> select /*+ index(idx_empid) */ * from employee where empid = 1001;

Execution Plan

-----------------------------------------------------------------------------------------
| Id  | Operation                   | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |           |     1 |   112 |     2   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS BY INDEX ROWID| EMPLOYEE  |     1 |   112 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | IDX_EMPID |     1 |       |     1   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------

After giving the hint, the optimizer used the index once again and performed an index scan. From the above example it is clear that, when an index can be made invisible only to the Optimizer and not to the user. User can still use it by giving a hint to the optimizer where ever it is required.
Alternatively, there is a session level parameter, optimizer_use_invisible_indexes. This parameter can be set to TRUE, so that all the invisible indexes can be made visible to the optimizer.

SQL> alter session set optimizer_use_invisible_indexes = true;

Advantages of Invisble Indexes

1. Invisible indexes can help to a great extent, in testing scenarios where the optimizer behavior needs to be tested without the index. This does not need dropping and recreating the index.
2. Indexes can be created for certain adhoc queries (queries that are fired very infrequently) and can be made invisible after the usage.

However, invisible indexes behave the same like a normal index towards the DML operations. They need to be updated with each DML operation.

Earlier Approach:

Earlier RDBMS versions (6,7) were using a dictionary based approach based on static, table-wide dictionary. So, a table will have an associated look up global dictionary table which holds the lookup entries and the compressed data. The advantage of this approach was higher compression factor as compared to the latest block level compression. Also the global dictionary table will take less space as compared to the block level approach (explained next). But with the advent of new partition techniques and features, the block level approach holds greater merits.

Latest Compressing Techniques (specifically in reference to Oracle 10GR2):

The latest compression technique used by Oracle is a unique compression algorithm specially designed for RDMBS systems. The main features of this approach are:
Block Level compression:
The compression window for data compression is a database block. This means the data is compressed block wide instead of table. Every compressed block is self contained and all the information needed to uncompress the data is available within the block.
Symbol table:
The block contains a dictionary called as “symbol table” within each compressed block. This symbol table will have the common data and the links to associate this data with the actual rows.
Multi-Column Compression:
If a sequence of columns are having common data, then instead of saving each individual column as separate entry, the combination of the columns will be saved in the symbol table as a whole. This approach is particularly useful in case of materialized views using grouping sets and cubes (where the data is ordered).
Cross Column Compression:
As explain above, the symbol table holds the common data. This is true for the column values for different columns. So, if column values from the different columns are different, they all will share the same symbol table entry.

Advantage of Block Level Compression:

Disk Space saving:
This is the obvious reason for implementing data compression. Although the space saving comes at a cost of decreased query performance (time required to decompress the data), when used along with other features, this can be minimized.
Coexisting compressed and non-compressed data:
The same table can have both compressed and non-compressed data. This is possible because the compression is at block level, one block might hold compressed data and the other block might hold normal uncompressed data. This is particularly useful with partitioning where you can compress the old partitions while keep the current partition as non-compressed.
Less Buffer Size required:
The data from a compressed block is read and cached in its compressed format and it is decompressed only at data access time. As the data is cached in compressed form, more data can be hold into the same
amount of buffer cache.

How to use compression:

Compression can be used for tables, partitions and materialized view (Index compression is also possible, but that is out of scope of this article). The keyword “COMPRESS” is used with the table’s meta-data to compress the data. Please note that the compression works only in the following cases:

CREATE TABLE AS SELECT

Following example shows the compression using CTAS.

CREATE TABLE tbl_nocompress
AS
SELECT mod(rownum, 10) || 'ANY ADDITIONAL STRING TO MAKE THE COLUMN LENGTH LONGER, COMPRESSION WORKS BETTER' col1
  FROM all_objects;

CREATE TABLE tbl_compress
COMPRESS
AS
SELECT mod(rownum, 10) || 'ANY ADDITIONAL STRING TO MAKE THE COLUMN LENGTH LONGER, COMPRESSION WORKS BETTER' col1

SELECT segment_name, segment_type, blocks
  FROM dba_segments
 WHERE segment_name IN ('TBL_COMPRESS', 'TBL_NOCOMPRESS');

-- SEGMENT_NAME	  | SEGMENT_TYPE | BLOCKS
-- TBL_COMPRESS	  | TABLE        | 148
-- TBL_NOCOMPRESS | TABLE        | 1208

Two tables are created having 10 distinct values, one is compressed and other without compression. The blocks used for non-compressed table are almost 10 times that of compressed one. Please note that this is an indicative example and actual compression ratio will depend on database settings (for ex: db block size).

INSERT /*+ APPEND */

Now, lets insert the same data, with and without using “APPEND” hint:

INSERT INTO tbl_compress
SELECT mod(rownum, 10) || 'ANY ADDITIONAL STRING TO MAKE THE COLUMN LENGTH LONGER, COMPRESSION WORKS BETTER' col1
  FROM all_objects;

SELECT segment_name, segment_type, blocks
  FROM dba_segments
 WHERE segment_name IN ('TBL_COMPRESS', 'TBL_NOCOMPRESS');

-- SEGMENT_NAME   | SEGMENT_TYPE | BLOCKS
-- TBL_COMPRESS   | TABLE        | 1224
-- TBL_NOCOMPRESS | TABLE        | 1208

Although the tbl_compress is created with “COMPRESS” parameter (check the create script), normal DMLs are done without compression. If you use insert/update/delete, the modified data is NOT COMPRESSED. If you start with a large compressed table and update each row, each row will be decompressed and stored decompressed. This verifies that same table can hold both compressed and non-compressed data. Now, recreate the table and insert the entries in append mode:

DROP TABLE tbl_compress PURGE;

CREATE TABLE tbl_compress
COMPRESS
AS
SELECT mod(rownum, 10) || 'ANY ADDITIONAL STRING TO MAKE THE COLUMN LENGTH LONGER, COMPRESSION WORKS BETTER' col1
  FROM all_objects;

INSERT /*+ APPEND*/INTO tbl_compress
SELECT mod(rownum, 10) || 'ANY ADDITIONAL STRING TO MAKE THE COLUMN LENGTH LONGER, COMPRESSION WORKS BETTER' col1
  FROM all_objects;

-- SEGMENT_NAME   | SEGMENT_TYPE | BLOCKS
-- TBL_COMPRESS   | TABLE        |  292
-- TBL_NOCOMPRESS | TABLE        | 1208

This time we inserted the data in append mode, and the new data is compressed (block size approx. doubled instead of 10 times). Please note that although we are inserting the same data as it is already existing in the tables, new blocks are getting allocated to save it. The compression would have been much higher, if the table level compression were used instead of block level compression.

DIRECT PATH LOADS (SQLLRD)

while using DIRECT=TRUE with sqlldr

ALTER TABLE <TABLE_NAME> MOVE

Now lets try to compress the tbl_nocompress with ALTER command.

ALTER TABLE tbl_nocompress MOVE COMPRESS;

SELECT segment_name, segment_type, blocks
  FROM dba_segments
 WHERE segment_name IN ('TBL_COMPRESS', 'TBL_NOCOMPRESS');

-- SEGMENT_NAME   | SEGMENT_TYPE | BLOCKS
-- TBL_COMPRESS   | TABLE        | 292
-- TBL_NOCOMPRESS | TABLE        | 148

This is an easy way of compressing the table in case you were doing normal DMLs on a table with “compressed” attribute set (Remember that this will make the indexes on the table invalid because of rowid changes).

Achieving higher Compression Ratio:

Read Only/mostly Data => Compression is generally used for “read only” or “read mostly” data like archived data or old partitioned data. The current running partition can be kept uncompressed while the old partitions can be compressed.

Large DB Block Size => The larger the size of block size, the more rows it finds for compression in the same block and thus the chances of achieving higher compression are more.

Ordered data => With the right sorting order, more rows can be find with common data and thus higher compression can be achieved. As mentioned before, this can be particularly useful with materialized views used for aggregating data.

Long Fields with less Cardinality => Longer fields with less cardinality are ideal for compression as the space saving is larger.

Adding / Removing Columns from compressed tables:

Earlier it was not possible to add or remove columns from a compressed table. In Oracle 10G, you can add the column but can’t drop it (tested on 10.2.0.4). One way is to set the columns as unused:

ALTER TABLE tbl_compress ADD col2 NUMBER;

ALTER TABLE tbl_compress DROP COLUMN col2;
-- ORA-39726: unsupported add/drop column operation on compressed tables

ALTER TABLE tbl_compress SET UNUSED COLUMN col2;

Please note that once you set the column as unused, there is no easy way to get it back. There is no command like “ALTER TABLE SET USED COLUMN
” (at least in 10.2.0.4). In oracle 11G, you can drop the column from the compressed table after setting it unused. Here I would like to quote a statement from TOM’s blog:

“It is sort of “not necessary” of course in this case – in fact, I’d say dropping a column from a compressed table probably should be done via ‘alter table t move’ anyway (in order to, well, compress the data on the block again…)”

This should have given a broad idea about the concept. In oracle 11G, oracle has added more sophisticated compression techniques like “OLTP Compression”, “RMAN Compression”, “Network Compression” but that is out of scope of this article. Also, we are not discussing the performance penalty we pay for compression and the trade-off between space/performance. There are in-depth white papers available on web for consultation.

- I have disabled PK and now oracle is doing full table scan.
- How PK constraints and indexes are related/different?
- How Oracle is using a non-unique index to enforce PK constraints?

Although these questions seem simple to the experienced users yet these can act as food for thought for the new developers. I have tried to consolidate few aspects about PK constraint which I found particularly confusing / worth knowing.

1. Primary key(PK) constraint and unique index are different.
PK constraint is a rule that prohibits multiple rows from having the same value in the same column or combination of columns and prohibits values from being null.
Index is a database object which is used for fast retrieval of data. It is created using DDL commands: “CREATE INDEX” or as part of a “CREATE TABLE” with PK/UK constraint or an “ALTER TABLE” command to add these constraints.

2. An enabled PK constraint is always associated with an index.
The associated index can be unique or non-unique (discussed later). The corresponding index can be find by querying:

SELECT constraint_name, constraint_type, index_name
  FROM user_constraints
 WHERE table_name = '<TABLE_NAME>';

Also, if we have an enabled PK constraint, the corresponding column(s) will be “NOT NULL“. Now if you drop/disable the PK constriant, the column(s) will be changed to the state in which they were before adding the PK constraint.

-- Creating a table with two columns. One as NULL and other as NOT NULL
CREATE TABLE tbl_test ( col_1 NUMBER,
                                  col_2 NUMBER NOT NULL);

-- Querying to check the the column nullable status
SELECT table_name, column_name, nullable
  FROM user_tab_cols
 WHERE table_name = 'TBL_TEST';

-- TABLE_NAME | COLUMN_NAME | NULLABLE
-- TBL_TEST   | COL_1       | Y
-- TBL_TEST   | COL_2       | N

-- Adding the the PK constraint
ALTER TABLE tbl_test ADD CONSTRAINT tbl_test_pk PRIMARY KEY(col_1);

-- Querying to check the user constraints.
--Two entries, one for NOT NULL constraint and one for PK constraint
SELECT a.table_name, b.column_name, a.constraint_name,
           a.constraint_type, a.index_name
  FROM user_constraints a, user_cons_columns b
 WHERE a.table_name      = 'TBL_TEST'
   AND a.constraint_name = b.constraint_name;

-- TABLE_NAME | COLUMN_NAME | CONSTRAINT_NAME | CONSTRAINT_TYPE | INDEX_NAME
-- TBL_TEST   | COL_2       | SYS_C001231845  | C               |
-- TBL_TEST   | COL_1       | TBL_TEST_PK     | P               | TBL_TEST_PK

-- Rechecking the column nullable status. Both the columns are now NOT NULL
SELECT table_name, column_name, nullable
  FROM user_tab_cols
 WHERE table_name = 'TBL_TEST';

-- TABLE_NAME | COLUMN_NAME | NULLABLE
-- TBL_TEST   | COL_1       | N
-- TBL_TEST   | COL_2       | N

-- Disabling the PK constraint
ALTER TABLE tbl_test DISABLE PRIMARY KEY;
-- OR
-- ALTER TABLE tbl_test DISABLE CONSTRAINT tbl_test_pk;

-- The column status is changed back as it was before adding the PK.
SELECT table_name, column_name, nullable
  FROM user_tab_cols
 WHERE table_name = 'TBL_TEST';

-- TABLE_NAME | COLUMN_NAME | NULLABLE
-- TBL_TEST   | COL_1       | Y
-- TBL_TEST   | COL_2       | N

3. If the PK constraint is disabled, there will be no index associated with it.
The “index_name” in the above query would be blank. But the constraint name would still be there. So, PK constraint exists (with status as disabled) but there is no associated index.

DROP TABLE tbl_test;

CREATE TABLE tbl_test (col_1 NUMBER);

CREATE INDEX idx_col_1 ON tbl_test (col_1);

ALTER TABLE tbl_test ADD CONSTRAINT tbl_test_pk PRIMARY KEY(col_1);

SELECT constraint_name, constraint_type, index_name
  FROM user_constraints
 WHERE table_name = 'TBL_TEST';

-- CONSTRAINT_NAME | CONSTRAINT_TYPE | INDEX_NAME
-- TBL_TEST_PK     | P               | IDX_COL_1

ALTER TABLE tbl_test DISABLE PRIMARY KEY;
-- OR
-- ALTER TABLE tbl_test DISABLE CONSTRAINT tbl_test_pk;

-- Once the PK is disabled, the association with the index is gone
SELECT constraint_name, constraint_type, index_name, status
  FROM user_constraints
 WHERE table_name = 'TBL_TEST';

CONSTRAINT_NAME | CONSTRAINT_TYPE | INDEX_NAME | STATUS
TBL_TEST_PK     | P               |            | DISABLED

4. Once PK constraint is disabled, the index left on that column can be dropped.
If the index was created by oracle with the creation of PK constraint, it will be dropped automatically. If some existing index was associated with the PK constraint, it will not be dropped by oracle(refer point 6 for details). But its now possible to drop that index manually.

-- With the primary key disabled, the index can now be dropped
DROP INDEX idx_col_1;

SELECT table_name, index_name
  FROM user_indexes
 WHERE table_name = 'TBL_TEST';

-- no rows returned.

5. Enabling of the PK constraint requires association with index.
If we now try to enable the PK constraint again, it will pick up the first index it found on that column and will get associated with it. In case there is no index to get associated, oracle will create a new index with the name same as that of PK constraint.

ALTER TABLE tbl_test ENABLE PRIMARY KEY;
-- OR
-- ALTER TABLE  tbl_test ENABLE CONSTRAINT tbl_test_pk;

-- Oracle has created a new index with name "TBL_TEST_PK"
SELECT constraint_name, constraint_type, index_name
  FROM user_constraints
 WHERE table_name = 'TBL_TEST';

-- A new index "TBL_TEST_PK" is created and associated with the PK constraint
-- CONSTRAINT_NAME | CONSTRAINT_TYPE | INDEX_NAME
-- TBL_TEST_PK     | P               | TBL_TEST_PK

SELECT table_name, index_name
  FROM user_indexes
 WHERE table_name = 'TBL_TEST';

-- TABLE_NAME | INDEX_NAME
-- TBL_TEST   | TBL_TEST_PK

6. Use “USING INDEX” clause to associated a particular index with the PK.
If there are more than one indexes on the column on which you want to add PK constraint, we can selectively choose the index to be assoicated with the PK using “USING INDEX“. This clause can be used while:
a) Adding the PK constraint for the first time (using “ALTER TABLE” command).

DROP TABLE tbl_test;

CREATE TABLE tbl_test ( col_1 NUMBER,
                        col_2 NUMBER,
                        col_3 NUMBER);

CREATE INDEX idx_col_1_2 ON tbl_test(col_1, col_2);

CREATE INDEX idx_col_1_3 ON tbl_test(col_1, col_3);

CREATE UNIQUE INDEX idx_col_1 ON tbl_test(col_1);

-- Forcing oracle to use the unique index "IDX_COL_1"
ALTER TABLE tbl_test ADD CONSTRAINT tbl_test_pk PRIMARY KEY(col_1)
USING INDEX idx_col_1;

SELECT constraint_name, constraint_type, index_name
  FROM user_constraints
 WHERE table_name = 'TBL_TEST';

-- CONSTRAINT_NAME | CONSTRAINT_TYPE | INDEX_NAME
-- TBL_TEST_PK     | P               | IDX_COL_1

b) Enabling the PK constraint.

DROP TABLE tbl_test;

CREATE TABLE tbl_test ( col_1 NUMBER, col_2 NUMBER,
                        col_3 NUMBER);

CREATE INDEX idx_col_1_2 ON tbl_test(col_1, col_2);

CREATE INDEX idx_col_1_3 ON tbl_test(col_1, col_3);

CREATE UNIQUE INDEX idx_col_1 ON tbl_test(col_1);

ALTER TABLE tbl_test ADD CONSTRAINT tbl_test_pk PRIMARY KEY(col_1);

SELECT table_name, index_name, uniqueness
  FROM user_indexes
 WHERE table_name = 'TBL_TEST';

-- TABLE_NAME | INDEX_NAME  | UNIQUENESS
-- TBL_TEST   | IDX_COL_1_2 | NONUNIQUE
-- TBL_TEST   | IDX_COL_1_3 | NONUNIQUE
-- TBL_TEST   | IDX_COL_1   | UNIQUE

-- Although an unique index exists, oracle has picked up the first index
SELECT constraint_name, constraint_type, index_name
  FROM user_constraints
 WHERE table_name = 'TBL_TEST';

-- CONSTRAINT_NAME | CONSTRAINT_TYPE | INDEX_NAME
-- TBL_TEST_PK     | P               | IDX_COL_1_2

ALTER TABLE tbl_test DISABLE PRIMARY KEY;

-- Forcing oracle to use the unique index
ALTER TABLE  tbl_test ENABLE CONSTRAINT TBL_TEST_PK USING INDEX IDX_COL_1;

SELECT constraint_name, constraint_type, index_name
  FROM user_constraints
 WHERE table_name = 'TBL_TEST';

-- CONSTRAINT_NAME | CONSTRAINT_TYPE | INDEX_NAME
-- TBL_TEST_PK     | P               | IDX_COL_1

Manully associating PK constraint with already existing unique/non-unique index has the following advantages:
a) The index remains available and valid when the constraint is disabled.
b) Enabling the PK constraint doesn’t require rebuilding the unique/non-unique index associated with the constraint.
c) The redundant indexes can be eliminated. PK constraint can be associated with a composite index too if the column is included as the prefix of the composite index. So, in the example above, it iss possible to remove the unique index (if not required) and the composite index can be used for PK enforcement.

7. The index associated with the PK constraint needn’t be unique.
A non-unique index can also be be associated with the PK constraints. Now the question is how oracle allows PK constraint to be enforced using a non-unique index. Here is the explanation (as per best of my knowledge, might not be correct):

As described above, PK constraint is a rule to prohibit duplicate/null records for the PK column. Suppose, we already have 1 Million records in the table and inserting a new entry. So, to enforce the PK constraint, Oracle has to search through the already present records and this is where the index comes handy. If you have an index on that column, the search will be quite fast. The unique index will be the best but a non-unique index will also be a better option as compared to a full table scan. So, the basic purpose of associating index with PK constraints is to efficiently enforce the underlying rule. So, using index for PK constraint enforcement is a part of Oracle architecture (I assume its the same for all other RDBMS).

DROP TABLE tbl_test;

CREATE TABLE tbl_test ( col_1 NUMBER, col_2 NUMBER,
                        col_3 NUMBER);

CREATE INDEX idx_col_1_2 ON tbl_test(col_1, col_2);

-- Associating composite index with the PK constraint
ALTER TABLE tbl_test ADD CONSTRAINT tbl_test_pk PRIMARY KEY(col_1)
USING INDEX idx_col_1_2;

SELECT constraint_name, constraint_type, index_name
  FROM user_constraints
 WHERE table_name = 'TBL_TEST';

-- CONSTRAINT_NAME | CONSTRAINT_TYPE | INDEX_NAME
-- TBL_TEST_PK     | P               | IDX_COL_1_2

 SELECT table_name, index_name, uniqueness
  FROM user_indexes
 WHERE table_name = 'TBL_TEST';

-- TABLE_NAME | INDEX_NAME  | UNIQUENESS
-- TBL_TEST   | IDX_COL_1_2 | NONUNIQUE

8. Merits of allowing non-unique index for enforcing PK constraints:
a) The non-unique indexes facilitates the use of “INITIALLY DEFERRED” clause with the constraint until the transaction has been committed if the PK constraint has been defined as “DEFERRABLE” at the time of creating. The “DEFERRABLE” PK constraint can’t be associated with a unique index.

DROP TABLE tbl_test;

CREATE TABLE tbl_test ( col_1 NUMBER,
                        col_2 NUMBER);

ALTER TABLE tbl_test ADD CONSTRAINT tbl_test_pk PRIMARY KEY(col_1)
INITIALLY DEFERRED DEFERRABLE;

-- The resulting index created by oracle is non-unique
SELECT table_name, index_name, uniqueness
  FROM user_indexes
 WHERE table_name = 'TBL_TEST';

-- TABLE_NAME | INDEX_NAME  | UNIQUENESS
-- TBL_TEST   | TBL_TEST_PK | NONUNIQUE

-- Allowing duplicate records inspite of the presence of PK consraint
INSERT INTO tbl_test VALUES (1,2);
INSERT INTO tbl_test VALUES (1,2);
INSERT INTO tbl_test VALUES (1,2); 

-- Constraint checked at the time of transaction commit
COMMIT;
-- ORA-02091: transaction rolled back
-- ORA-00001: unique constraint (GC_ADMIN.TBL_TEST_PK) violated

b) The “NOVALIDATE” option can be used to exclude the enforcement of constraint on the already existing data.

DROP TABLE tbl_test purge;

CREATE TABLE tbl_test ( col_1 NUMBER);

INSERT INTO tbl_test VALUES (1);
INSERT INTO tbl_test VALUES (1);
INSERT INTO tbl_test VALUES (1);

ALTER TABLE tbl_test add constraint idx_col_1 PRIMARY KEY (col_1) NOVALIDATE;
-- ORA-02437: cannot validate (GC_ADMIN.IDX_COL_1) - primary key violated

ALTER TABLE tbl_test add constraint idx_col_1 PRIMARY KEY (col_1) DISABLE;

ALTER TABLE tbl_test ENABLE NOVALIDATE PRIMARY KEY;
-- ORA-02437: cannot validate (GC_ADMIN.IDX_COL_1) - primary key violated

-- This is because oracle tries to create unique index for the PK constraints.
-- The statement fails while checking the uniqueness for creating the unique index.
-- To fix this, create a non-unique index first. Then oracle will associate
-- the primary key constraint with this non-unique index.
CREATE INDEX idx_col_1 ON tbl_test(col_1);

ALTER TABLE tbl_test ENABLE NOVALIDATE PRIMARY KEY;

9. Bitmap index can’t be associated with a PK constraint.

DROP TABLE tbl_test;

CREATE TABLE tbl_test ( col_1 NUMBER,
                        col_2 NUMBER,
                        col_3 NUMBER);

CREATE BITMAP INDEX idx_col_1 ON tbl_test (col_1);

ALTER TABLE tbl_test ADD CONSTRAINT tbl_test_pk PRIMARY KEY(col_1) USING INDEX idx_col_1;
-- ORA-14196: Specified index cannot be used to enforce the constraint.

10. Dropping the PK may or may not drop the associated index.
If you drop a PK constraint, the associated index may or may not be dropped depending on the association of PK constraint and index. Two scenario arises:
a) The PK constraint is associated with an already present index (either by using “USING INDEX” clause or by default association if not specifically specified). In that case, the index will not be dropped with the dropping of PK constraint.

DROP TABLE tbl_test;

CREATE TABLE tbl_test ( col_1 NUMBER);

CREATE INDEX idx_col_1 ON tbl_test (col_1);

ALTER TABLE tbl_test ADD CONSTRAINT tbl_test_pk PRIMARY KEY(col_1)
USING INDEX idx_col_1;

ALTER TABLE tbl_test DROP PRIMARY KEY;

-- Primary Key dropped
SELECT constraint_name, constraint_type, index_name
  FROM user_constraints
 WHERE table_name = 'TBL_TEST';

-- no rows selected.
-- The index is still present
 SELECT table_name, index_name, uniqueness
  FROM user_indexes
 WHERE table_name = 'TBL_TEST';

-- TABLE_NAME | INDEX_NAME | UNIQUENESS
-- TBL_TEST   | IDX_COL_1  | NONUNIQUE

b) If the PK constraint is created while there is no index on PK column, oracle will create a new unique index with the same name as PK constraint. By default, this index will be dropped with the dropping of PK constraint. You can keep this index intact by using the “KEEP INDEX” clause.

DROP TABLE tbl_test;

CREATE TABLE tbl_test ( col_1 NUMBER);

ALTER TABLE tbl_test ADD CONSTRAINT tbl_test_pk PRIMARY KEY(col_1);

SELECT constraint_name, constraint_type, index_name
  FROM user_constraints
 WHERE table_name = 'TBL_TEST';

-- CONSTRAINT_NAME | CONSTRAINT_TYPE | INDEX_NAME
-- TBL_TEST_PK     | P               | TBL_TEST_PK

SELECT table_name, index_name, uniqueness
  FROM user_indexes
 WHERE table_name = 'TBL_TEST';

-- TABLE_NAME | INDEX_NAME  | UNIQUENESS
-- TBL_TEST   | TBL_TEST_PK | UNIQUE

ALTER TABLE tbl_test DROP PRIMARY KEY;

SELECT constraint_name, constraint_type, index_name
  FROM user_constraints
 WHERE table_name = 'TBL_TEST';

-- no rows selected.

 SELECT table_name, index_name, uniqueness
  FROM user_indexes
 WHERE table_name = 'TBL_TEST';

-- no rows selected.

ALTER TABLE tbl_test ADD CONSTRAINT tbl_test_pk PRIMARY KEY(col_1);

ALTER TABLE tbl_test DROP PRIMARY KEY KEEP INDEX;

-- The PK constraint is gone
SELECT constraint_name, constraint_type, index_name
  FROM user_constraints
 WHERE table_name = 'TBL_TEST';

-- no rows selected.
-- Yet the index created by oracle is still there
 SELECT table_name, index_name, uniqueness
  FROM user_indexes
 WHERE table_name = 'TBL_TEST';

-- TABLE_NAME | INDEX_NAME  | UNIQUENESS
-- TBL_TEST   | TBL_TEST_PK | UNIQUE

Please note that the above mentioned points are also more or less applicable for Unique key(UK) constraints. I haven’t tried to touch that subject to keep the content precise.
All queries are tested and verified on Oracle 10.2.0.4 version.

Disclaimer: All data and information provided on this article is for informational purposes only. Author makes no representations as to accuracy, completeness, suitability, or validity of any information on this article. All information is provided on an as-is basis.