On Wed, 3 Sep 2008 02:25:10 -0700, Ron Hawkins <[EMAIL PROTECTED]> wrote:
>Kees, Ted, et al, > >As far back as I can remember IMS and DB2 logs have been hand placed to >reduce the chance of contention between the Logging process (mainly write) >and the Archive process (read). The most common practice I have seen is a >round-robin arrangement where the next used log is always on a different >volume, thus keeping the archive process one volume behind. > >SMS does not take away the need to look after your loved ones. While 80% of >datasets can happily exist anywhere in the Mosh Pit, there are still a few >precious "hotties" that need special treatment. They need to be hand placed, >which is one of the reasons SMS STORCLAS has the Guaranteed Space attribute: >to allow a VOLSER to be specified and honoured. Rather than calling it micro >managing, I would suggest it is good practice. Allocating the DB2 logs is >hardly a daily occurrence, and neither is allocating the WADS, catalogs, >RACF datasets and other files that require special treatment. > >Critical Files that must be kept contention free need to be hand placed. >Files that need special treatment, like Solid State Performance for the WADS >in FlashAccess, also need to be hand placed. System Managed Storage is not >about chaos, it is about ensuring order. Giving the owner of DB2 performance >the tools to deliver reliable performance will make everything run smoother. >It doesn't matter if they are a DBA, Storage Admin, or the Capacity Planner: >as long as they can hand place the things that need TLC. Kees' experience is >a good example of this. > >Ron > > >> >> Right, until some extent: yes, the DBA's should not be able to request >> those storage management details. >> >> Another point that you (the storage manager) should be aware of when >> concerning DB2 Archive Logs is their performance. When we moved from >> Hitachi disk to ESS, we had severe performance problems with the Log >> Archiving. DB2 was logging faster than archiving could empty the logs >> causing several DB2 halts. We had to spread the DB2 Logs over the ESS >> in >> such a way that logging did not interfere with archiving, thus ensuring >> sufficient archive performance. >> >> I think this is an ESS problem and not a DS8000 problem, but you might >> want to take a look into this, to prevent the DBA's from seeing >> justification in their storage management demands. >> >> Kees. > >---------------------------------------------------------------------- Thanks for the feedback Ron et.al. Some can call it micro-managing and their entitled to their opinion but unless someone knows all the details surrounding an environment, that is all it is...an opinion. I definitely agree that the need for little islands of storage doesn't really make sense from a storage management perspective but unfortunately, I am not a DBA and they get a lot more respect than my meager position holds so my two cents counts for very little. I did want to pass on some more information just to hopefully help someone else who might run into this situation. Apparently, the DBAs were using a template definition for several jobs where they were specifying a "generic" allocation of 100 primary and 100 secondary cylinders and a volume count of 5. This would work for some jobs but not for ones using larger tables. According to the DBAs, this was a necessary evil when they upgraded from version 7 to 8. After questioning this, they were able to remove the generic space allocation from the template which has solved most of the issues. I've gotten a lot of good feedback so I thank you all. Gil. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
