Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Creating a new database

Re: Creating a new database

From: Howard J. Rogers <howardjr_at_www.com>
Date: 2000/07/27
Message-ID: <397f167c@news.iprimus.com.au>#1/1

"Sandy" <daleelaNOdaSPAM_at_usa.net.invalid> wrote in message news:267b69a6.6b05cbd4_at_usw-ex0109-068.remarq.com...
> Hi,
>
> I would like to know when you run the create database
> mydb ...; what else to do before being able to create user
> tables i mean are all the system tables automatically
> created or not ?
>
> and if not i would like which scripts we must run to do etc
>

Depends what you mean, Sandy.

After you create your database, all the tables and files required to have a functioning database are ready to roll (assuming that you remember to run catalog and catproc after you've issued the 'create database' command).

However, at that point you only have the SYSTEM tablespace -and whilst it would be perfectly possible to create all your User tables in that one tablespace, you will end up with a database that performs like such a dog it barks. The idea in Oracle is to leave the SYSTEM tablespace only for the data dictionary. Nothing else should ever be created there. So you are really expected to go on and start creating your own tablespace -for example, DATA, INDEX, TOOLS, TEMP and RBS (for all your rollback segments). Each additional tablespace will require (and accomplish) the addition of a new data file to your database -the idea being that these should then be distributed across multiple physical devices so that (for example) an update on a table doesn't have to compete for I/O with the required updates on the Index or rollback segments that the table update implies.

There are no real scripts for this sort of thing: because which tablespaces you go on to create depends heavily on your intended database and its usage patterns (you might end up with, for example, BIG_DATA for huge tables, separate from the SMALL_DATA tablespace for little lookup tables. Or you might go for FAST_DATA -for tables which get regularly thrashed- and SLOW_DATA for tables which are relatively static. And conceivably, you go for "BIG_FAST", "BIG_SLOW", SMALL_FAST" and "SMALL_SLOW" and so on. And if you end up with four sepearate data tablespaces like this, you'll want four separate index tablespaces. And on and on and on....

So it's a matter of judgement, experience and foresight as much as anything else (who said being a DBA was easy?!)

Hope that starts you in the right direction, anyway.

Regards
HJR
> thanks a lot Sandy
>
>
>
> * Sent from AltaVista http://www.altavista.com Where you can also find
related Web Pages, Images, Audios, Videos, News, and Shopping. Smart is Beautiful Received on Thu Jul 27 2000 - 00:00:00 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US