>This is just type 100 - 102 records on 2 out of 11 LPARS BTW. >For some reason - the word "overkill" came to mind. Yes, whoever had the bright idea to put DB2 tracing into SMF should be shot.
Whenever the DB2 admins turn on their tracing, the in-storage SMF buffers cannot keep up, and even setting them to their maximum of 1GB we lost SMF data needed for accounting. I was of a mind to change SMF so that it doesn't accept any more data one the buffers are full. Would hopefully stop DB2 in its tracks. >My "SMFDUMP" jobs are also in STC SC with a high importance (2). Almost >nothing is IMP=1 in my environment. I envy you. Here everyone believes that they are top of the hacking order and belong into IMP=1. We run flatline on the box for hours, so WLM is pretty much outclassed here. SMFDUMP runs in SYSSTC because I put it there. > This is one of those problems you >don't have until you have it if you normally have spare cycles. WLM >is funny that way. :-) Yes, and PHBs don't understand that. So whoever screams loudest gets IMP=1 until *everyone* is imp=1. :-( (I know that my frustration is showing...) >We've never had a problem keeping up even during heavy periods Then you're lucky. How big is your standard in-storage SMF buffer? How many DB2s do you run on any one lpar? We went through quite a few hoops to prevent constantly loosing SMF data. >We really need PFA in place with the SMF flooding warning for those >situations because no one realizes there is a problem most of the time If DB2 turns on the wrong kind of trace and floods SMF, NOTHING will help you. By the time you see the message, you've already lost data. >A couple of times there were more than 255 daily >GDGs created from offloads and we had to manually code the >volsers in MXG JCL. We used to run out of space during the nightly processing. Which is why we have implemented warnings on the number of SMF switches within a certain time frame. If those exceptions are too often, we prepare the night shift to possibly change to tape. We haven't run out of GDGs yet. Barbara NItz ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
