Writting to diskpool & primarytape at same time

[MCharland]

The teach in class, said it's possible to write to your primary data at the same time as your diskpool. This helping to go faster during migration, since part of the data already there.

I'm reading active-data pool, but that doesn't sound rigth , any inside info?

thanks

 

[sgabriel62]

Yep - simultaneous writes to copy pool.

 

[moon-buddy]

One caveat, though. You need to have a reasonable amount of available tape drives especially if you have many disk pools that are defined by usage: File System, Oracle DB, Exchange DB, MS-SQL, etc.

 

[BBB]

See "help upd stg", eg.

upd stg <primarypool> copystgpool=<copypoolname>

Note that you should continue to run "ba stg primarypool copypool" each day, even if it does nothing. It just makes double sure your copypool is complete, because there are circumstances in which it won't be (eg. copypool tape error etc).

 

[MCharland]

Humm!!
The choice for the pool on the "simultaneous write" is "none".

I see the note ... "During client node or import operations, data can be written to the primary storage pool and any combination of copy storage pools and active-data pools. " and your refering to the "ba" command

Which tend to lead me that I have my poll badly defined and I did not catch what the teach said:

Disk_os_pool (devclass = disk, type = primary random)
. >> next storage ... tape_os_pool ( devclass = lto, type = primary sequential))
. then I have ... tape_os_copy ( devclass = lto, type = copy)

my maintenance script script run ...
. mig stg diskpool du=90 lowmig=0
. ba stg tape_os_pool tape_os_copy

The option for migration have: du=85 low=50, so that I can restart backup's.

Moving my tape (using ba) to external media is fine. My issue is during backup session the disk fill soo fast that the "option for migration" does not free the disk and the pool storage taps to 100%, even dough I have migration going.

--------------------------
tsm: LAVSTSM01>q pro

Process Process Description Status
Number
-------- -------------------- -------------------------------------------------
24 Migration Disk Storage Pool DISK_OS_POOL, Moved Files: 513,
Moved Bytes: 690,741,248, Unreadable Files: 0,
Unreadable Bytes: 0. Current Physical File
(bytes): 144,650,240 Current output volume:
AOX4LIL3.
25 Migration Disk Storage Pool DISK_OS_POOL, Moved Files: 1,
Moved Bytes: 102,400, Unreadable Files: 0,
Unreadable Bytes: 0. Current Physical File
(bytes): 1,734,549,504 Current output volume:
AJX4DLL3.
26 Migration Disk Storage Pool DISK_OS_POOL, Moved Files: 38,
Moved Bytes: 380,567,552, Unreadable Files: 0,
Unreadable Bytes: 0. Current Physical File
(bytes): 19,079,168 Current output volume:
ATX4MML3.


tsm: LAVSTSM01>q vol stgpool=disk_os_pool

Volume Name Storage Device Estimated Pct Volume
Pool Name Class Name Capacity Util Status
------------------------ ----------- ---------- --------- ----- --------
/tsm_pool1/disk_os_pool- DISK_OS_PO- DISK 20,480.0 99.8 On-Line
/disk11.dsm OL
/tsm_pool1/disk_os_pool- DISK_OS_PO- DISK 20,480.0 100.0 On-Line
/disk12.dsm OL
/tsm_pool1/disk_os_pool- DISK_OS_PO- DISK 11,151.0 100.0 On-Line
/disk13.dsm OL
/tsm_pool1/disk_os_pool- DISK_OS_PO- DISK 20,480.0 100.0 On-Line
/disk14.dsm OL
/tsm_pool1/disk_os_pool- DISK_OS_PO- DISK 20,480.0 100.0 On-Line
/disk15.dsm OL
/tsm_pool1/disk_os_pool- DISK_OS_PO- DISK 20,480.0 100.0 On-Line
/disk16.dsm OL
/tsm_pool1/disk_os_pool- DISK_OS_PO- DISK 20,480.0 99.9 On-Line
/disk17.dsm OL

 

[BBB]

You prob misunderstood me.

Use the "upd stg ..." command I gave to enable simultaneous copypool write.

The "ba stg" bit I'm saying you should simply continue to run "ba stg tape_os_pool tape_os_copy" in your maintenance script even if you have enabled simultaneous copypool writes, thats all.

But if you think this is going to be a solution to your diskpool filling up you're looking at the wrong thing. Lower your himig limit (to say 60%) to start with. And at least once a day run "mig stg diskpool himig=0 lowmig=0" to empty the diskpool ready for the next night's backups, rather than leaving it almost full to begin with. If you want the data kept in the diskpool to speed up restores, consider using caching ("upd stg ... cach=yes"), although enabling this may slow down certain operations like migration, client backups.

But the actual cause seems to be your system, or your disk system, or your tape drives are not fast enough to keep the pool drained. The above suggestions are to help alleviate your prob but not completely fix it.