| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: Database vs. Tablespace vs. Datafiles
I think there's still some confusion in the way you've responded to this. In
particular, the sentence a tablespace resides in a datafile can be misconstrued.
The rest of your explanation here is OK. Tablespaces are logical, and can span
multiple datafiles across multiple disks, so the idea that a tablespace resides in a
datafile doesn't make sense on that basis.
To clarify some of the other issues, what normally happens when people create a database is this. The create database command doesn't take a tablespace parameter normally, because all we're creating at this stage is the SYSTEM tablespace. Most people normally add other tablespaces (RBS, TEMP, USERS etc.) after the create database statement due to the good old chicken and egg syndrome of not being able to create non system objects using the SYSTEM tablespace. I won't go further into this at this stage, because that may be more detailed than Greg needs now in his career as a DBA (Greg, let us know if you need the gory detail here!).
Further, it is possible for nonracial processes to write to Oracle data files, depending on the OS, permissions etc. Would you ever want to do this? No way! But that may be where Greg's fourth comment is coming from.
HTH. Pete
Andreas Schlager wrote:
> Hi Greg!
>
> I think, you messed the terms. Basically: A TABLESPACE resides IN a DATAFILE.
> The datafile is nothing else than a physical file on your disk. The tablespace
> is only a "logical" unit. A tablespace can span over multiple datafiles. For
> example: you make a tablespace named "MYTBLSPACE". When this tablespace is full,
> you must add another datafile to this tablespace. The tablespace looks like one
> unit, now f.e. 3 GB large. But on your disk you now may have two datafiles, one
> 2 GB and one 1 GB in size.
>
> When the Tablespace grows, Oracle makes an EXTENT. To do this, there must be
> unused space in the DATAFILE. Oracle allocates a part of the free space to the
> tablespace. When this occurs often, you get a performance-problem because of the
> fragmented tablespace. So the tablespace should be sized well to your needs.
>
> The creation of a tablespace must not be at DB creation. You can create a
> tablespace every time you want with the CREATE TABLESPACE command. But it's much
> easier to do this with the Oracle Enterprise Manager.
>
> I don't know what you mean with point D.
>
> I hope, this helps you.
>
> On Fri, 21 May 1999 03:46:35 GMT, news2_at_baxnet.net (Greg) wrote:
>
> >I'm a little confused on this one. I'm totally new to Oracle, so bear
> >with me!
> >
> >A) I've read tons of docs about the basic layout and policies of Oracle.
> >It's my understanding that the DB is the master of it all, followed in a
> >pecking order: TableSpaces, DataFiles, then Extents and other OS block
> >type objects. Right?
> >
> >B) But this is what gets me: When I create a DB, I'm asked to assign a
> >specific DATAFILE in the create script. Why a DATAFILE? Why have I
> >totally jumped around the TABLESPACE here? Why the heck doesn't the
> >DataBase CREATE command point to a series of specific TABLESPACEs for
> >specific uses instead of a DATAFILE? Then let the DBA assign different
> >DATAFILES to the tablespaces as needed?
> >
> >C) I read in Oracle docs that when I create a new DataBase, it wants a
> >system, user, temp, index and "general data" tablespaces. But there's no
> >place to add TABLESPACES in the "Create Database" statement! Am I wrong
> >on that?
> >
> >D) I can modify TableSpaces all day long, I've gotten that far. I attach
> >DataFiles to Tablespaces with no problem. But further reading states
> >that the DataFile must be dedicated to the DataBase with no other uses!
> >
> >E) I'm lost.. I'd love to get over this hurtle, and I'm sure it's just
> >the way I've interpreted all of this, or a mental block or something…
> >
> >Thanks in advance - Jon
>
> Andreas Schlager
> aschlager_at_kaindl.com
>
> M. Kaindl Holzindustrie
> Walser Weg 12
> A-5071 Wals / Salzburg
--
Regards
Pete
Pete Sharman Email: psharman_at_us.oracle.com Project Manager Phone: +1.650.607.0109 (int'l) Worldwide Internal Services Education (650)607 0109 (local)Oracle Corporation
SQL> select standard_disclaimer, witty_remark 2 from company_requirements;
Opinions are mine and do not necessarily reflect those of Oracle Corporation
"Controlling application developers is like herding cats."
Kevin Loney, ORACLE DBA Handbook
"Oh no it's not! It's much harder than that!"
Bruce Pihlamae, long term ORACLE DBA
Received on Fri May 21 1999 - 03:07:48 CDT
 |
 |