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

"Vincent Ventrone" <vav_at_brandeis.edu> wrote in message news:<9eorgv$9i9$1_at_new-news.cc.brandeis.edu>...
> We are about to move our PeopleSoft Financials (Education & Gov.) ver. 7.5
> SP1 into production & have decided to use Oracle Standard 8.1.7.1 instead of
> Enterprise Ed. because the cost is so much lower & it seems clear to us that
> PeopleSoft uses none of the features in Enterprise, nor do we plan to use
> any of those features. This will also be a rather modest sized database,
> approx. 6GB when fully implemented. However, the Oracle salespeople are
> trying to convince us that we *must* use Enterprise Edition & not Standard
> though the reasons are, so far, extremely vague -- I suspect the only reason
> is the difference in commissions for the sales force! So I'm wondering if
> anyone in this newsgroup is running PeopleSoft Financials in production
> using Standard Ed. & whether they've encountered any difficulties or
> disadvantages by doing so.
>

Hi Vincent.

I can't speak to Peoplesoft-specific issues, but I recently just finished a significant investment of time in the Standard vs. Enterprise issue myself. Here's my 2 cents:

According to the latest information:
http://technet.oracle.com/docs/products/oracle8i/doc_library/817_doc/server.817/a76962/ch4.htm#73594

Oracle claims there are some serious differences, but their documentation fluctuates between being flat out wrong and misleading in many cases. Just walking down the list on document mentioned in the link above, let's take a look past the hype, to the real deal:

Advanced Security - not available. True, but this option is an extremely expensive option on top of the base EE price, and is really geared towards client-server architectures. In our case, we were very concerned about sniffing sensitive data travelling between the web server and the database. Our solution was simple, and about 1/10,000th the cost of AS: we installed additional NICs and used a high-grade cross-over cable between the two boxes, making (literally) a private network. No sniffing here! For DBA access and the occassional SQL-plus session, we're using tunneled OpenSSH, which I would argue is far more robust and better tested than Oracle's wallet manager (in the 8.17 docs, they announce several apps that "now" use 128-bit keys. Nice...) This solution works with Enterprise Manager, as well as TOAD, by the way.

Diagnostics Pack and Tuning Pack- not available. Right, but look further down the page and read the description for the Oracle Standard Management Pack: for a slight addtional cost to SE you get "A complete set of database tuning, diagnostic, change management, and other manageability technologies for Oracle8i". And frankly, most of the GUI stuff will only go so far in troubleshooting real world problems, especially with performance. Where is bstat when you need it?

Parallel Server - not available, but how widely implemented is this in medium- or even large-scale enterprise deployments? I've worked on systems that supported 10,000 concurrent users on one 4-processor DEC alpha which more than held it's own. If you *really* need OPS, you're probably not sweating the additional 85% cost... In many apps, performance is far more disk-bound that CPU, and there are other failover soultions beside OPS.

Bitmap indexes - not available. This one is a bit of a pain, but the jury's still out on real-world performance for the traditional M/F and Y/N data tables. Oracle's documentation is a bit contradictory here, especially when using the more-than-10%-of-the-data-will-be-returned rule with indexes. Anyone out there have real numbers on this?

Function-based indexes. This might be a consideration, but even so, it could be worked around with derivative data being put in their own columns (not optimal, I agree, but workable).

Materialized views - I don't quite get this one. If you have a summary table, why would a query redirect be more efficient, than simply referring to the summary table directly. Large-scale DW/DSS people, help me out here.

Parallel DML -- if you are using Partioning, this could be significant. Parallel Query - Possibly important, but probably less so on single CPU x86 machines.

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.

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.

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.

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.

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...

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.

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 ! ! !

Hope that helps.

-kenn Received on Mon Jun 04 2001 - 02:48:57 CDT