What happens when I add a VDB to a Self-Service Container?
When a VDB is first added to a Container, it will be refreshed to the latest point in time on the parent object. This allows Self-Service to begin tracking the VDB from a known point and keep accounting for future changes. As of 5.1.6, it is possible to add an existing VDB to a container without the refresh.
Why is the initial Refresh so long when adding a VDB to a container?
The initial Refresh is always from the latest Point-in-Time on the respective sources. If it's been a while since a snapshot has taken, it can take a significant amount of time to apply the necessary archive logs for Oracle sources. You can reduce the time this takes by taking a new Snapshot of the source prior to creating Containers.
How do I figure out why a Self-Service operation failed?
Self-Service operations will result in jobs and actions just like operations performed in the Admin App. Just like any other VDB operation, you should be able to see the underlying failure in the Actions pane or the Dashboard.
How do I figure which object caused the Self-Service job to fail when I have a lot of objects in each Container.
You’ll need to either focus on the failed jobs in the Action pane, or look at all of the jobs in the Dashboard that occur after the start time of the parent Self-Service job and before the end time. If you have a lot of activity on the Delphix Engine, you may need to figure out which VDBs are associated with the Container to be able to decipher which jobs are associated. Remember, a failure on any of the objects in the Container will cause the operation on the Container to fail.
My user reports that their Container shows Attempt Recovery what should I do?
This is an indication that a persistent failure has occurred during an operation. For example: a Refresh they performed failed and Self-Service couldn’t revert back to the previous state either. Generally, this is indicative of an environmental problem since the automated recovery didn’t work. Possible sources of the issue could be listener issues, authentication failure, target environment problems, etc and to resolve look into those areas and errors found in the Admin App. In particular, looking through the Dashboard for Failed jobs can help quickly isolate the issue.
I see snapshots that are being held beyond the retention period since we started using Self-Service. What is causing this?
There are a couple of reasons that this could happen.
1. Since Self-Service allows users to create Bookmarks and those Bookmarks are held until deleted, they could be keep open references to those snapshots. Even if the Bookmarks have been deleted, if a user has branched or restored from that point, they may still be holding a reference to the underlying data.
2. The other common way for this to occur is via Branches. Self-Service will perform retention on data associated with Branches but will not remove the Branch through retention. If the user has a Branch that hasn’t been refreshed in a while, it may be holding references to older data causing Snapshots to be held.
Having users be cognizant of the resources they're using, and encouraging them to remove unneeded bookmarks as well as removing or regularly refreshing branches, can help avoid many problems.
Why is the Trash button not available on a Template?
In order to delete the Template, you’ll need to ensure that all of the Containers derived from the Template have been deleted.
Why is the Trash button not available on the Container?
In versions of Delphix prior to 4.3.3, Containers that needed recovery could not be deleted from the UI. To delete the container, you’ll need to log into the CLI and perform the following steps:
ssh -l delphix_admin@DOMAIN delphix delphix> jetstream delphix jetstream> container delphix jetstream container> delphix jetstream container> select CONTAINER-1 delphix jetstream container 'CONTAINER-1'> delete delphix jetstream container 'CONTAINER-1' delete *> ls delphix jetstream container CONTAINER-1 delete *> set deleteDataSources=false/true delphix jetstream container 'CONTAINER-1' delete *> commit Dispatched job JOB-7327 JETSTREAM_USER_CONTAINER_DELETE job started for "CONTAINER-1". JETSTREAM_USER_CONTAINER_DELETE job for "CONTAINER-1" completed successfully. delphix jetstream container>