on 09-29-2010 9:47 AM
Hi,
We want to transfer last 6 months data from Production system to Quality system.
We have selected last 6 months data which is around 315 GB (unexpected). Then we created a new package and run it again for 1 month only , but still it is showing data transfer volume 315 GB.
Our total database is 440 GB. and in last 6 months, database growth is 70 GB. so practically, Data transfer volume should not be 315 GB.
We have installed DMIS patch level 12.
Please suggest any solution.
- Bhupendra Patel
Hi,
It might be possible that maximum amount of data is stored in Z tables which are by default transferred in Full.
Please check if this is the case and try to reduce them by assigning them a reduction criteria via the activity "Maintain Table Reduction".
Regards,
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Suman,
Thanks for prompt reply.
Please find below tables in which DFKKOP and DFKKOPK are bigger.
Conv. Object Table name Size
DFKKOP DFKKOP 72.978.432
DFKKOPK DFKKOPK 68.495.360
ZSIMI_INVOICE ZSIMI_INVOICE 31.243.264
/NYH/CP_TRANS /NYH/CP_TRANS 23.387.136
FKKDEFREV FKKDEFREV 22.867.968
ZCA_2004KKOP ZCA_2004KKOP 22.684.672
DFKKKO DFKKKO 16.335.872
- Bhupendra Patel
Hi Bhupendra,
As can be observed, more than 200 GB is occupied by these 7 tables which if am not worng are transferred in Full. In this case, a from date of 6 months doesn't affect since the entire data will be transferred.
In order to reduce the data volume, please either reduce them or if these tables are not required, you may also set them for No Transfer. This way it will be possible to easily bring down the data transfer volume.
The difference in the size of the tables might be caused due to :
a. Database statistics are not up to date in the system
b. The data is held in compressed form at the DB level, etc.
Also, I would also like to inform you that the activity Estimate Data Transfer volume gives only an approximate volume. The actual data transfer volume may vary by a small amount.
Best Regards,
Suman
Hi Bhupendra,
To answer that question, you will have to consult the functional experts who would be using these tables and confirm if the chosen reduction criteria is good to go or not. For example, a table might be reduced by date by default but the testers may need all data for a fiscal year. In that case, a differnt reduction criteria would have to be chosen.
Thus, I would suggest to have a discussion with the experts and then proceed ahead with the transfer to avoid problems after the transfer.
Best Regards,
Suman
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello,
The reason for this behaviour is that TDMS or better the MWB underlying TDMS is not calculating the raw data but the worst case data amount.
So the number of rows multiplied with the fieldsize of each field of the row.
If you have tables with many empty fields the numbers are not really accurate.
To have a better view on the amount i would recommend to check the size of the table (for the top ten tables) and divide it by the number of rows in the table and then multiply it again with the number of rows to be transfered.
Best Regards
Joerg!
Edited by: Joerg Wrage on Sep 29, 2010 2:54 PM
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks suman and joerg for the reply.
I think all 7 table were calculated full. I have reduced size using Maintain table reduction and it is reduced to 101 GB from 315 GB.
As i have reduced table size with the defualt field selection so just wanted to know that will it cause any problem??
Once again thanks a lot.
- Bhupendra Patel
User | Count |
---|---|
80 | |
9 | |
9 | |
7 | |
7 | |
6 | |
6 | |
6 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.