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

Kenn,

thanks for covering this. i'm going to chip in my half cents worth. (comments embedded)

"Kenn White" <kennwhite_at_hotmail.com> wrote in message news:6f933d26.0106032348.6b4ca3c1_at_posting.google.com...
> "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.
>

as i understand it, Advanced Security "secures" (encrypts/decrypts) only the Net8 traffic. all of our Net8 traffic is behind the firewall, and the majority of it is between the application servers and the database servers. AFAIK, Advanced Security does not encrypt/decrypt other traffic (for example, telnet sessions used by DBAs.) network security is important, but Advanced Security is not a comprehensive solution.

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

there are other third-party tools that do nearly the same job as well, or better.

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

parallel server is primarily a "high availability" solution. in order to take
advantage of the "high availability" of parallel server, applications have to be parallel server aware, detect the loss of the connection, connect to the second instance, losing any uncommitted transaction. this was with 8, new features may have been introduced with 8i.

there are a lot of other issues that impact 24x7 availability (table reorgs, index rebuilds, replication, application upgrades, etc.) that are not at all addressed by parallel server.

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

with Oracle8, i have used regular indexes to handle "skewed" data by deriving a new column (as you describe) for the specific values where the index will be populated for less than 10% of the rows, setting the column to NULL for the other 90%+ of the rows. without the overhead that bitmap indexes can impose on inserts/updates/deletes.

sometimes this has resulted in a significant performance boost, other times not. just drop the indexes that turn out to be of no benefit.

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

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 - 00:48:43 CDT