I am trying to wrap my head around this layout.
I have a pool that is mixed with solid state drives and spinning drives. The intent is all DB2 tables are on solid state. My solid state is on all 1 UCB range so it is easy for me to identify. However, when I look at this pool for DB2, I am not sure how SMS is honoring the intent. When a dataset is allocated, my understanding is that it will land on any available space in the pool. Therefore it is possible my DB2 table might not be on the solid state device I want it to be on. Is that a correct understanding? If that is correct, is there any way in SMS to force the allocation (via JCL or other) to the specific volume in the pool? Final thought. Say I get the file on the solid state, if it gets migrated and then recalled, is there any way to ensure it goes back to the solid state device? Now for a side question. With DB2 in general, IBM's direction is to keep all application tables and system tables in same pools. Is my option to make sure all DB2 items are on solid state? Or can I have elements like image copies, log archives etc., to the solid state rather than separating out to spinning and solid state? They use the same HLQ for all DB2 Allocations, so I would need to change my ACS code to include the dsorg type for separation. Better to have all solid state and not worry about mixing VSAM and NON-VSAM in the pool for DB2? Or for DB2 recovery and backup, it is okay to have a Solid State Pool and Spinning pool for non VSAM DB2 files for backup/recovery and daily usage? I remember some Share presentations on how DB2 is looking to be placed in SMS and I will probably go back and re-read it. As you know, things change over time. Any thoughts or guidance is appreciated. Lizette ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
