Subscribe to Blog via Email
How many times have you had a developer come to you and say, “I just did a bad thing in the database. Can you recover from what I just did?”
With Delphix virtualization, we make this pretty easy to address from the user interface with a simple slider to recover from a PIT before the catastrophic mistake, but today, we’ll discuss how to do this from the command line
1.Log into the Delphix engine as an admin user.
ssh delphix_admin@<yourengine> delphix > timeflow delphix timeflow > ls
2. Depending on the platform that you’re using, (in our example, we’ll use Oracle) you’ll see the list of the databases available and can choose the one that you want to refresh before the catastrophic incident from the clueless developer
delphix database> select [VDB name]
3. We can do a simple rollback if we just want to go back to the last snapshot or we can use an list command to see more options:
delphix database "[VDB Name]"> rollback
delphix database "[VDB Name]" rollback *> ls Properties type: OracleRollbackParameters credential: (unset) timeflowPointParameters: type: TimeflowPointSemantic container: (required) location: LATEST_POINT username: (unset)
4. So we’ve decided to do a PIT recovery after the mistake and use the following command and then commit the changes:
delphix database "[VDB Name]" rollback *> set timeflowPointParameters.location=82439
delphix database "[VDB Name" rollback *> commit
That’s all there is to it.
So what if the developer is incompetent and screws up repeatedly?
Follow steps 1-4 above and then to purge the problem from the environment, run the following command from the delphix engine:
delphix database developer [developer employee ID] remove *> commit
An eject button we’ve installed in the delphix engine will remove the developer from the premises and Delphix will even submit all necessary paperwork to Human Resources to complete his termination processing.
If you’d like to automate the process, you can create a handy script that simply asks for the following parameters by calling it from any shell, Powershell for windows or even Jenkins as part of DevOps!
Happy April 1st!
Since the introduction of Enterprise Manager 12c, folks have been asking for a list of best practices. I know a lot of you have been waiting for this post!
1.Use previously deployed, older hardware for your Enterprise Manager deployment on 13c.
Enterprise Manager is a simple, single service system. There is no need for adequate resources and ability to scale. In fact, I’ll soon be posting on my blog about building an EM13c on a Raspberry Pi 3.
2. Please feel free to add new schemas, objects and ETL’s to the Oracle Management Repository, (OMR.)
This database doesn’t have enough to do with metric collections, data rollup, plugin, metric extensions and notifications.
3. Turn on the standard statistics jobs and baseline collection jobs on the OMR.
The OMR has its own version of the stats job, but running two jobs should make it run even better and even though baselines aren’t used, why not collect them, just in case?
4. Set the EM13c to autostart, but set the listener to stay down.
The Oracle Management Service, (OMS) shouldn’t require the listener to connect to the OMR when starting, after all.
5. If there is a lot of garbage collection, just add more memory to the java heap.
If we give it more memory, then it will have less to clean up, right? More is better and there isn’t any way to find out what it should be set to anyway.
6. If you want to use the AWR Warehouse, you should use the OMR database for the AWR repository, too.
It shouldn’t make a difference to network traffic, datapump loading or resource workloads if they share a box. These two databases should work flawlessly on the same hardware, not to worry about network traffic, etc.
7. If you have a lot of backlog for job processing on your EM13c, you should trim down the worker threads.
Serializing jobs always speeds up the loading of data.
8. Sizing an Enterprise Manager EM13c is a simple mathematical process, which I’ve displayed below:
(If I didn’t mention it earlier, there will be a quiz at the end of this post…)
9. Never apply patches to the Enterprise Manager tiers or agents.
Each release is pristine and bugs don’t exist. It will only require more work in the way of applying these patches and downtime to your EM13c environment.
10. Patch any host, database or agent monitored by the Enterprise Manager manually.
Patch plans and automation of patching and provisioning is a terrible idea and the only way a DBA can assure if something is done right is if they do it manually themselves. Who needs a good night’s sleep anyway?