![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
> (I really love the way it describes "small" as "less than, say, 50 GB".
> I'd like to know in which universe 50 GB can be considered "small"...)
Telecom. Finance. Multimedia. Web services. Application Service
Providers (aka "white labeling").
Generally, "small" is anywhere you don't actually need the permission
system of your database, I'd say, because what you're doing is too simple.
Note that MySql generally backs up stuff the same way - the table
structures and the rows, but none of the system tables. I guess you
either explicitly dump them separately, or you do what I did which is
that those things don't change except manually, so you already have a
record of how it's set up.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Invisible" <voi### [at] dev null> wrote in message
news:491bff7c$1@news.povray.org...
>
> (I really love the way it describes "small" as "less than, say, 50 GB".
> I'd like to know in which universe 50 GB can be considered "small"...)
Enterprise databases.
Personally I consider any database under 100GB small. Over about 700 GB is
large. Huge is over a couple TB.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Gail wrote:
> Personally I consider any database under 100GB small. Over about 700 GB
> is large. Huge is over a couple TB.
Well, I guess Oracle is *designed* for big stuff.
So I guess to all you guys, the 1.2 GB database I'm responsible is
"microscopic" then? :-)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Orchid XP v8" <voi### [at] dev null> wrote in message
news:491c70f1$1@news.povray.org...
> Gail wrote:
>
>> Personally I consider any database under 100GB small. Over about 700 GB
>> is large. Huge is over a couple TB.
>
> Well, I guess Oracle is *designed* for big stuff.
So's SQL Server.
> So I guess to all you guys, the 1.2 GB database I'm responsible is
> "microscopic" then? :-)
Tiny. I have test databases on my desktop ten times that.
The smaller they are the easier they typically are to maintain and admin.
It's the bigger ones that are difficult because of the time required to do
anything with them (like backup, restore, defragment, etc)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> Well, I guess Oracle is *designed* for big stuff.
>
> So's SQL Server.
Yeah - I didn't mean to imply otherwise. (Recall that the "small" quote
game from an Oracle manual.)
>> So I guess to all you guys, the 1.2 GB database I'm responsible is
>> "microscopic" then? :-)
>
> Tiny. I have test databases on my desktop ten times that.
Really?
How much disk space do you have??
> The smaller they are the easier they typically are to maintain and
> admin. It's the bigger ones that are difficult because of the time
> required to do anything with them (like backup, restore, defragment, etc)
Yeah, I'll bet.
Mind you, having said that, it takes about 3 minutes to backup *my*
database...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 wrote:
> Mind you, having said that, it takes about 3 minutes to backup *my*
> database...
I've had databases that took more than three minutes to *delete*.
Mind, they were full of several thousand gig of raided multimedia...
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New wrote:
> I've had databases that took more than three minutes to *delete*.
Oddly enough, trying to delete a few thousand PNG files is an efficient
way to lock Windows Explorer up for several seconds. And the deletion
takes an anomolusly long time too... hmm.
> Mind, they were full of several thousand gig of raided multimedia...
I find the concept of "several thousand GB" intimidating. o_O
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 wrote:
> Oddly enough, trying to delete a few thousand PNG files is an efficient
> way to lock Windows Explorer up for several seconds.
Yes, just like that. :-) It makes Linux very unhappy too.
Oddly enough, I've had occasions in Vista where I move or delete a
diretory, and it spends a huge amount of unnecessary time trawling thru
a big complex directory structure, when presumedly it could just rename
the directory itself and be done. As if it wants to count how many files
are in there before it moves them as it would with a copy.
> And the deletion takes an anomolusly long time too... hmm.
Windows does some funky stuff with NTFS and deleting lots of files. It
puts stuff in the journal that the file was deleted, but since the name
of the file is actually an attribute of the file itself and not just the
directory, you can't (for example) recreate the file after you deleted
it but before the journal has actually been flushed to disk. Plus,
apparently, there's no way to tell NTFS to flush the journal as fast as
you can.
It might be something like this that makes Windows slow at deleting
large numbers of files at once - you're waiting on a slow journal to flush.
I think on Linux it was just a combination of me picking a file system
not really optimized for bunches of little files, combined with a
journaling mode that's designed for utter safety rather than efficiency,
combined with a software RAID. I probably could have improved it a bunch
if I had an incentive to learn my options before installing things. :-)
>> Mind, they were full of several thousand gig of raided multimedia...
> I find the concept of "several thousand GB" intimidating. o_O
Try to avoid working with libraries of weeks-worth of uncompressed audio
tracks.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Orchid XP v8" <voi### [at] dev null> wrote in message
news:491c777e$1@news.povray.org...
> Really?
>
> How much disk space do you have??
Haven't we been over that before?
Desktop:
1x80GB (2 paritions, OS)
1x320GB (2 partitions, apps and data)
1x160GB (1 partition, games)
Laptop:
2x120GB drives
Server:
1x80GB (OS and apps)
4x160GB in a RAID 5 config. Results in 480GB of usable space
>> The smaller they are the easier they typically are to maintain and admin.
>> It's the bigger ones that are difficult because of the time required to
>> do anything with them (like backup, restore, defragment, etc)
>
> Yeah, I'll bet.
>
> Mind you, having said that, it takes about 3 minutes to backup *my*
> database...
That's slow for a 1.2 GB. My 10GB test DB backs up in under a minute, and
that's just on a desktop. No fast SCSI drives, backups and data on same
drive and tonnes other stuff running.
Ok, mine is SQL and yours is Oracle so maybe 3 min is reasonable.
Last DB I worked on took 4 hours to backup. That's partially cause the SAN
was badly configured though. It should have taken maybe 2 at the most.
That's a 1.2 TB database
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Gail wrote:
> That's a 1.2 TB database
Oh, and for S&G purposes, AT&T before the breakup had 9 major databases,
the biggest of which was 320 terabytes, the next biggest of which was
something like 290 terabytes, etc. And something like 1800 full-time
employees writing SQL code in >million stored procedures.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |