Copy optical disk data back to iSeries disks

[marktaylor]

Like Rav ( see: http://www.odusergroup.org/forums/index.php?topic=1164.0 ) we are using optical to store our CSOD images.

Again, Like Rav, we need to move all Optical images back to disk.

Our 'Original' Migration Policy was:

Level 10 - Disk - 60 Days
Level 20 -  Optical - 99999 Days - 'Optical Forever'

Our 'Modified' Migration Policy, to allow us to start bringing documents back is:

Level 10 - Disk - 181 Days
Level 20 -  Optical - 999998 Days
Level 30 - Disk - 999999 Days

So - we have a couple questions.

First - we really don't want to send any more documents to Optical - what's the best way to prevent migration to optical moving forward?

Secondly - once we move everything back to disk - can we remove Level 20 and 30 from the policy? (Or we we remove 10 and 20?) .

Thanks!

[Joe Wolken]

You can not remove a level from the Migration Policy.  However, you can select the check box on the Migration Level definition screen to Disable the level.  This prevents OnDemand from writing any new objects to this level.  You could do this for your Level 10 and 20 in your environment.

There is a good description of Migration Policies and Storage Levels on starting on about page 145 of the IBM Redbook, CM OnDemand Guide, SG24-6915-03.

[marktaylor]

Thanks, Joe! That's exactly what we wanted to know. Followup if I may...

Let's say, then, that we disable levels 10 and 20. All new documents will go to level 30. After 181 days (given our example below), will  documents that are at Level 10 migrate to level 30 'on their own'? Or will we have to migrate those manually as well?

We intend to start moving images from level 20 to 30 manually sometime soon. We're actually in the process of recalling old SFA documents now; as soon as that finishes we're going to tackle the ASM documents.

Thanks!

[Joe Wolken]

Yes, it has been my experience that as you continue to run DSM/ASM it will continue to migrate documents from level 10 to level 30 if level 20 is disabled using the number of days that was specified in the migration policy when the object was stored.  This would be on after 181 in your example.

Good luck with the SFA migration.

Joe

[marktaylor]

Thanks, Joe! Moving images back is going swimmingly!

I might mention - we did run into one issue with recalling the SFA images  - the job was taking lots of CPU (55% +) and took days to recall a single platter. We found a tip that states:

     It might be possible to improve the performance of MMF by creating the following index using SQL:

     CREATE INDEX QUSRRDARS/QARLRSRTX ON QUSRRDARS/QARLRSRT (CDTYPE, ONAME, RESTIND)

And it made a HUGE difference. CPU went to 1-2% max, and the each platter was processed in a matter of hours, not days.

Hopefully this information might help someone else!