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

"Invisible" <voi### [at] devnull> 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

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

"Orchid XP v8" <voi### [at] devnull> 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

>> 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

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

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

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

"Orchid XP v8" <voi### [at] devnull> 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

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