Contenu connexe Similaire à Snapmirror Design (20) Snapmirror Design2. Current BI Architect for Database
refreshes
2 2
Archive Log Archive Log
Production
1 1
RMAN RMAN
To build DG To build DG
1
Standby NEO
1 EDW
NEO 3 Standby
Vol
DMS
EDW Clone 3
DMS
Vol Clone
2 3 4 5 6 7
2 3 4 5 6 7
8 9 10 11
8 9 10 11
12
10g
12
10g
Development
QA / Staging
© 2008 NetApp. All rights reserved. NetApp Confidential - Limited Use 2
3. DB Refresh Pain Points
Storage Allocated for Dev / STG /QA are not big
enough to accommodate 8 set of production database.
To Accommodate 8 set of prod environment we have
to follow RMAN backup and restore which is taking
more then 10 days to refresh, Impacting SLA. (Using
DataGaurd technology to keep database in sync)
Have to do refresh standby database after every
month-end or quarter-end (due to no logging), many
groups have to involved to get this done and taking
everyone time.
RMAN backup impacts production database
performance.
Existing Solution is not scalable.
It is impacting development, QA and UAT cycle.
© 2008 NetApp. All rights reserved. NetApp Confidential - Limited Use 3
5. Example of NetApp Snapshot Technology in
Action
The following figures assume that the file system is writing a file
that consists of the blocks A, B, C, and D.
The live file system writes the blocks A, B, C, and D to
disk and locates them with pointers.
© 2008 NetApp. All rights reserved. NetApp Confidential - Limited Use 5
6. A Snapshot is taken – no data is read, written, or copied to
disk, the Snapshot simply points to the current locations.
© 2008 NetApp. All rights reserved. NetApp Confidential - Limited Use 6
7. The live file system modifies block C, and writes C’ to
disk – there is no change to block C. The live file system
points to C’ instead of C. The Snapshot still points to
block C, which is unchanged.
© 2008 NetApp. All rights reserved. NetApp Confidential - Limited Use 7
8. As more changes are made to the file system, it is clear
that the Snapshots are still able to recreate the file as it
was at the time they were taken.
© 2008 NetApp. All rights reserved. NetApp Confidential - Limited Use 8
10. FlexVol Clone
Virtual Volumes (Do not consume any space)
DB Assigned to Project-1
Vol
DB VOL
Clone As Database
VOL Changes
Snap-S1 LUN
LUN FS
FS
Sn
ap
Assigned to Project-2
-
DB
S2
VOL As Database
Changes
LUN
FS
© 2008 NetApp. All rights reserved. NetApp Confidential - Limited Use 10
11. BI Database Refresh Architect
PFINDM Pcentric
PSLSDM PEDW Production
PCSDM PRPNET8
PCUSTIN
sacprodflr 05 sacprodflr 06 sacprodflr 11 sacprodflr 12
PFINDM Pcentric
SnapMirror PSLSDM PEDW
Backup Filers
PCSDM PRPNET8
PCUSTIN
Backup Filers
Dev / STG /QA
SnapMirror PFINDM Pcentric PFINDM Pcentric PFINDM Pcentric
PSLSDM PEDW PSLSDM PEDW PSLSDM PEDW
PCSDM PRPNET8 PCSDM PRPNET8 PCSDM PRPNET8
PCUSTIN PCUSTIN PCUSTIN
svldevflr 09 svldevflr 10 svldevflr 11 svldevflr 12 Clone Clone
© 2008 NetApp. All rights reserved. NetApp Confidential - Limited Use 11
12. Solution
Using FlexVol Clone we can create many
private copy of database using single physical
copy of database.
We do not have to manage / refresh standby
databases after each quarter-end or month-
end.
Dev /QA /UAT databases are not impacted by
no logging operation on primary database
(POROD).
It consumes much lesser storage.
NetApp on NetApp.
No additional investment is required.
© 2008 NetApp. All rights reserved. NetApp Confidential - Limited Use 12
13. Limitations
Cloned Database instance should not changed
data more then 20-30% of total size.
We have to keep refreshing databases
frequenctly (minimum once in a quarter).
© 2008 NetApp. All rights reserved. NetApp Confidential - Limited Use 13