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. |