OK, here's my good news/bad news for the informal poll: Production 6.1 server: New TSM 6.1.2 installation with a wompin powerful Win2K3 box, lots of external SAN disk Running 76 schedules of daily incrementals: Most clients are relatively small Win2K3 servers, all TSM client 6.1 A few Linux clients TSM 5.4 & 5.5, Solaris clients TSM 5.4 & 5.5, SQL client 5.5. Retention is nolim, 30 days (but only about half the clients have been running 30 days yet).
DB is 25 GB Occupancy 29M objects, 7TB total data in primary storage pools. (Since this is a new TSM customer, didn't have to face any issues with doing export/import. That may be why I haven't had to deal with data base swell.) No problems with server crashes since upgrade from 6.1.1 to 6.1.2 (in spite of the fact that I almost daily get 1 or 2 client failures saying the client backup died because the server active log is full, which it isn't). The problem is sizing the active logs, which do not work as documented. (Documentation says the active logs will get created in 512M chunks up to the ACTIVELOGSIZE limit, but it goes higher than that, and when it starts running up, it's explosive.) NOBODY should run at the default log size of 2048. My active log size is 80GB. I chose to go with V6 for a particular reason with this customer. Still probably the best choice for this customer for internal site reasons. After this experience, here's what I'm telling my other customers: The good news: There is nothing I've encountered that makes me worry about data integrity. The sucker works. The bugs I'm still encountering are things we can work around for a while. (I would probably feel differently if it kept crashing on me.) The bad news: There are messy, annoying, time consuming issues that you will run into, especially if you are a power user: - There are error messages that are not documented to any degree of usefulness. (Fond memories of ANR9999? Say hello to his little friend, ANR0162W "Supplemental data base diagnostic information"... A simple SQL query syntax error generates enough output to send zillions of bits to an untimely death in the bit bucket. But for real errors, the info provided is useless.) - Just the fact that the stable of scripts I normally use for checking and diagnosing TSM systems don't format in columns from the command line anymore has taken a surprising amount of time to mess with. - SQL time-interval queries don't appear to work at all any more. Certainly don't work as documented (gotta spend some time on that one..) - There are errors in the documentation, some obvious, some subtle. - There are bugs, and we'll be finding them for a while yet. - et cetera - et cetera So, If you have a REASON to go to the 6.1 server, do it (at least on Windows - sounds like Linux is having uglier issues...). For example, if I had the opportunity to take advantage of 6.1 dedup, I'd say do it in a heartbeat. Just understand that dealing with 6.1 still requires patience and time, and plan accordingly. It will NOT be like previous smooth upgrades in the 5.x series. If you don't have a reason you need to go to 6.1 server, stick with 5.5 while the rest of us bleed, and spend your time taking advantage of all the cool new things in the 6.1 clients: -6.1 for Windows has much improved integration with VCB -6.1 -snapdiff for NetApp is HUGE -6.1 for Exchange has item-level restores now -6.1 ISC is a significant improvement over previous versions You can use all those with your 5.5 server. They should keep you busy for a while. Wanda (send Bandaids) P On Mon, Oct 5, 2009 at 11:50 AM, Allen S. Rout <a...@ufl.edu> wrote: > >> On Fri, 2 Oct 2009 09:49:52 -0600, Kelly Lipp <l...@storserver.com> > said: > > > > That last paragraph made my head hurt! I had the "opportunity" to > > take a database class in college. Didn't want to know it then, > > don't want to know it now. > > There was a "Know-nothing" political party, once.. :P > > > I'll echo Rick's comments: you pioneers, you go! Those arrows don't > > hurt that much. That which doesn't kill you makes you and all of us > > stronger. > > But that logic works even if we _do_ die. > > - Allen S. Rout >