Hi.
We are testing recover of a large MSSQL database.
24 data files (mdf-files) of 45Gb each.
When starting recover using GUI TSM start to load volume(s).
But before sending data from TSM to client, it begin allocating data files one-by-one.
This operation takes 20min each datafile, and you can say 24*20min is a very long time to wait before data actually is being transferred from TSM to the client !
It seems like it during the allocatation is doing a 'writing a test-pattern' in the files to prevent any data on disk to be available to read.
Probably a good thing for security, but in case of a restore, there should be a posibility to ignore this and just allocate files using the bipmap/fat?
I have been working on other OperatingSystem where this was a feature to turn on/off (called highwater-marking on a good old OpenVMS system
Has anyone seen this behavior before?
During this allocate of files nothing is happening on the TSM server?
Any suggestion or feedback will be helpful for me.
Thanks
/Torben
We are testing recover of a large MSSQL database.
24 data files (mdf-files) of 45Gb each.
When starting recover using GUI TSM start to load volume(s).
But before sending data from TSM to client, it begin allocating data files one-by-one.
This operation takes 20min each datafile, and you can say 24*20min is a very long time to wait before data actually is being transferred from TSM to the client !
It seems like it during the allocatation is doing a 'writing a test-pattern' in the files to prevent any data on disk to be available to read.
Probably a good thing for security, but in case of a restore, there should be a posibility to ignore this and just allocate files using the bipmap/fat?
I have been working on other OperatingSystem where this was a feature to turn on/off (called highwater-marking on a good old OpenVMS system
Has anyone seen this behavior before?
During this allocate of files nothing is happening on the TSM server?
Any suggestion or feedback will be helpful for me.
Thanks
/Torben