Tài liệu Oracle Unleashed- P2 docx

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 constraints do not. If possible, use constraints for checking; they are quicker than using database triggers. System-Level Privileges Each Oracle user defined on the database can have one or more of over 80 system-level privileges. These privileges control on a very fine level the right to execute SQL commands. The database administrator assigns system privileges either directly to Oracle user accounts or to roles. The roles are then assigned to the Oracle user accounts. 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. Auditing Oracle's auditing mechanism provides three types of audit trails. One audit trail tracks which system privileges are used. Statement auditing keeps track of which SQL statements are used without regard to specific objects. Object-level auditing audits access to specific objects. You can initiate these audit trails to track when the statements succeed, when they fail, or both, so that all accesses are audited. You can use auditing to keep track of anyone attempting to break into the system. 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.) Machine Failure When the machine on which the database server is running fails and shuts down (the power is turned off, for example), the Oracle instance stops running. As long as no database files are lost, the only action required of the database administrator is restarting the Oracle instance. When you do this, the SMON background process reads the online redo log files and reapplies any changes for committed transactions. Any changes that had not been committed are rolled back. 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. Cold Backup A cold backup is when you copy the three sets of files (database files, redo logs, and control file) when the instance is shut down. This is a straight file copy, usually from the disk directly to tape. You must shut down the instance to guarantee a consistent copy. (It is possible to back up the files without bringing the instance down; see the section titled "Hot Backup.") If you only perform a cold backup, the only option available in the event of data file loss is restoring all the files from the latest backup. All work performed on the database since the last backup is lost. Archiving If you've set up the database to run in ARCHIVELOG mode (easily done by the DBA), the database changes recorded in the redo logs are archived to an archive destination whenever the redo logs fill. Using this option, you have a complete record of changes made to the database files in the offline and online redo log files. 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. Multiplexing In this part, I discuss the options available for Oracle to duplicate data to provide an extra level of protection in the event of data loss. Control Files To protect against control file loss, the Oracle RDBMS software can maintain more than one copy of the control file. You do this by making a consistent copy of the existing control file and modifying an INIT.ORA parameter. This does not significantly impact the performance of the database. If all copies of the control file are lost, you can manually recreate them using the CREATE CONTROLFILE command. 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. [...]... Additional Tips Summary 4 SQL Oracle' s SQL: An Overview Structured Query Language (SQL) was introduced by IBM as the language to interface with its prototype relational database management system, System R The first commercially available SQL relational database management system was introduced in 1979 by Oracle Corporation Today, SQL has become an industry standard, and Oracle Corporation clearly leads...Previous TOC Page q Next Page Home Part II Part II Oracle Tools and Utilities Previous TOC Page Next Page Home Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Previous TOC Page q Next Page Home 4 r SQL s s s s s s s s s Oracle' s SQL: An Overview s SQL—The Standard Data Types s Numeric s Date s Character s Binary s Others... powerful and overlooked SQL statements is the DECODE statement The DECODE statement has the following syntax: DECODE(val, exp1, exp2, exp3, exp4, , def); DECODE will first evaluate the value or expression val and then compare expression exp1 to val If val equals exp1, expression exp2 will be returned If val does not equal exp1, expression exp3 will be evaluated and returns expression exp4 if val equals exp3... FROM emp e WHERE e.emp_id in (SELECT NVL(z.manager_id, e.emp_id) FROM emp z); In this example, the DECODE statement is nested with another DECODE statement If the Oracle user is 'ADMIN', show the salaries except for the president's salary If the Oracle user is 'PRES', show all salaries and if the user is anybody else, return '******' Another place the DECODE statement can be used is in the ORDER BY clause... 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 Binary Two data types, RAW and LONGRAW, are available for storing binary type data such as digitized sound and images These... similar characteristics as the VARCHAR2 and LONG data types already mentioned Use the RAW data type to store binary data up to 2000 characters and use the LONGRAW data type to store binary data up to 2 GB Oracle only stores and retrieves binary data; no string manipulations are allowed Data is retrieved as hexadecimal character values Others Every row in the database has an address You can retrieve this... 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... 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) FROM emp GROUP BY dept_no; The GROUP BY example will list all department numbers once with the summation... Hyperbolic sine of n SOUNDEX Character SOUNDEX(c) A string with phonetic representation of c SUBSTR Character SUBSTR(c, m [,n]) A portion of c beginning at character number m for n characters If m is negative, Oracle counts backward from the end of c If n is omitted, all characters are returned to the end of c SUBSTRB Character SUBSTRB(c, m [,n]) The same as SUBSTR except m and n are number of bytes SQRT Number... www.verypdf.com to remove this watermark AND UPPER(city) = 'ROCHESTER' AND TO_NUMBER(SUBSTR(zip,1,5)) > 14525 AND NVL(active_date,SYSDATE) > TO_DATE('01-JAN-90'); Notice the use of the UPPER function When Oracle performs character string comparisons, the case (upper- and lower-) of the strings in question have to match exactly Therefore, 'Rochester' does not equal 'ROCHESTER' The UPPER function will ensure . back. A distributed transaction can involve many Oracle databases and only one non -Oracle database. The Oracle two-phase commit mechanism controls the. 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