Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Snapshotting Oracle Database
- Scope
- Not about CPU contention because there’s no much to do here on single host
- It ill...
Traditional way
Prod
Dev1
dev1
Dev2
dev2
qa1
qa1
qa2
qa2
Rman duplicate
Or restore
- Features:
- clone of entire DB, one D...
CloneDB, which saves storage
Prod
dev
1
Dev2 qa
1
qa1
qa
2
qa2
Rman duplicate or database restore.
Same as before, but put...
Pluggable DB, which saves memory
cdb dev1
dev2
qa1
qa2
One instance
-- One instance means less memory
pressure
-- Creation...
When a certain state is reached, guaranteed restore point can be created, when it is required later, database can be rewou...
Upcoming SlideShare
Loading in …5
×

Snapshotting Oracle Database

318 views

Published on

different ways to clone/snapshot an Oracle Database

Published in: Data & Analytics
  • Be the first to comment

  • Be the first to like this

Snapshotting Oracle Database

  1. 1. Snapshotting Oracle Database - Scope - Not about CPU contention because there’s no much to do here on single host - It illustrates conceptually how database is cloned in various ways - It discusses how to use different clone strategy for different scenarios - When talking about snapshot, it means a database state in the past. The technologies discussed here can all bring database to a point in time in the past Andrewmasj@gmail.com
  2. 2. Traditional way Prod Dev1 dev1 Dev2 dev2 qa1 qa1 qa2 qa2 Rman duplicate Or restore - Features: - clone of entire DB, one DB one instance. - Traditional database backup and restore is used - Traditional rman duplicate is used - Dev1 is snapshot of prod, qa1 can be further snapshot of dev1, etc - Pros: reused script. it works. Easy to maintain - Cons: contention on memory and storage. Time consuming when DB is big
  3. 3. CloneDB, which saves storage Prod dev 1 Dev2 qa 1 qa1 qa 2 qa2 Rman duplicate or database restore. Same as before, but putting to NFS server NFS QA NFS Server with plenty of cheap storage Same clone process as before In this approach, DBs with existing clone method co-exists with DBs done by CloneDB, which serves purpose to -- have a same start point, then grow themselves individually -- reduce storage contention on main host -- can have many “snapshots” on cheap storage and build them Up on main host with less cost Limits -- once base database is destroyed, all depending cloneDBs will also be destroyed -- not good for performance testing dev dev 1 dev n dev n dev 2
  4. 4. Pluggable DB, which saves memory cdb dev1 dev2 qa1 qa2 One instance -- One instance means less memory pressure -- Creation of new PDB can be easily achieved as clone of existing PDB
  5. 5. When a certain state is reached, guaranteed restore point can be created, when it is required later, database can be rewound back to guaranteed restore point quickly. Good thing in Oracle’s flashback database feature is you can rewind back to any guaranteed restore point without having to concern rewinding back to earlier point would override later points. For example, rewinding back to GP2 and making some changes won’t hurt the ability to later rewind back to GP3 or GP4. Taking QA testing as an example, after major state has been achieved, under DBA’s help, guaranteed restore point is created as a snapshot of that state. QA can continue their testing and create more restore points along the way. When they have to fork out on same set of data or same state of database, they can create a restore point and then go to the first test condition, it is GP2 in the illustration. Along the testing, GP3 and GP4 can be created. After one condition is tested, database can be rewound back to GP2 and QA can start testing on another condition based on exactly same set of data or state of database. In each of branched testing, restore points can be created and database can be easily restored to any of them, even they are in different branches. For instance, while as branch 2, it can be restored to GP3 or GP4 that are in branch 1, later it can be further restored to Gp5 or GP6 after being restored to GP3 or GP4. One of benefit of this solution is that only one database and instance are required. One of drawback is it can be only in one of the state at a time, you can not parallel checking and comparing data between different states. CloneDB is under consideration should you want to simultaneously have environments starting from same point. GP1 GP2 GP3 GP4 GP5 GP6 fork Branch 1 Branch 2 Rewind back to GP2 Having another path from GP2 Flashback database, a smart way to have “snapshots” of database It saves both on Memory and Storage and it is easiest to setup and maintain

×