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 <asr AT ufl DOT edu> wrote:
> >> On Fri, 2 Oct 2009 09:49:52 -0600, Kelly Lipp <lipp AT STORSERVER DOT 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
>
|
