Re: Crash course for an Oracle DBA

S. Anthony Sequeira said: > On Wed, March 7, 2007 11:39, Obnoxio The Clown said: >> I'm always worried when someone starts out by mapping what they know >> of >> one database to another. Sooner or later you'll be asking us questions >> about how Informix does things that Oracle does, but Informix doesn't >> do. > > I don't think I will do this kind of thing, I'm well used do doing my > own research, but I can't make any promises :) What I'm looking for > is a grounding, an equivalent to the Oracle Concepts manual. > >> A reasonably set up Informix instance shouldn't require any real >> maintenance effort at all. Are you seeing any particular problems? > > None, but who knows. We have a very tight SLA on this, and I'm the > end of the line, where the buck stops. I want to be prepared. > > You can say the same for a well set up Oracle instance, and probably > just about any commercial RDBMS offering on the market, however, I > have no idea who set up this particular database (if that's the right > term), and would like to be able to at least tell whether it has been > 'reasonably set up'. > > I do believe that it requires the addition of chunks (terminology > again?) occasionally. Correct terminology. You can look at the issue of storage from different perspectives. As far as the database server is concerned, you can have "dbspaces", in which you can place tables. A dbspace consists of at least one "chunk", of preferably raw disk. As the table(s) in the dbspace grow, you run out of space and hence need to add another chunk of raw disk to the dbspace. As far as tables within dbspace are concerned: space gets added in "extents". When you create a table, you can specify the dbspace in which it gets created, and the size of both the initial extent and any subsequent (or "next") extents. If a table starts getting too many extents, the server will start doubling the next extent size. An "instance" of IDS is a collection of shared memory segments, dbspaces and processes that connect the two. An instance can contain multiple "databases" (roughly equivalent to an Oracle schema, I believe.) Tables exist within databases and you connect to a_database@a_server. Remote joins and queries are possible, either across databases in an instance or across instances. Does that answer everything, or was there something you still needed to know? > Hope you get my drift, I'm not looking for a free lunch, just looking > for pointers as to the best way to educate myself. I was hoping you were offering a free lunch. :o) -- Bye now, Obnoxio "I'm astonished anyone pays real money for this crap." -- Cosmo -- This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean.

Obnoxio The Clown wrote: > A dbspace consists of at least one "chunk", of preferably raw disk. Since this is NT, scratch the "preferably raw disk" part. Chunks are typically filesystem files on Windows as the advantages to using raw disks are much smaller than for UNIX. Guy > S. Anthony Sequeira said: >> On Wed, March 7, 2007 11:39, Obnoxio The Clown said: >>> I'm always worried when someone starts out by mapping what they know >>> of >>> one database to another. Sooner or later you'll be asking us questions >>> about how Informix does things that Oracle does, but Informix doesn't >>> do. >> I don't think I will do this kind of thing, I'm well used do doing my >> own research, but I can't make any promises :) What I'm looking for >> is a grounding, an equivalent to the Oracle Concepts manual. >> >>> A reasonably set up Informix instance shouldn't require any real >>> maintenance effort at all. Are you seeing any particular problems? >> None, but who knows. We have a very tight SLA on this, and I'm the >> end of the line, where the buck stops. I want to be prepared. >> >> You can say the same for a well set up Oracle instance, and probably >> just about any commercial RDBMS offering on the market, however, I >> have no idea who set up this particular database (if that's the right >> term), and would like to be able to at least tell whether it has been >> 'reasonably set up'. >> >> I do believe that it requires the addition of chunks (terminology >> again?) occasionally. > > Correct terminology. > > You can look at the issue of storage from different perspectives. As far > as the database server is concerned, you can have "dbspaces", in which you > can place tables. A dbspace consists of at least one "chunk", of > preferably raw disk. As the table(s) in the dbspace grow, you run out of > space and hence need to add another chunk of raw disk to the dbspace. > > As far as tables within dbspace are concerned: space gets added in > "extents". When you create a table, you can specify the dbspace in which > it gets created, and the size of both the initial extent and any > subsequent (or "next") extents. If a table starts getting too many > extents, the server will start doubling the next extent size. > > An "instance" of IDS is a collection of shared memory segments, dbspaces > and processes that connect the two. An instance can contain multiple > "databases" (roughly equivalent to an Oracle schema, I believe.) Tables > exist within databases and you connect to a_database@a_server. Remote > joins and queries are possible, either across databases in an instance or > across instances. > > Does that answer everything, or was there something you still needed to know? > >> Hope you get my drift, I'm not looking for a free lunch, just looking >> for pointers as to the best way to educate myself. > > I was hoping you were offering a free lunch. :o) >

Guy Bowerman said: > Obnoxio The Clown wrote: > > A dbspace consists of at least one "chunk", of preferably raw disk. > > Since this is NT, scratch the "preferably raw disk" part. Chunks are > typically filesystem files on Windows as the advantages to using raw > disks are much smaller than for UNIX. There's always one. :op -- Bye now, Obnoxio "I'm astonished anyone pays real money for this crap." -- Cosmo -- This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean.