Tài liệu Oracle Unleashed- P2 docx

If you add a constraint to a table after it has been created, any columns that make up the PRIMARY KEY constraint are modified to NOT NULL.. It dictates that a column or set of columns o

Because integrity constraints are checked at the database level, they are performed regardless of where the insert, update, delete statement originated—whether it was an Oracle or a non-Oracle tool Defining checks using these constraints is also quicker than performing the same checks using SQL In addition, the information provided by declaring constraints

is used by the Oracle optimizer to make better decisions about how to run a statement against the table The Oracle Forms product can also use constraints to automatically generate code in the front-end programs to provide an early warning to the user of any errors

The types of integrity constraints that you can set up on a table are NOT NULL, PRIMARY KEY, UNIQUE, FOREIGN KEY, CHECK, and indexes

NOT NULL Constraints

You set the NOT NULL constraint against a column to specify that the column must always have a value on every row;

it can never be null By default, all the columns in a table are nullable For example, using a NOT NULL constraint on

an orders table, you can specify that there must always be an order amount

PRIMARY KEY

The PRIMARY KEY constraint defines a column or a set of columns that you can use to uniquely identify a single row

No two rows in the table can have the same values for the primary key columns In addition, the columns for a primary key constraint must always have a value—in other words, they are NOT NULL If you add a constraint to a table after it has been created, any columns that make up the PRIMARY KEY constraint are modified to NOT NULL Only one PRIMARY KEY constraint can exist for any table For example, using a PRIMARY KEY constraint on an orders table, you can specify that a table cannot have two records with the same order number

UNIQUE

The UNIQUE constraint defines a secondary key for the table This is a column or set of columns that you can use as another way of uniquely identifying a row No two rows can have the same values for the UNIQUE key column or columns Although it is not possible for a table to have more than one primary key, a table can have more than one UNIQUE constraint

The columns for a UNIQUE constraint do not have to be identified as NOT NULL (although they usually are) If the values for any of the columns that form the unique constraint are null, the constraint is not checked For example, using a PRIMARY KEY and UNIQUE constraint on a customers table, you can specify that the customer number is a primary key and that the customer name is a unique key (which would mean that you could not have two customers with the same name on your table—a rare situation)

The UNIQUE constraint is not checked if the values in the column are null

FOREIGN KEY

The FOREIGN KEY or referential integrity constraint enforces relationship integrity between tables It dictates that a column or set of columns on the table match a PRIMARY KEY or UNIQUE constraint on a different table For example, you could set up a FOREIGN KEY constraint on the orders table to specify that whenever an order record is inserted or updated, the customer number must also exist in the customers table This ensures that you don't get orders for

nonexistent customers

You use FOREIGN KEY constraints to enforce parent/child relationships between tables You can even use them to Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

enforce self-referential constraints, usually in situations where a hierarchical structure is set up with all the rows held in the same table If any of the columns of the foreign key are null, the constraint is not checked at all Foreign key columns are usually declared as NOT NULL

It is possible to specify that when the parent row is deleted, the delete should automatically cascade and delete the child rows—a dangerous situation The user is informed only about the master rows that were removed, and he might not be aware of the additional rows that were deleted automatically in the background because he is not told that this cascading deletion has happened

Only this automatic deletion of child rows is supported by specifying the ON DELETE CASCADE clause to the end of the foreign key creation statement If you change the master table's key value, however, the child rows are not updated automatically to reflect the new key; you can implement this update cascade requirement using database triggers

FOREIGN KEY constraints are not checked at all if any of the columns in the foreign key are null

CHECK

A CHECK constraint specifies additional logic that must be true for the insert, update, or delete statement to work on the table The additional logic returns a Boolean result, and in the check constraint, you ensure the values in the row being modified satisfy a set of validation checks that you specify The syntax of a CHECK constraint is very similar to the syntax found in the WHERE clause of a SELECT statement; however, you cannot use subqueries or other columns that vary over time (such as SYSDATE) You can use database triggers to perform this additional processing that you cannot put into constraints For example, using a CHECK constraint on the orders table, you can specify that the order amount must be greater than zero and the salesman's commission cannot be greater than 10 percent of the order total

Indexes

PRIMARY KEY and UNIQUE constraints automatically create an index on the columns they're defined against if the constraint is enabled upon creation If an index already exists on the columns that form the PRIMARY KEY or UNIQUE constraint, that index is used, and Oracle cannot create a new one Oracle creates indexes when the constraint is enabled (which is the default when the constraint is first added to the table) Oracle drops the indexes from the table when the constraint is disabled Enabling and disabling constraints can take significant time and system overhead due to the index creation and removal

When you set up a FOREIGN KEY constraint, the columns are not indexed automatically Because the foreign key columns are usually involved in joining tables together, you manually create indexes on those columns

Disabling a PRIMARY KEY or UNIQUE constraint drops the index for the constraint

Database Triggers

A database trigger is a PL/SQL block that you can define to automatically execute for insert, update, and delete

statements against a table You can define the trigger to execute once for the entire statement or once for every row that

is inserted, updated, or deleted For any one table, there are twelve events for which you can define database triggers For each of the twelve events, you can define many database triggers for the same event

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

A database trigger can call database procedures that are also written in PL/SQL Unlike database triggers, procedures on the database are stored in a compiled form For this reason, you should put the longer code segments into a procedure and then call the procedure from the database trigger

In addition to implementing complex business rules, checking, and defaulting, you can use database triggers to insert, update, and delete other tables An example of this use is providing an auditing facility where an audit trail is

automatically created in an audit table whenever a row is changed on a table Without database triggers, this function would be implemented in the front-end programs that make the change to the database; however, someone bypassing the code in the front-end programs (using SQL*Plus, for example) would not go through the checks and processing defined

Database triggers differ from constraints in that they enable you to embed SQL statements within them, whereas

For example, before I can create a trigger on a table (even if I own the table as an Oracle user), I must have a system privilege called CREATE TRIGGER either assigned to my Oracle user account or assigned to a role given to the user account

The CREATE SESSION privilege is another frequently used system-level privilege In order to make a connection to the database, an Oracle account must have the CREATE SESSION system-level privilege assigned to it This gives the account the privilege to make connections to the database

Object-Level Privileges

Object-level privileges provide the capability to perform a particular type of action (select, insert, update, delete, and so on) on a specific object The owner of the object has full control over the object and can perform any action on it; he doesn't need to have object-level privileges assigned to him In fact, the owner of the object is the Oracle user who grants object-level privileges to others

For example, if the user who owns a table wants another user to select and insert rows from his table (but not update or delete), he grants the select and insert object-level privileges on that table to the other user

You can assign object-level privileges either directly to users or to roles that are then assigned to one or more Oracle user accounts

Users and Roles

A role is a type of object that you can use to simplify the administration of system and object-level privileges Instead of assigning privileges directly to user accounts, you can assign the privileges to roles that are then assigned to users

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

Roles are essentially groupings of system and object-level privileges They make the administration of privileges much easier because you can configure the privileges for a particular type of user once and assign those privileges to a role When a user needs that set of privileges, you can use a single role assignment command to set that user up Without the use of roles, you'd need to issue many commands for each of the different privileges required

In addition, you can set up different roles with the correct privileges even though you don't yet have Oracle user accounts that require those assignments You can assign a role to another role, building hierarchies of roles Also, you can protect

a role with a password that the user must supply when he wants to enable the role

As already discussed, a physical database could contain many Oracle user accounts that are protected by passwords You must supply the username and password regardless of which tool you use to gain access to the database Roles are not the same as Oracle users; you cannot connect to the database by supplying a role name and password

In addition, you can set up how all the different types of auditing record the entries The audit trail can record one entry per operation regardless of how many attempts are made on the operation during the connection session Alternatively, request one entry in the audit trail for every attempt (successful or not) on the operation during the session

If it's set up and enabled, the audit trail keeps the audit information in a data dictionary table owned by the user SYS This table indicates the operation being audited, the user performing the operation, and the date and time of the

operation Oracle provides a set of data dictionary views to make the information in the dictionary audit table more meaningful Although the audit trail is implemented in a data dictionary table, it keeps the insertion of rows in the audit trail even if the user rolls back his transaction

The database administrator can clear out or archive the audit trail periodically

Backup and Recovery

In this part, I discuss some of the options that the architecture gives you when it comes to backing up and recovering your database See Chapter 14, "Backup and Recovery," for more detail

Backup and Recovery Options

This section outlines at a high level some of the options available for backing up and restoring your database I discuss the types of failure that can occur and the actions to take The major part of this section describes preventive action to guard against loss of your database files

This section discusses in theory the available options The backup and recovery options mentioned here, along with other available options, are discussed in greater detail in Chapter 14

Different Types of Failure

The major types of failure that can occur are statement failure, user process failure, machine failure, distributed

transaction failure, instance failure, and disk failure/file loss

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

Statement Failure

In Oracle, a DML statement such as UPDATE operates on either all the rows satisfying its where clause or none at all

Failure with a statement occurs for a myriad of reasons For example, when you insert rows into a table, the table might require more storage; if the database software discovers that no more free storage is available, it returns an error message

to the user Oracle does not leave only half the rows updated Even if the failure occurs halfway through the statement, the rows already modified are "unmodified." This is known as statement-level rollback

Note that other DML statements in the transaction remain in a pending state ready for a commit or rollback

User Process Failure

A user process failure occurs when the user process making the connection to the database terminates abnormally during execution For example, the system administrator could have killed the user process If this does occur, the Oracle background process PMON automatically rolls back any changes for the current transaction All changes already

committed by the user process are saved, but inserts, updates, and deletes since the last commit or rollback are reversed

Also, the PMON background process releases any locks, rollback segments, and other system resources acquired by the user process when it was alive No database administrator involvement is necessary The database continues to function

as usual, and the tables are accessible to other users (A slight delay could occur before the locks are released.)

Remember that a COMMIT statement writes only the changes to the redo log files; it does not write the database blocks back to disk at the point at which the commit was issued If the database blocks with committed changes were written to the database files before the machine failure, the SMON background process obviously does not need to reapply the changes for those blocks

Instance Failure

Instance failure occurs when the machine is still up and running but the Oracle instance itself fails (perhaps one of the background processes was killed) This situation is very similar to machine failure in that the database administrator needs only to restart the instance; the SMON process reapplies any changes When restarting the instance after this kind

of failure, you will notice no difference from when the instance is started after a normal shutdown

Distributed Transaction Failure

A distributed transaction is one that involves changes to more than one database If a failure occurs during a distributed transaction, the RECO background process (if it's running) automatically synchronizes the rollbacks of the transaction's changes across all the databases involved Again, no manual intervention is required in all but the most serious cases The database administrators of the instances involved in the distributed transaction can manually force the commit or rollback of the changes on their databases, but I recommend that you leave the recovery to the RECO background process if possible This might not be possible if the links between the databases are not available for the RECO

processes on all the instances to communicate

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

Disk Failure/File Loss

The only time you really need to concern yourself with recovery is when you lose one or more of the files making up the database—the database files themselves, the control file, and the redo logs Some type of manual recovery is necessary

If you lose one or more of the files (database, redo, control), you have available the options highlighted in the following sections In every situation, you must work with a previous backup of the database

If you lose one or more of the database files, you could restore them from the last backup and reapply the changes since the last backup from the online and offline redo log files You must have some kind of backup of the files and the

complete set of online and offline redo logs from which to reapply all the changes made to the database

With the archiving option, you lose no changes in the database if the complete set of redo logs is available All the changes committed before the file was lost are reapplied It is also possible to perform recovery if the control or redo log files are lost

Hot Backups

Some sites (such as worldwide airline reservations systems) cannot shut down the database while making a backup copy

of the files The cold backup is not an available option

You can use a different means of backing up your database—the hot backup Issue a SQL command to indicate to Oracle, on a tablespace-by-tablespace basis, that you want to back up the files of the tablespace The users can continue

to make full use of the files, including making changes to the data Once you have indicated that you want to back up the tablespace files, you can use your operating system to copy those files to your backup destination

The database must be running in ARCHIVELOG mode for the hot backup option

If a data loss failure does occur, you can restore the lost database files using the hot backup and the online and offline redo logs created since the backup was done The database is restored to the most consistent state without any loss of committed transactions

Export and Import

Along with the RDBMS software, Oracle provides two utilities that you can use to back up and restore the database These utilities are useful to database administrators for system-wide backups and recoveries and also application

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

developers for temporary backups of their own data and object recovery into their own user accounts

The Export utility dumps the definitions and data for the specified part of the database to an operating system binary file The Import utility reads the file produced by an export, recreates the definitions of objects, and inserts the data

For a full database import, you must have an existing template database already created

If you use Export and Import as a means of backing up and recovering the database, you cannot recover all the changes made to the database since the export was performed This is similar to the situation with the cold backup The best you can do is recover the database to the time when the export was last performed

On large, data-filled databases, the Export and Import utilities can take a long time to run; many hours is not unusual However, the utilities do provide an option to selectively export and import different user accounts and even objects within an Oracle user account

Redo Logs

Redo logs record all the changes made to data blocks on the database If the database is running in ARCHIVELOG mode and only the offline redo logs are lost, you should shut down the database and make another backup of the three sets of files for the database

If the online redo logs are lost, however, you could lose some work because some of the information required to reapply changes to the database files is in the online redo log files To guard against this, you can multiplex (mirror) the online redo log files in the same way as the control files When the RDBMS software writes changes to one redo log, the exact same information is written to an exact copy of the redo log

Distributed Databases

A distributed database is one logical database that is implemented as two or more physical databases on either the same machine or separate machines thousands of miles away The system's designers decide where the tables should

physically reside

Each physical database has its own instance and sets of files, and the machines on which the databases reside are

connected over a network The location of tables can be made transparent to the application using database links and synonyms

Oracle enables a transaction and even a single statement to access tables on two or more distributed databases This does not necessitate any more coding by the application developers

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

A distributed transaction is a transaction that modifies tables on more than one database and then expects all the changes

to be committed If there is any kind of failure, all the changes on all the databases are rolled back A distributed

transaction can involve many Oracle databases and only one non-Oracle database The Oracle two-phase commit

mechanism controls the synchronization of commits across all databases and can automatically roll back changes on all the databases if any kind of failure should occur The RECO background process synchronizes this operation

In addition to the this functionality, Oracle also provides the capability to replicate tables from one database to others This is called creating a snapshot of the table

You create a snapshot with the CREATE SNAPSHOT command on the database where you want to have the copy of the

data The Oracle RDBMS software automatically sends down any changes made to the master copy of the table to each

of the snapshot copies at user-defined intervals without any manual intervention

The snapshot mechanism enables you to make updates to the snapshot copy of the table, in which case the changes are sent from the copy table back to the master table

Chapter 53, "Networking Oracle," discusses distributed databases in greater detail

National Language Support

Oracle's national language support (NLS) enables users to use the database in their own languages It provides the following functions:

● Support for different encoding schemes, so that data created with an encoding scheme on one machine can be processed and displayed on another You define the character set to be used for storing data on the database as part of the CREATE DATABASE statement For example, data created on a database with the 7-bit U.S ASCII standard character set can be displayed on a machine connected to the same database using the Chinese

GB2312-8 character set Translation tables within the national language support provide this support

● Control over the language used for server error and informational messages, numbers, dates, currency formats, and the starting day of the week

● Support for linguistic sort to ensure the characters appear in the correct order next to each other in a sort

● Definition of a NLS language either for the database as a whole or at the session level With changes to the session parameters but without any changes to the Oracle user account, you could run some sessions with English, others German, others French, and so on, if the same Oracle username is connected to the database with many different sessions

You can add support for new languages using the NLS*WorkBench product, which essentially maintains translation tables for interpreting input from the user and for displaying output

When it comes to delivering application systems in different languages, the most important part of the user interface is the different prompts, boilerplate, and messages from the application Currently, the application developers themselves define how the boilerplate, prompts, and messages from the application system change from one language to another Oracle is working on a translation product to make this task easier

Following a SQL Statement Through the Architecture

In this section, I bring together major parts of the Oracle architecture and follow the steps a typical SQL statement might

go through to be executed I use a simple scenario with both the Oracle SQL*Plus tool and the Oracle database server machine on a UNIX box without any networking involved Using a single task configuration, the Oracle instance has just started

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

The following shows some of the steps involved in executing SQL statements

1 The user executes the SQL*Plus tool and enters the Oracle username and password

2 Oracle validates the username and password against the data dictionary and sends a response to the user process

to indicate connection

3 The user enters a SELECT statement

4 Oracle must translate the SELECT before it executes it so the Oracle parser and optimizer is called If any user

has issued exactly the same statement before, the parsed version might be in the shared pool area in memory

Oracle uses the parsed version, so no extra parsing is done for this statement

5 To translate the SELECT statement, Oracle must obtain the names of the objects, privileges, and other

information from the data dictionary The data dictionary cache area in the shared pool in the SGA does not have the information on the tables, so parsing of the SELECT statement is suspended while the information is read in

6 Oracle runs a recursive SQL statement (a system-generated statement) to load information about the objects from the data dictionary tables in the database files into the data dictionary cache in memory

7 Parsing of the original user SELECT statement resumes, and Oracle constructs an optimization plan to control the way the statement runs

8 The statement accesses a table Assume the Oracle blocks for the table are not in the database buffer cache in the SGA The required Oracle blocks are read in from the database files and held in the cache area of the SGA

9 Oracle runs the statement and returns the results to the user

10 The user issues an UPDATE statement to modify some of the fields on the rows he's just selected Because the data dictionary cache already has the information about the table in memory, no more recursive SQL is

generated (assuming that the information has not been flushed out by another process requiring space in the cache area) Also, the Oracle blocks for the table are in the database buffer cache, so you won't do another disk I/O to read these blocks in

11 Oracle locks the rows to be updated

12 Before Oracle makes the UPDATE, information about the old state of the blocks is recorded in a rollback segment and the original version of the values is also recorded in the redo buffers cache

13 Oracle updates the rows and records the new version of the values in the redo buffer cache in the SGA

14 The user issues the COMMIT command to make the change permanent to the database

15 Oracle records an entry indicating a commit in the redo buffer cache, and the old, new, and the commit entry are all flushed down to the online redo log (whichever one is the current one in use)

16 The rollback segment is released (but not overwritten) for other processes to use

17 Oracle releases the locks on the table

18 The user receives a commit successful message (the exact wording of this message varies from tool to tool)

19 If the user issues a rollback instead of a commit, the old versions of the values changed are restored back to the Oracle data blocks from the rollback segment Oracle also writes to the redo buffer cache an entry indicating that a rollback was performed

Summary

In this chapter, I covered the major parts of the Oracle architecture—the architecture used by all the tools and commands Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

against the database Even though familiarity with the intricate workings of the architecture is not necessary for you to use the database and tools, it provides valuable background information in helping to work out why the database is not functioning as it should Knowledge of the architecture also lends more meaning to some of the more cryptic error and information messages.

Previous

Page TOC

Next Page Home

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

Previous

Page TOC

Next Page Home

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

Previous

Page TOC

Next Page Home

■ The DECODE Statement

■ INSERTs, UPDATEs, and DELETEs

Because SQL is a non-procedural language, sets of records can be manipulated instead of one record at a time The syntax is free-flowing, enabling you to concentrate on the data presentation Oracle has two optimizers (cost- and rule-based) that will parse the syntax and format it into an efficient statement before the database engine receives it for processing The database administrator (DBA) determines which optimizer is in effect for each database instance

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

SQL—The Standard

The American National Standards Institute (ANSI) has declared SQL as the standard language for relational database management systems Most companies that produce relational database management systems support SQL and tend to comply with the ANSI SQL89 standard

The NUMBER data type is used to store zero, negative, positive, fixed, and floating point numbers with up to 38 digits

of precision Numbers range between 1.0x10 -130 and 1.0x10 126

Numbers can be defined in one of three ways:

NUMBER(p,s)

where p is the precision up to 38 digits and s is the scale (number of digits to the right of the decimal point) The scale

can range between -84 to 127

NUMBER (p)

This is a fixed-point number with a scale of zero and a precision of p

NUMBER

This is a floating-point number with a precision of 38

The following table shows how Oracle stores different scales and precisions:

Actual Data Defined as Stored as

You can easily retrieve the current date and time by using the function SYSDATE

Date arithmetic is possible using number constants or other dates Only addition and subtraction are supported For example, SYSDATE + 7 will return one week from today

Every database system has a default date format that is defined by the initialization parameter NLS_DATE_FORMAT This parameter is usually set to DD-MON-YY, where DD is the day of the month (the first day of the month is 01), MON is the abbreviated month name, and YY is a two-digit year designation

If you do not specify a time, the default time is 12:00:00 a.m If only the time component is captured, the default date will be the first day of the current month

Character

There are four character types available:

1 The CHAR data type is used where fixed-length fields are necessary Any length up to 255 characters can be specified The default length is 1 When data is entered, any space left over will be filled with blanks All alpha-numeric characters are allowed

2 The VARCHAR2 is used for variable-length fields A length component must be supplied when you use this data type The maximum length is 2000 characters All alpha-numeric characters are allowed

3 The LONG data type is used to store large amounts of variable-length text Any length up to 2 GB can be specified Be aware that there are some restrictions to using this data type, such as:

Only one column per table can be defined as LONG

A LONG column cannot be indexed

A LONG column cannot be passed as an argument to a procedure

A function cannot be used to return a LONG column

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

A LONG column cannot be used in where, order by, group by, or connect by clauses

4 4 The VARCHAR data type is synonymous with VARCHAR2 Oracle Corporation is reserving this for future use Do not use this data type

MLSLABEL is a data type used to store the binary format of a label used on a secure operating system

The CREATE Statement

The CREATE statement opens the world to the user Whether a simple temporary table is to be created or a complex database schema, you will repeatedly use the CREATE statement Only a few of the more common CREATE statements are covered here

ENABLE clause DISABLE clause AS subquery

In this syntax, SCHEMA is an optional parameter to identify which database schema to place this table in The default is your own

TABLE is mandatory and is the name of your table

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

COLUMN DATATYPE are required to identify each column in the table Separate the columns with commas There is a maximum of 254 columns per table

The DEFAULT expression is optional and is used to assign a default value to a column when a subsequent insert

statement fails to assign a value

COLUMN CONSTRAINT is optional It is used to define an integrity constraint such as not null

TABLE CONSTRAINT is optional and is used to define an integrity constraint as part of the table, such as the primary key

PCTFREE is optional but has a default of 10 This indicates that 10 percent for each data block will be reserved for future updates to the table's rows Integers from 1 to 99 are allowed

PCTUSED is optional but has a default of 40 This indicates the minimum percentage of space used that Oracle

maintains before a data block becomes a candidate for row insertion Integers from 1 to 99 are allowed The sum of PCTFREE and PCTUSED must be less than 100

INITRANS is optional but has a default of 1 Integers from 1 to 255 are allowed It is recommended that you leave this alone This is an allocation of the number of transaction entries assigned within the data block for the table

MAXTRANS is optional but has a default that is a function of the data block size This is used to identify the maximum number of concurrent transactions that can update a data block for your table It is recommended that this parameter not

be changed

TABLESPACE is optional but has a default value as the tablespace name of the owner of the schema A different tablespace name than the default can be used Tablespace names are usually application-dependent The DBA will be able to give proper recommendations

STORAGE is optional and has default characteristics defined by the DBA

CLUSTER is optional and specifies that a table is to be part of a cluster You must identify the columns from the table that need to be clustered Typically, the cluster columns are columns that comprise the primary key

ENABLE is optional and turns on an integrity constraint

DISABLE is optional and turns off an integrity constraint

AS SUBQUERY is optional and inserts the rows returned by the subquery into the table upon creation

Once the table is created, you can use the ALTER TABLE command to make alterations to the table To modify an integrity constraint, DROP the constraint first, and then re-create it

Let's look at two examples on creating tables:

CREATE TABLE ADDRESSES (ADRS_ID NUMBER(6),

ACTIVE_DATE DATE,

BOX_NUMBER NUMBER(6),

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

This is the simplest form of a table create using all of the default capabilities The second example follows:

CREATE TABLE ADDRESSES (ADRS_ID NUMBER(6) CONSTRAINT PK_ADRS PRIMARY KEY,

ACTIVE_DATE DATE DEFAULT SYSDATE,

BOX_NUMBER NUMBER(6) DEFAULT NULL,

ADDRS_1 VARCHAR2(40) NOT NULL,

ADDRS_2 VARCHAR2(40) DEFAULT NULL,

CITY VARCHAR2(40) DEFAULT NULL,

STATE VARCHAR2(2) DEFAULT 'NY',

command The DBA is responsible for administering these privileges The syntax to create an index is

CREATE INDEX schema.index ON schema.table (COLUMN ASC/DESC)

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

CLUSTER schema.cluster INITRANS x MAXTRANS x TABLESPACE name STORAGE clause PCTFREE x NOSORT

In this syntax, SCHEMA is an optional parameter to identify which database schema to place this table in The default is your own

INDEX is mandatory and is the name of the index

ON is a mandatory reserved word

TABLE is a mandatory table name upon which the index will be built

COLUMN is the column name to be indexed If there is more than one column, make sure they are in order of priority

ASC/DESC are optional parameters Indexes are built in ascending order by default Use DESC for descending order

CLUSTER is needed only if this index is for a cluster

INITRANS is optional but has a default of 1 Integers from 1 to 255 are allowed It is recommended that this parameter not be changed This is an allocation of the number of transaction entries assigned within the data block for the index

MAXTRANS is optional but has a default that is a function of the data block size It is used to identify the maximum number of concurrent transactions that can update a data block for the index It is recommended that this parameter not

be changed

TABLESPACE is optional but has a default value as the tablespace name of the owner of the schema A different tablespace name than the default might be needed The DBA will be able to give some recommendations

STORAGE is optional and has default characteristics defined by the DBA

PCTFREE is optional but has a default of 10 This indicates that 10 percent for each data block will be reserved for future updates to the index Integers from 1 to 99 are allowed

NOSORT is an optional parameter that will save time when creating the index if the table data is already stored in ascending order This cannot be used if a clustered index is being created

Using the addresses table defined from the create table example, two indexes will be created in the next example

CREATE INDEX x_adrs_id ON ADDRESSES (ADRS_ID);

This will create an index on the adrs_id column only

CREATE INDEX x_city_state ON ADDRESSES (CITY,STATE)

TABLESPACE application_indexes;

This index has two columns; CITY is the primary column In order for queries to use an index, the column names must

be part of the select statement If a select statement included STATE but not CITY, the index would not be used

However, if the select statement contained a reference to CITY but not STATE, part of the index would be used because CITY is the first column of the index

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

Sequences

Sequences are a great way to have the database automatically generate unique integer primary keys The CREATE SEQUENCE system privilege is needed to execute this command The DBA is responsible for administering these privileges The syntax to create a sequence is

CREATE SEQUENCE schema.name

NAME is mandatory because it is the name of the sequence

INCREMENT BY is optional The default is one Zero is not allowed If a negative integer is specified, the sequence will descend in order A positive integer will make the sequence ascend (the default)

START WITH is an optional integer that enables the sequence to begin anywhere

MAXVALUE is an optional integer that places a limit on the sequence

NOMAXVALUE is optional It causes the maximum ascending limit to be 10 27 and -1 for descending sequences This

is the default

MINVALUE is an optional integer that determines the minimum a sequence can be

NOMINVALUE is optional It causes the minimum ascending limit to be 1 and -(10 26) for descending sequences This

is the default

CYCLE is an option that enables the sequence to continue even when the maximum has been reached If the maximum

is reached, the next sequence that will be generated is whatever the minimum value is

NOCYCLE is an option that does not enable the sequence to generate values beyond the defined maximum or minimum This is the default

CACHE is an option that enables sequence numbers to be preallocated that will be stored in memory for faster access The minimum value is 2

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

NOCACHE is an option that will not enable the preallocation of sequence numbers

ORDER is an option that ensures the sequence numbers are generated in order of request

NOORDER is an option that does not ensure that sequence numbers are generated in the order they are requested

If you want to create a sequence for your adrs_id column in the ADDRESSES table, it could look like the following example:

CREATE SEQUENCE adrs_seq

INCREMENT BY 5

START WITH 100;

To generate a new sequence number, use the pseudocolumn NEXTVAL This needs to be preceded with your sequence name For example, adrs_seq.nextval would return 100 for the first access and 105 for the second If determining the current sequence number is necessary, use CURRVAL Therefore, adrs_seq.currval will return the current value of the sequence

Other Objects

The purpose of this chapter is not to elaborate on every SQL statement The ones given have been covered to give an overview of the more common create statements Listed next is an alphabetical list of all objects that can be created with the CREATE statement

CREATE xxx, where xxx is one of the following:

WHERE conditions are met

GROUP BY selected columns

SELECT city, state

FROM addresses;

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

When this code run, every city and state will be retrieved from the table If 30 people lived in Rochester, NY, the data would be displayed 30 times To see only one occurrence for each city and state use the DISTINCT qualifier, as shown

in the following example:

SELECT DISTINCT city, state

FROM addresses;

This will cause only one row to be retrieved for entries with Rochester, NY

The FROM clause is a listing of all tables needed for the query You can use table aliases to help simplify queries, as shown in the following example:

SELECT adrs.city, adrs.state

FROM addresses adrs;

In this example, the alias adrs has been given to the table addresses The alias will be used to differentiate columns with the same name from different tables

The WHERE clause is used to list the criteria necessary to restrict the output from the query or to join tables in the FROM clause See the following example

SELECT DISTINCT city, state

FROM addresses

WHERE state in ('CA','NY','CT')

AND city is NOT NULL;

This example will retrieve cities and states that are in the states of California, New York, and Connecticut The check for NOT NULL cities will not bring data back if the city field was not filled in

The GROUP BY clause tells Oracle how to group the records together when certain functions are used

SELECT dept_no, SUM(emp_salary)

Name Type Syntax Returns

CHARTOROWID Conversion CHARTOROWID(c) Converts character to rowid data type

dest_c [,source_c])

string a from one character set to another The source source_c to the destination character set dest_c

COUNT Group COUNT(DISTINCT|ALL e) Number of rows in a query ALL is default e can

be represented as * to indicate all columns

GREATEST Other GREATEST(e [,e] ) The greatest of the list of expressions e.

HEXTORAW Conversion HEXTORAW(c) Converts hexadecimal character c to raw

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

INITCAP Character INITCAP(c) c with the first letter of each word in uppercase.

(1, 2 [, n [, m]]) nth character for mth occurrence of 2 and returns

the position of the occurrence

INSTRB Character INSTRB(1,2[,n[,m]]) Same as INSTR except numeric parameters are

in terms of bytes

LEAST Other LEAST(e [,e] ) The least of the list of expressions e.

LENGTH Character LENGTH(c) Number of characters in c If c is a fixed-length

data type (char), all trailing blanks are included

Character 1 left padded to length of n If

character 2 is not omitted, use as a pattern instead of blanks

Removed characters from the left of c If set s

defined, remove initial characters up to the first character not in set

MONTHS_BETWEEN Date MONTHS_BETWEEN(a,b) Number of days between dates a and b.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

NEW_TIME Date NEW_TIME(a, z1, z2) Date and time in time zone z2 when date and

time in time zone z1 are a).

NEXT_DAY Date NEXT_DAY(a, c) Date of first weekday identified by c that is later

than date a.

NLSSORT Character NLSSORT((c [,parm]) String of bytes to sort c.

(c [,parm])

letter of each word in uppercase parm has the

form of NLS_SORT = s where s is a linguistic

sort or binary

NLS_LOWER Character NLS_LOWER(c [,parm]) c with all letters lowercase See parm above.

NLS_UPPER Character NLS_UPPER(c [,parm]) c with all letters uppercase See parm above.

NVL Other NVL(e1, e2) If e1 is null, returns e2 If e1 is not null, returns

e1.

RAWTOHEX Conversion RAWTOHEX(raw) Converts raw value to its hexadecimal equivalent

REPLACE Character REPLACE(c, s1 [, r2])

Replace each occurrence of string s1 in c with r2

If r2 is omitted then all occurrences of s1 are

removed

ROUND Date ROUND(n [,f]) Date rounded to format model f If f is omitted, n

will be rounded to nearest day

ROUND Number ROUND(n[,m]) n rounded to m places right of decimal point If

m is omitted, to 0 places.

ROWIDTOCHAR Conversion ROWIDTOCHAR(rowid) Converts rowid to varchar2 format with length of

18

RPAD Character RPAD(1, n [, 2]) 1 right-padded to length of n with 2.

RTRIM Character RTRIM(c [, s]) c with characters removed after last character not

in set s If s is omitted, set defaulted to ''.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.