Also, note the title of this slide deck by an Oracle product manager: “Long Transactions with Oracle Database Workspace Manager Feature”. You can see the remnants of this old name in the documentation – many of the document URLs start with “long”. I suspect OWM was once known (or internally referred to) as “Long Transactions” or something like that, probably because of its user workspace and merging features. for each row, the user can decide to refresh their workspace with the updated data in the parent, or they can force their workspace’s change onto the parent). If any change to a row would conflict with a change that another user made to the same row in the parent workspace, the merge stops and the user may be prompted to resolve the conflicts (i.e. the “live” workspace if that was the source). If they are happy with their changes in a workspace, they can choose to do a Merge – which attempts to effect all the inserts, updates and deletes that were made in the workspace to its parent workspace (e.g. If the user is not happy with their scenario, they can simply delete the workspace and the live data is not affected. In addition, the user can create and view savepoints and additional workspaces within a workspace – OWM maintains a hierarchy of workspaces. Similarly to savepoints, the user can get a differences report between any workspace (including the “live” workspace). Changes made by other users to the “live” workspace may, optionally, be automatically propagated into a workspace. The user can jump back and forth between the scenarios and the “live” workspace (which is the default). They can also run an API command ( dbms_wm.SetDiffVersions) to generate a differences report which shows all the inserts, updates, and deletes that have occurred since a savepoint.Īn example of using workspaces is where a user could create one or two workspaces, each representing a different scenario. One example of using savepoints is that a user could create a savepoint, make changes, go back and view the database as of the savepoint, and can rollback all changes to a savepoint. Note: the default workspace for a user session is called “ LIVE“, and the default savepoint is “ LATEST“. I haven’t tried this myself but it looks like a powerful feature. The Valid Time use case allows your users to set a date/time range on each record multiple versions of a unique row can be created with non-overlapping date ranges updates can be done within the context of a given date/time range, which will cause rows that span the boundary of the range to be split into multiple versions. The Row History use case is similar to using Flashback Query which is a more modern feature of the database however, since it can be enabled or disabled individually for each table, it may require less storage space to support querying back as far as the user would like in time.
0 Comments
Leave a Reply. |