Thread

Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]

Herve Lefebvre <aegir@rocketmail.com> — 1998-07-24T14:22:04Z

---Marc Fournier <marc.fournier@acadiau.ca> wrote:
>
> On Thu, 23 Jul 1998, The Web Administrator wrote:
> 
> > Nope.. Oracle has a background process which re-allocates free
space..It does get
> > fragmented, and the only real way to unfrag is to export (dump)
and import.No Vacuum,
> > at least on 7.3.2
> 
> 	So, essentially, our VACUUM command provides functionality that
> Oracle *doesn't* have, right?

I don't think any fragmentation occurs under Oracle, if dataspaces are
allocated on raw-devices (wich is a functionnality PG doesn't have).

When you allocate dataspaces on raw devices, Oracle manage it's own
"file system", it's own cache-memory for this device, wich allows
a different cahce-strategy than the OS have.

--
H.Lefebvre
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]

Michael <wwwadmin@wizard.ca> — 1998-07-24T17:02:29Z

Herve Lefebvre wrote:

> ---Marc Fournier <marc.fournier@acadiau.ca> wrote:
> >
> > On Thu, 23 Jul 1998, The Web Administrator wrote:
> >
> > > Nope.. Oracle has a background process which re-allocates free
> space..It does get
> > > fragmented, and the only real way to unfrag is to export (dump)
> and import.No Vacuum,
> > > at least on 7.3.2
> >
> >       So, essentially, our VACUUM command provides functionality that
> > Oracle *doesn't* have, right?
>
> I don't think any fragmentation occurs under Oracle, if dataspaces are
> allocated on raw-devices (wich is a functionnality PG doesn't have).
>

Of course, most DBA's I know never use raw devices, because of issues such
as backups, etc... and even then, (but I am no expert here) I understand
that data still gets fragmented because of it's implementation of data
blocks, and it's rules for when to use the next block etc.. It has to allow
for records which expand and contract, so it leaves room initially to allow
for this so that records never span across two data blocks etc..Getting out
my trusty Oracle Manual....
Under Fragmentation....
To determine the amount of fragmentation...
select tablespace_name, sum(bytes), max(bytes), count(tablespace_name)
from dba_free_space
group by tablespace_name
order by tablespace_name
/
If the number of contigous blocks is greater than 10 to 15, you should
defrag the tablespace.  The steps are
1) export data from the tablespace with the 'exp' utility. For indexes,
capture the SQL to recreate them
2) Drop all the objects
3) Drop the tablespace
4) Recreate the tablespace
5) Import the data back into the tablespace with the 'imp' utility.
Maunally recreate indexes by using their SQL scripts.

Having sorted all that out...  I think we should stop asking what 'Others'
have, and just concentrate on making Postgres the best database out there,
and let 'Others' implement Postgres Features..  IMHO, to often we are so
intent on copying the 'Big Guys' that qwe forget out own strengths to the
point that we start burdening clean code with garbage for compatibilities
sake, rather than looking at it from scratch and seeing what the most
effecient method is...
The boys at Postgres have so far done a good job of creating an effecient
Database, let's keep it that way, rather than created a Clone of some
commercial software that might have years of compatibility issues that
forced implementation of methods that may not be the most effecient..
So let's stop comparing Postgres to the rest.. If there is something we
need to do with our Databases that we can't, then these are the issues we
should address only..
It's like saying let's unix should use back slashes instead of forward
slashes.. just because that is what windows/dos does...
Or that we should recode Ultima to use a Doom perspective...
Let Postgres stand on it's own merits, and not it's Oracle Compatibility..
Imagine what would have happened if Linus Torvald whould have decided that
Linux needed to be Windows compatible.. The code would not have been the
work of art it is today..  Well enough editorializing..
That's my last note on the Postgres vs. the rest argument..

--
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Michael - System Administrator              Working in Cheap Canadian
Dollars
Unix Administration - WebSite Hosting - Network Services - Programming
Wizard Internet Services - TechnoWizard Computers - Wizard Tower
TechnoServices
------------------------------------------------------------------------------

(604) 589-0037          Beautiful British Columbia, Canada
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]

Brett W. McCoy <bmccoy@lan2wan.com> — 1998-07-24T17:54:51Z

On Fri, 24 Jul 1998, The Web Administrator wrote:

> The boys at Postgres have so far done a good job of creating an effecient
> Database, let's keep it that way, rather than created a Clone of some
> commercial software that might have years of compatibility issues that
> forced implementation of methods that may not be the most effecient..
> So let's stop comparing Postgres to the rest.. If there is something we
> need to do with our Databases that we can't, then these are the issues we
> should address only..

PostgreSQL is the first real database server I've ever used.  I've not 
used Oracle or Sybase or anything like that, so the only thing I can 
compare it with is desktop database systems like MS-Access, and all I can 
say is that there' s no comparison. :-)  I don't want PostgreSQL to be 
like Access, nor anything else for that matter, but just be what it is.

Brett W. McCoy           
                                         http://www.lan2wan.com/~bmccoy
-----------------------------------------------------------------------
"The Number of UNIX installations has grown to 10, with more expected."
   -- The UNIX Programmer's Manual, 2nd Edition, June, 1972