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: PeopleSoft on Oracle: Standard or Enterprise Edition??

Re: PeopleSoft on Oracle: Standard or Enterprise Edition??

From: Howard J. Rogers <howardjr_at_www.com>
Date: Tue, 5 Jun 2001 22:50:57 +1000
Message-ID: <3b1cd5d4@news.iprimus.com.au>

[Snip]
> >
> > Online Index coalesce (defragmentation) - A pain, but it should be
> > managable with proactive maintenance, especially off-hours scripting.
> > If you're running 24x7 and see massive, constant DML on indexed
> > tables, you're probably not sweating the added cost of EE.
> >

Index Coalescing is, imho, of dubious value. The deletes or updates on your tables need to be highly concentrated within the index before the coalesce will actually do anything at all. If your DML is scattered across the entire table, then practically nothing will happen, If a great, concentrated, wodge of leaf nodes have vast quantities of empty space, then maybe you'll see a benefit. Never seen it myself, however.

> > Online Index build - "Indexes can be built and re-built without
> > locking the table during the operation." This one, I don't get.
> > Everytime I've tried to either build or rebuild a large index on OLTP
> > systems, I've seen locking (in EE), so it's not clear to me what
> > you're really losing here.

Online rebuilds mean that whilst the index is being rebuilt, all DML to the table that would affect the index is placed into a journal space. The theory goes that when the index rebuild is complete, the journal is then played, and hence applied to the index. Meanwhile MORE DML is happening, so the journal is being added to as it is also being played. Ideally, DML quietens down of its own accord so that the new arrivals don't outweigh the emptying of the journal. But, if that's not true, such that the journal is not getting cleared after a 'reasonable' period of time, then Oracle will suddenly decide to lock the table in the old fashioned way, thus allowing the journal to be cleared down.

Clearly, you are trying an online rebuild on a table still subject to heavy DML -which is entirely contrary to the training course (and, from memory, the documentation) advice. So yes, the results will be unpredictable.

On relatively quiet tables, then it works quite nicely.

Otherwise, I think your assessment is reasonably fair. I personally would not like to lose bitmap indexes, not function-based indexes.

Regards
HJR
> >
> > Advanced Replication - Possibly a Big Lie. In the Linux version
> > (8.1.7.0.1) of Standard Edition, it *is* an option -- I'm looking at
> > v$option, as well as the install logs as I write this. It's right
> > there with a checkbox.
> >
>
> Advanced Replication was NOT available with 8.0 SE.
>
> > Multi-protocol connectivity. Do people *really* mix SPX/IPX and IP to
> > connect to Oracle these days? In all the implementations I'm familiar
> > with, including DEC, HP, and IBM, IP is the preferred protocol (and
> > certainly represents the largest install base).
> >
> > Oracle connection manager - Another possible Big Lie. It's right
> > there in my install options -- I'm looking at it.
> >
>
> if you run Connection Manager on a separate node, as some of the
> documentation suggests, do you have to pay for an EE license on
> that node ? yikes !
>
> > Standby Database -- Not clear on this one. The link above (the
> > newest, as far as I can tell) says no, on 8.17 SE; however, according
> > to this document:
> > http://technet.oracle.com/products/oracle8i/pdf/8i_fam.pdf
> > 8.16 SE *does* allow read-only Standby Database, so who knows...
> >
>
> hmmm... SE does NOT provide "managed" standby database.
> so you'd be on your own to detect that archiving of log files has
> completed, and transmitting the file to the remote machine, and
> applying the redo. letting oracle manage this for me would be
> a big plus...
>
> but what if i could have a second database up live running, ready
> to accept transactions without having to do anything to "failover"
> and without having to "switch" the standby database to active...
> be able to specify the specific schemas/objects to keep in sync
> nearly realtime... without having for force log switches... and do it
> with less of an impact on the network... now that would be slick.
> oh... wait a minute... i'm confusing myself with another solution
> we obtained from another vendor...
>
> > For the record, we are using 1.2Ghz K7 Thunderbirds, with 3 SCSI
> > controllers and UW 9 drives, and 1.5GB RAM, running on Red Hat Linux
> > 6.2 and are seeing *fabulous* performance in both OLTP as well as
> > datamining apps (yes, we use two different boxes, specifically
> > configured for each respective environment). Talk about "on the
> > cheap" -- by using minimum named users, and the 33 license-per
> > Gigahertz formula that Oracle requires, our total cost was literally
> > hundreds of thousands less by opting Standard Edition.
> >
>
> sweet! we're using dual 440MHz PA-RISC processors, 4 Wide
> Ultra 2 LVD SCSI controllers, 10K RPM LVD 18GB drives, 2GB
> RAM, HP-UX 11.0, MC/ServiceGuard cluster.
>
> > It is entirely possible that some of the misinformation stems from
> > that fact that different platforms have slightly different options,
> > even though they are all "8.17". So much for "100+" platforms
> > supported (well, at least equally, I suppose...)
> >
> > In this environment, our concurrent user base is fairly small but the
> > data volumes are sizeable. By using open source tools such as
> > PHP/Apache/OpenSSL/OpenSSH, we have put together a very well-tuned
> > system. As I type this, I'm watching some stress tests on a 1 million
> > row table build (mixed, real-world data), with multiple indexes. It is
> > clocking around 30,000 inserts per minute. U-S-A ! ! !
> >
>
> that's crankin.
>
> > Hope that helps.
> >
> > -kenn
> >
>
>
Received on Tue Jun 05 2001 - 07:50:57 CDT

Original text of this message

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