Colin, Thank you VERY much for taking the time to give us this info. IC62978 may explain a lot of what I'm seeing, but I had not hit on it in my searches.
BTW, can you tell me where to find the mentioned db2diag.log file on a Win2K3 server? If it's in there, I can't find it. I'll look forward to 6.1.2.1! W On Tue, Oct 6, 2009 at 8:12 PM, Colin Dawson <col...@us.ibm.com> wrote: > Howdy, > > Of the items being discussed I do not know if PMR's are open with IBM > service or not. I encourage folks to open PMR's for issues that are > encountered. We are working through reported problems and getting them > diagnosed and resolved. > > There is a fix for IC62978 that will be coming out with the server > patch level 6.1.2.1. The reason I mention this here is that in some cases > this may be contributing to needing more log space then was originally > expected or planned for. The issue is that the online table reorganization > is opportunitic meaning that it really gets going and doing its work when > the server is idle or not running a heavy workload. The problem arises > when there are long running transaction(s) such as a TDP or BA client > backing up a large object (100's of GB or TB in size) using a single > transaction. This long running single transaction mixed with table > reorganization doing it's thing can result in a lot of log use for the > active and archive log and depending upon the duration of things and the > log settings in place we may get to an out of log space situation and bring > down the server. The fix for this APAR causes the table reorganization to > work and play better with other transactions and should provide relief for > some of the ever increasing log size issues being encountered. Certainly > if after 6.1.2.1 is available there continues to be log consumption issues, > that is definitely something we'd want to see and pursue via problem > records. > > The other fix of note coming out in 6.1.2.1 is IC63162. This is a > timing related crash that has been reported and seen by a number of > customers. So, if you are experiencing an intermittent crash this is > definitely something that should be reported especially if it continues to > be seen after 6.1.2.1 is available and applied in your environment. > > Relating to both APAR's mentioned above, additional information will > be published for this via our flash process in the next few days... > > With regards to database space and needing significantly more then was > needed for V5.x, I have not seen or diagnosed much in that area at this > point. From the discussion here it seems that we are seeing this on a > couple different fronts. One being from Geoff Gil (references having a > problem record opened for this) and the other being from Stefan Folkerts > (no reference to a problem record). If folks have problem records for > these, please email the PMR # and we can get the development/L3 team > engaged as we would like to look into this and see what is going on. From > a high-level view of things, we are using table level compression which > should keep the database space in check. The preliminary investigation in > this case will then be to see what kind of efficiency are we seeing with > that or is it being given a chance to actually do what is needed. The > other thing that comes to mind in this case is that TSM V6 is using a much > larger page size for the database. Most of the tables are using 8KB for > the database pages while our largest tables are using 32KB. Part of the > initial "bubble" of increased database space may be resulting from the way > the database clustering is being done along with these larger allocation > units/pages being in the mix. So, if this were coming in to play in this > case, it may be that the occupancy per page is relatively low and future > record insertions and such will use this space and things will plateau or > stabilize as such... Anyway, this is just speculation and there are > certainly things we'll need to look at to get a handle on this and such... > > Thanks in advance for taking the time to read through my response and > thoughts on things... > ----------------------------------------------------- > Colin Dawson > TSM Server Development > col...@us.ibm.com > > > > From: Stefan Folkerts <stefan.folke...@itaa.nl> > > To: ADSM-L@VM.MARIST.EDU > > Date: 10/04/2009 11:26 PM > > Subject: Re: [ADSM-L] TSM 6.1 and the ever expanding DB > > Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> > > > > > > > I have been a member of the "TSM 6 in production club" since 6.1.2.0 and > I am not happy with this release. > > I am also seeing strange db errors right from the start (clean install > and export/import from 5.5 server) looking at the IBM help for these > errors I read fairly cryptic steps about changing DB2 setting..step one > was "Open the DB2 console"..what the heck!? > I don't want to open the DB2 console, IBM told me I would not need DB2 > knowledge and that the DB2 database use would be transparent for > me..well..it's not...within the first hours after install until now it > is not. > > DB size has increased about 5 times (using dedupe) and don't even get me > started on the log size. > > Good things are dedupe, I get a 22% reduction of the amount of data > stored on disk which is nice. > Performance is good, it sucks that they changed some internal tables so > tools such as TSMmanager need to catch up on the new layout..TSMmanager > reports on size stuff don't work at the moment. > > More than once the system just stops responding...no lead on where it > comes from and I never had this before on v5, it's not the hardware > since I run TSM v6 inside a VMware VM and all other vm's are fine. > > At this point in time I would not recommend using TSM 6.1.2.0 in a > production environment. > > -----Oorspronkelijk bericht----- > Van: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] Namens Zoltan > Forray/AC/VCU > Verzonden: vrijdag 2 oktober 2009 15:15 > Aan: ADSM-L@VM.MARIST.EDU > Onderwerp: Re: [ADSM-L] TSM 6.1 and the ever expanding DB > > Join the club. I am beginning to wonder if anyone is successfully using > V6.1, trouble-free. > > Monday I decided to put my 6.1.2 server into production and am wondering > if this was a really bad decision. > > I have had to bounce it 5-times due to it simply hanging/going > non-responsive eventhough the only "activity" has been exporting a large > node from another server. > > The primary active log has been expanded 3-times (from 20GB to 60GB) > eventhough I run 3-full DB backups daily. > > I had to reserve 300GB for the archivelog space. > > The DB has grown to 65GB for 4-nodes eventhough the original server with > 250-nodes is only 80GB used. > > The diagnostic information for DB/log errors is fairly useless. The > book > says to go to DB2 to get it to explain the SQL????? errors, eventhough > in > other places the book says to not mess with DB2 ("pay no attention to > the > man behind the curtain......"). I am having to become way more > knowledgeable in DB2 than I ever wanted to be ("Damn it, Jim.....I am > the > backup/TSM administrator - not a DBA!" - apologies to DeForest Kelley) > > Just got my 5th SQL error this week ("10/2/2009 8:49:46 AM ANR0162W > Supplemental database diagnostic information: -1:22003:-413 ([IBM][CLI > Driver][DB2/LINUXX8664] SQL0413N Overflow occurred during numeric data > type conversion. SQLSTATE=22003") > > I have to run 3-full DB backups every day (along with the now added > 3-BACKUP VOLHIST) just to try to keep ahead of what I consider normal, > daily activity (never had to do this on V5.x - daily DB incrementals > use > to be more than enough - heaven help me if I get this server up to the > size of my biggest V5 server which has a 150GB DB - I could never backup > the DB fast enough to keep it from crashing). > > --------------- > > How about an informal poll. > > How many folks are running V6.1.2 servers in production? > > How big (occupancy? DB size? Number of active nodes?) > > What platform? > > > > From: > "Gill, Geoffrey L." <geoffrey.l.g...@saic.com> > To: > ADSM-L@VM.MARIST.EDU > Date: > 10/01/2009 08:12 PM > Subject: > [ADSM-L] TSM 6.1 and the ever expanding DB > Sent by: > "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> > > > > I'm finding that what I know about how the DB works in 5.5 doesn't > really equal how it works in 6.1. On a Linux box I brought up to migrate > clients to a 6.1 server I created a 20GB log and 100GB DB. There 'will > be' about 150 nodes moved to this instance but currently about 20 are > backing up. My 5.5 server, on AIX 5.3, has a 125GB DB about 50% used, a > 11GB log and it backs up 500+ clients per day with no issues. > > > > Last nights backup on the new box is telling me there is no more space > in the database so backups are failing. After backing up systems for 30 > days? I find that way out of whack from how 5.5 works and it seems to be > telling me I need more than 10 times the space to keep 6.1 up. I can't > believe 20 computers have eaten up 100GB of DB space in such a short > period of time. > > > > I have a case open with IBM to discuss but I'm wondering what others are > finding that are using 6.1. Perhaps I'm missing something in my setup > that is causing the problem (I hope) because if not I don't want to even > think about how much disk I have to add to the current box so I can > upgrade it and make it run with the 400+ systems that will stay on it. > > > > Anyone else seeing this or have an idea what I may have missed? > > > > Geoff Gill > TSM/PeopleSoft Administrator > > SAIC M/S-B1P > > 4224 Campus Pt. Ct. > > San Diego, CA 92121 > (858)826-4062 (office) > > (858)412-9883 (blackberry) >