Bill,
I'm sure that *SM scales the way it should. But there are practical limits
on the size of the database that have to do with current computing
technology, not *SM.
The recommendation that support gave to one of my customers was to limit the
database to 17GB. I don't know why they used that number.
My recommendation to customers is to contain the database to a reasonable
restore time. That's different for everyone. In many shops, an 8 hour
restore time would be acceptable only if it occurred at a convenient time of
day, say, after all the backups were finished and before the next cycle was
starting.
If the server is rude and wants a database restore at an inconvenient time,
I want to be able to get the restore done and meet the service goals for the
backups. In some shops, missing a days worth of backups due to an unplanned
outage is acceptable. Most shops certainly missed many days of backups when
they were using whatever product *SM replaced. Of course, they didn't
necessarily tell their management about that.
I think the *SM database will continue to scale far beyond what we have
today. As we replace existing machines with faster machines, the DB
backup/restore times will be reduced and larger *SM databases will be
practical.
In the meantime, single server *SM scaling has a limit. But *SM scaling has
no limit. My background is distributed computing rather than centralized.
I like to add another server when I reach today's practical limits and add
centralized management capabilities. We get all of that in *SM. That's why
I like to use it for most enterprise backup environments.
I agree with your call for optional databases, but I've seen the problems in
trying to implement multiple database support back when I worked for a
competitor of *SM. Other databases are more scalable.
My snide comment about Oracle administrators was due to some of the Oracle
databases I've been asked to back up lately - 1Tbyte growing to 4Tbytes!
Now, that's too big for any database with today's technology. Can the
software handle it? Probably. But we have to go through lot's of hoops to
make it restorable using mainstream hardware. It would help if the database
administrators design the database with restore in mind rather than letting
them grow to an unmanageable size.
Bill Smoldt SSSI
Storage Solutions Specialists, Inc.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
Of
Bill Colwell
Sent: Friday, February 04, 2000 7:49 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Largest *SM DB
What I am hearing is that you don't think *SM scales up the way it should.
Is IBM/Tivoli really recommending not to go over 20G? It's news to me, and
if so, will they please a clear public statement on scalability?
My db stats are --
Total Usable Pages: 16,801,792
Used Pages: 14,374,135
The last full backup took 8:55. I do it weekly, I take daily
incrementals. The server is os/390 1.3, *sm is at 3.1.2.50, 1450 nodes,
92M files, 5.6T total primary pool data, 9840 tape drives.
I still think the ultimate solution for large databases is to have an
option to host the db in db2 or oracle where the managment tools are very
robust, and a 54G db is ordinary.
--
--------------------------
--------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
In <000c01bf6e9d$c6344b60$8404a8c0@balthasar>, on 02/04/00
In <000c01bf6e9d$c6344b60$8404a8c0@balthasar>, on 02/04/00
at 09:48 AM, Bill Smoldt <smoldt AT STORSOL DOT COM> said:
>And split it up, they should. You shouldn't have a database this large
>unless you're from Texas. We aren't Oracle database administrators, who
>all believe bigger is better.
>I think the current support recommendation is to keep it under 20G. The
>last site I visited with a 50G+ database was taking too long to back up
>the database.
>For those of you with large DBs - how is your DB backup time?
>Bill Smoldt SSSI
>Storage Solutions Specialists, Inc.
> -----Original Message-----
>From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
>Of Joshua S. Bassi
>Sent: Thursday, February 03, 2000 2:17 PM
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Re: Largest *SM DB
>Keith,
>This was talked about on the list about 6 months ago. I believe the
>largest DB reported here was 70GB. Most customers end up splitting the
>*SM implementation at that point into one or more servers.
>--
>Joshua S. Bassi
>Senior Technical Consultant
>Symatrix Technology, Inc.
>jbassi AT gloryworks DOT com
>(503) 702-3371
>-----Original Message-----
>From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
>Keith Nelson
>Sent: Thursday, February 03, 2000 10:57 AM
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Largest *SM DB
>Who's managing the largest single instance of a *SM DB?
>Keith Nelson Voice: 612.891.2867
>Gresham Enterprise Storage Fax: 612.891.4763
>knelson AT openmic DOT com Web: http://www.gresham-computing.com
|
