DBA Tips Archive for Oracle
No Title[an error occurred while processing this directive]
by Michael New, MichaelNew@earthlink.net, Gradation LLC
Any experienced DBA knows that the Oracle database management system, has some of the greatest support for concurrency and consistency across multiple transactions. In a typical transaction, Oracle will lock the row(s) being updated until either the transaction is committed or rolled back. For most applications, this is more than adequate, especially for databases with short-duration transactions or long-running transactions executed by a limited amount of users that are totally independent of the activity in other user sessions.
But consider a database where the DBA must support long-running transactions that could take hours or even days to complete. Oracle's standard transaction integrity techniques might prove insufficient. In these situations, all user sessions will have to ensure an unacceptable long wait for a lock on a row to be released by another user session. Furthermore, it is next to impossible to keep a domain of data that you are analyzing constantly, while other user sessions are performing DML operations that change this domain of data.
New with version 9i, Oracle introduces the idea of a "virtual workspace" called the Workspace Manager. Within this virtual workspace, the user session is able to have a domain of data that is constant, even though other user changes may be altering the data within this domain. Furthermore, the Workspace Manager enables the user session to return to this domain of data at a future point in time.
A workspace can be thought of as a virtual database facility that enables the user to maintain multiple versions of one row of data and it enables each workspace context to reference a different version of this row as compared to another workspace context. Basically, the workspace context enables the user to work with one version of the database in one workspace context, and with another version of the database in another workspace context, without compromising transactional integrity across the database.
It is possible for the user to perform data analysis with one version in one workspace context, while a large DML transaction runs in another context. The user has total availability to his data, even throughout the operation of the DML transaction. Once the transaction has committed, the user can merge the changed data with the original table. Workspace management enables users to manage one or more such workspaces.
The Workspace Manager enables users to version-enable a table, which enables them to maintain multiple versions of a row in that table. The table is the fundamental until for the Workspace Manager. When changes are made to a row in a regular table, the data is overwritten. When changes to a row are made on a version-enabled table, Oracle creates and maintains a new version of that row. Version-enabling a table can consume a large amount of storage space because the database has to maintain multiple versions of a row.
Installing Workspace Manager is fairly straightforward. If the database was created with the Database Configuration Assistant (DBCA), then Workspace Manager will automatically be installed. When you manually create a database using your own scripts, you must install the Workspace Manager by connecting to the database as the SYS user and running the script: ORACLE_HOME/rdbms/admin/owminst.plb.
It is worth mentioning what is involved when Workspace Manager is installed. The script first creates a user called WMSYS that will be used to hold all Workspace Manager objects (Packages, Views, etc.). The default password for WMSYS is WMSYS, but the account is locked when it gets created. (There is really no need to unlock and login to this account.). The WMSYS user will be assigned the following roles:
Users should use the package DBMS_WS (introduced in Oracle9i) to create and manage workspaces. The steps to effecting workspaces are as follows:
Throughout this short example, we will assume that we have a table called ORDERS with the following structure. Make sure to make the ID column the primary key of the table.
Use the ENABLEVERSIONING subprogram in the DBMS_WM package to version-enable this table.
By default, the DBA role has been granted the WM_ADMIN_ROLE role to execute procedures in the DBMS_WM package. Optionally, you can provide a second parameter to specify the version of the table that you want to maintain. When you version-enable a table, Oracle changes the table name by adding a suffix, _LT. Oracle also creates additional tables, views, triggers, and indexes to track the different versions of rows. For example, Oracle creates a new table to maintain information about rows that are synchronized after it resolves conflicts. Oracle generates the name of this table by taking the original name of the version-enabled table and adding a suffix, _AUX. In our example, the name of the table will be ORDER_AUX.
The versioning of tables is subject to the following restrictions:
Use the CREATEWORKSPACE procedure to create a workspace. Oracle creates this workspace in a tree hierarchy under the current workspace. By default, Oracle will create this workspace within the LIVE workspace.
You can identify the current workspace with the following query:
Any workspace you create will become a child workspace of this LIVE workspace. Now connect to the database has a user that has the WM_ADMIN_ROLE to run the following statement:
The following considerations apply to the creation of a workspace:
The next step is to grant privileges to the users that will need to access this workspace. For example, you can grant users or roles the privilege to access the workspace, create a workspace, remove a workspace, merge workspaces, and rollback workspaces. The following example demonstrates how you can grant the access privilege on workspace phase1_orders_ws to user JHUNTER:
Looking at the above example, the first parameter specifies the privilege(s) being granted. You must separate multiple privileges with a comma. The second parameter specifies the workspace to grant privileges on. The third parameter specifies the user/role to whom you are granting these privileges.
The default login is the LIVE workspace. You can access any workspace by invoking the GOTOWORKSPACE procedure, as show below:
You can perform queries and DMLs on the ORDERS table just as you would with a regular table. Workspace management is transparent to the user.
Modifications that you perform in this workspace WILL NOT be available to other user sessions until the workspace is merged with its parent. Oracle accomplishes this by maintaining different versions of the same row; you just have access to the versions that correspond to your workspace. Oracle still uses the default short-transaction-locking mechanism for the version of the row that you are updating.
Workspace Management enables you to apply additional locks on current and previous versions of the rows to eliminate conflicts between the parent and versioned records. For example, you can implement an exclusive lock to prevent users from modifying the previous versions of the rows, or you can implement a shared lock to allow users in the same workspace to share the current and previous versions of the rows. Use the SETLOCKINGON procedure from the DBMS_WM package to specify the session-level locking method, the SETWORKSPACELOCKINGMODEON to specify the row-level locking method, and the LOCKROWS method to specify access to parent and versioned rows.
You can freeze a workspace to disallow changes to rows in the version-enabled tables:
You can reverse this process as follows:
The DBMS_WM package also provides procedures for performing other operations. For example, the CREATESAVEPOINT procedure enables you to create savepoints in the current workspace, the ROLLBACKTOSP procedure enables you to roll back changes to a particular savepoint in the workspace, and ROLLBACKTABLE enables you to roll back changes on a single table.
The concept of savepoints in workspaces is very similar to that of normal transactional savepoints, but some differences exist. For example, although workspace-managed savepoints do not consume space, modifications to rows after the savepoint creation results in a new version of the row. Also, Oracle creates explicit savepoints to facilitate partial rollbacks in workspaces, and Oracle creates implicit savepoints when you create a new workspace.
When one row is modified in two or more workspaces, you will have more than two versions besides the original row, and these rows are in conflict since you have to decide which change will prevail. You must resolve these conflicts before you can refresh workspaces (apply changes from the parent workspace to the child) or merge workspaces (apply changes made in the child workspace to its parent). Oracle will raise an error if you attempt to either merge or refresh different versions of data where conflicts exist.
As you can see from the above conflict, we need to query the ORDERS_CONF view to see the actual conflicts. We can see that there is a row in both the parent workspace (LIVE) and the child workspace (phase1_orders_ws) that conflict. Remember that the ID is the primary key of the table and needs to be unique.
The query results show the BASE (or original) values before the data was modified in any of the workspaces. The rows with the workspaces named LIVE and phase1_orders_ws display the data rows modified in these workspaces that are in conflict with each other. This query also displays the modified data.
You must resolve these conflicts manually with the RESOLVECONFLICTS procedure before you can either refresh the child version data from the parent version data or merge the child version of the data with the parent. Here is an example for resolving the above conflict.
The first line prepares the environment for conflict resolution, the second command performs conflict resolution, the third command commits pending short-term transactions, and the fourth statement commits the changes as a result of the resolved conflicts.
Now that the conflicts have been resolved, the following query confirms this fact:
Now that you have resolved data conflicts, you can either merge or refresh the different versions of data. You are refreshing the workspace when you copy the parent workspace to the child workspace. You must resolve conflicts prior to refreshing or merging.
You can invoke the REFRESHWORKSPACE procedure to refresh all the data and REFRESHTABLE to refresh data for a single table. You cannot refresh the LIVE workspace; it is the topmost workspace in the hierarchy and does not have a parent workspace to refresh from.
Merging is done when you apply modifications from the child workspace to the parent workspace. Again, you must resolve conflicts before merging. You can invoke MERGEWORKSPACE to merge all data or invoke MERGETABLE to merge just one table:
The previous command merges the changes in the phase1_orders_ws workspace to its parent workspace, which is the LIVE workspace in our example. The MERGEWORKSPACE procedure has two optional parameters: one to specify whether a savepoint has to be created in the parent workspace before merging and one to specify if the workspace should be removed after the merge. Because we did not specify the optional parameters in our example, the database does not create any savepoint in the LIVE workspace before the merge, and it does not remove the workspace after the merge.
Once you have completed your versioned operations; you must disable the versioning of the tables to minimize the possibility of creating unnecessary rows. This action also gets rid of the overhead of maintaining additional indexes, views, and triggers. You invoke the DISABLEVERSIONING procedure to perform this action, as shown below:
You either must be the owner of the table or a user with the WM_ADMIN_ROLE role to perform this task. This command will fail if you have modified data in the table. If you want to execute this command regardless, you must specify that you want to FORCE it by providing the second argument, which is an option argument. If the FORCE parameter is TRUE, it will force changes to be discarded in the child workspace table before disabling versioning for the table. This action does not remove either the workspace hierarchy or the savepoints you established.
The final step is to remove the workspace using the REMOVEWORKSPACE procedure, as shown below:
This code rolls back the data in the workspace and deletes the workspace definition from the database. You must invoke the REMOVEWORKSPACETREE procedure to remove all the workspaces in a hierarchy.
Privileges in the Workspace Manager are distinct from the regular privileges in Oracle.
You have the following workspace-level privileges:
You also have the following system-level privileges:
The Workspace Manager provides the WM_ADMIN_ROLE role that contains all the workspace-level and system-level privileges that you can grant to the user. Oracle grants the WM_ADMIN_ROLE role to the DBA role.
You can assign workspace-level privileges and system-level privileges to a user with the GRANTWORKSPACEPRIV and the GRANTSYSTEMPRIV procedures, respectively. You use the REVOKEWORKSPACEPRIV and the REVOKESYSTEMPRIV procedures to revoke privileges.
You can perform exports and imports on version-enabled databases much like the same as you would with regular databases; however, you must take the following restrictions into consideration.
Jeffrey Hunter is an Oracle Certified Professional, Java Development Certified Professional, Author, and an Oracle ACE. Jeff currently works as a Senior Database Administrator for The DBA Zone, Inc. located in Pittsburgh, Pennsylvania. His work includes advanced performance tuning, Java and PL/SQL programming, developing high availability solutions, capacity planning, database security, and physical / logical database design in a UNIX / Linux server environment. Jeff's other interests include mathematical encryption theory, tutoring advanced mathematics, programming language processors (compilers and interpreters) in Java and C, LDAP, writing web-based database administration tools, and of course Linux. He has been a Sr. Database Administrator and Software Engineer for over 20 years and maintains his own website site at: http://www.iDevelopment.info. Jeff graduated from Stanislaus State University in Turlock, California, with a Bachelor's degree in Computer Science and Mathematics.
Copyright (c) 1998-2018 Jeffrey M. Hunter. All rights reserved.
All articles, scripts and material located at the Internet address of http://www.idevelopment.info is the copyright of Jeffrey M. Hunter and is protected under copyright laws of the United States. This document may not be hosted on any other site without my express, prior, written permission. Application to host any of the material elsewhere can be made by contacting me at firstname.lastname@example.org.
I have made every effort and taken great care in making sure that the material included on my web site is technically accurate, but I disclaim any and all responsibility for any loss, damage or destruction of data or any other property which may arise from relying on it. I will in no case be liable for any monetary damages arising from such loss, damage or destruction.
Last modified on
Saturday, 25-Feb-2012 17:47:06 EST
Page Count: 44532