on 12-18-2014 6:39 AM
Hi ,
We have ECC 6.0 production system, with DB2 version 10.1 as database. Its non partitioned database and has grown up to 3.5 TB whose everyday online backup size up to 1.5 GB and takes almost a day to get successful. This resource intensive backup has adverse effect on system performance. We are looking out for ways on how to compress,optimize the backup size and come across ACS and snapshot technology .
Have few points to discuss:
1) Is there any other better method to reduce db2 backup size available?
2) What are the pros and cons of using ACS/ snapshot technology?
3) ACS/snapshot technology compatibility with P series IBM servers
4) Any document/guide available for the same?
Kindly help us on the above points.
Regards,
Aditya
SAP Basis
Hi Aditya,
Table and index compression would likely be a good way to reduce conventional backup times. You should also check for and correct any severe tablespace size skew since that can reduce read parallelism as the backup progresses. Ensure that your LUNs have a queue depth much higher than the AIX default of 3, and that you have configured enough prefetchers and a reasonable degree of IO parallelism. Finally, the SAP default extent size of 32KB is IMHO bizarrely small and detrimental to backup performance in most cases. A more normal extent size of 128KB or 256KB, aligned to the RAID strip size, is better. Unfortunately this requires new tablespaces, but you can migrate online while compressing at the same time.
Also make sure that you have enough sessions if you are using TSM. I have a customer with a 4TB ECC database, compressed. They have implemented the above changes and use 3 or 4 sessions. The online backup takes about 3 hours, not that amazing but better than a day. In short, your challenge is to eliminate all IO bottlenecks 🙂
The aforementioned will improve big read performance generally. Snapshot backup is another option but too much to explain here I feel. One downside of snapshot backup is less flexibility in that you cannot restore just a single tablespace nor can you restore to different containers. However the performance advantages may far outweigh this.
Jeremy
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Jeremy,
Thanks a lot for this narrow and beautiful description on how to control the size. We checked table spaces and found BTAB data and index tables with highest size. Currently we have value 4 DB2BM edu's and value 16 prefetchers for around 30+ table spaces. So, for 30+ Containers can we place tantamount parallelism value to increase db performance? We have learnt that db2bm agent has one to one mapping with specific tablespaces and increasing their no. will not help performance. One solution is to evenly distribute db over the tablespaces using Db2 tools.Other solution which we observed is how about increasing prefetcher value as one table space can have more than one prefetcher to retrieve data...will it improve performance ?
How to check this Db2 extent size and LUN's queue length, kindly guide on this.
And we are using tapes in place of TSM, so how to go ahead with it?
Also Jeremy, We would like to know much about other options like this snapshot and ACS technology as we are on DB10.1 and If ACS technology wants us to upgrade our DB to 10.5 then we can consider it as a plus point
We want to explore max available options and ll pick the best
Kindly Guide us on above points and pls provide information/guide/doc if any on snapshot backup /ACS technology.
Thanks in advance,
Aditya
SAP Basis
Hi Aditya,
The IBM DB2 Knowledge Center would probably be the best place to start for ACS: http://www-01.ibm.com/support/knowledgecenter/#!/SSEPGG_10.1.0/com.ibm.db2.luw.admin.ha.doc/doc/c005...
There are also other, older resources such as Redbooks, that describe backup and recovery with ACS.
Note that the ACS scripted interface is available in 10.1 as of fix pack 3 if you want to integrate a non shrink-wrapped snapshot copy solution with DB2. External scripts are also possible, as before.
I'm sure that you can get a great result using snapshot backups, but be sure to prepare and above all test backup and recovery with your solution carefully. A couple of pointers:
I'm sure there is a lot more that should be added, but the devil in the detail is for you to work out 🙂
Jeremy
Going back to the conventional backups, you would need to determine where the bottlenecks are. Perhaps the write performance to tape is the problem rather than the reads.
Some additional points:
Another option to consider is to take incremental delta backups. Take a full on the week-end (or whenever the system is quiet), then take incremental daily backups for the rest of the week.
The ACS snapshots are good for onsite restores, but you cannot do offsite recoveries with them as the snapshot is held within the SAN.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
88 | |
23 | |
11 | |
9 | |
8 | |
5 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.