SQL Standard or Enterprise

I'm just curious. Are most of the JDE SQL shops out there running SQL Standard or Enterprise...and why?

Also, are you guys running all your batch jobs directly on the SQL server or running them all on app servers and letting the SQL box concentrate on SQL Server?

Thanks

Ryan

Hi,

For me, I guess it would really depend on the company's financial position and needs...if they can answer the factors below then they would now know what to choose...

- Enterprise edition is expensive compared to Standard edition
- Does the company really plan to use the Enterprise edition features?
- Enterprise features adds additional resource usage

Separating the DB from the enterprise batch/kernel is the best performance scenario, as the jde kernels and runbatch eats way too much memory and cpu resource...

Hope this helps.

I have always been a great supporter of running DB on the same box as the Enterprise Server - 99% of the time they do not compete for the same resources and the local comms are way faster than going through any kind of network.

And to comment on the Enterprise edition, it's not necessarily about the visible features, it will also work faster than the Standard, because it has a number of invisible features - I will refer you to the MS site for more details without listing any such features here.

[ QUOTE ]
I have always been a great supporter of running DB on the same box as the Enterprise Server - 99% of the time they do not compete for the same resources and the local comms are way faster than going through any kind of network.

[/ QUOTE ]

I have to debunk this. Even though in theory this would seem that while running the database and JDE applications on a single box things would run faster, in practice the opposite is true. Otherwise, we'd all be recommending huge "all in one" servers, with the java application server, the database AND the server apps all running on one box.

I've written a number of posts in the past explaining how contention internally causes issues between switching - and the fact that by removing the application from the server ensures the ability to tune that server for a database only.

The only way that a company can correctly scale JDE for large numbers of users is to ensure that the physical three tier architecture is utilized. Now, if you then want to up the ante and purchase 10GB Ethernet for intet-server communications, or have multiple honed connections between your apps servers and your database, then that works as well. It's all money at that point!

Hi,

I'd also like to remark that SQL 2008 can run as a
native 64-bit application (going beyond 4 Gb RAM) while
JDE (on Windows) is a native 32-bit piece of code.

So, JDE will be RAM-limited while SQL won't.

If you install both JDE and SQL on a "big box", let's
say 24 Gb RAM and 8 CPUs, JDE will just use 1/6 of
the available RAM.

In that case, it's wiser to spread JDE load across
6 * 4 Gb RAM servers than wasting 24 Gb RAM.

Please, correct me if I'm wrong...

The major reason for running SQL 2008 Enterprise Edition is to take advantage of the compression feature in SQL. Using PAGE compression you can reduce the size of JDE_PRODUCTION by about 80%. (Millage varies depending on data distribution.) The real gain of compression though is the effect on performance. Since a 8K page now contains up to 80% more data fewer physical reads are required to service a given query. Since the data pages are compressed in memory as well there less chance of needing to go to disk in the first place. Many of our clients have seen batch run times drop by over 50% after implementing compression.

If your at Collaborate in April I'll be doing a session on this topic. Please stop by.

If you're a small client there is no problem with running both on the same box. This was typical for the Xe World and saved a lot of costs.

With modern hardware it's just as easy to take on big box and virtualize it so for small clients that also a good possibility.

Yes there is better scalability if you separate (not necessarily better performance at the low end) o it really depends on your size.

For 8.12 and 9.00 most installs end up with separation of servers.


Colin

Sebastian .......RAM limitations are per process not per server.

JDE has multiple processes so it is possible for it to go way above 4 GB on a system with the available memory.

ie you can be runnig a bunch of UBE's (runbatch.exe) that each consume up to 2 GB of RAM all at the same time.


Colin

Hi Colin,

Thanks for the clarification.

Sebastian

This is a bit of a religious question: there's little data to support either cause and very strong believes.

But I have once seen how moving the Enterprise Server to a separate (and bigger) box would make UBE's run ~3-5 times slower - we actually benchmarked a few. Perhaps what I saw then is no longer true, because this was in pre-GB network times and the networking overhead was really very prominent.

Indeed, with very large implementations the scalability concerns will take precedence, but for smaller implementations I still think it's a good approach.

Contention is not really that much of an issue, as the DB would mostly be waiting for the disk and JDE - for the CPU (unless it's waiting for the DB). So they rarely compete for the same thing.

Perhaps we could design a good test scenario and someone would be able to put it to test, to finally answer this question with science ;-)

Yes, the network is important. Doing 3 tier on 100mb Ethernet is painful. But we've had gigabit for more than 10 years now - and 10GbE is readily available.

I have some benchmarks from back in 1999 and 2000 demonstrating how a well tuned network can easily out scale an allinone configuration. Even UBE's can scale to run faster too - it's all about architecture and ensuring as parallel a process load as possible. Pre-gigabit is likely pre-xeon too!

Of course, a very small customer (less than 20 users) wouldn't see a big reason to move from an all-in-one box, but most customers are substantially larger than that - even SQL server ones !

[ QUOTE ]
This is a bit of a religious question: there's little data to support either cause and very strong believes.

But I have once seen how moving the Enterprise Server to a separate (and bigger) box would make UBE's run ~3-5 times slower - we actually benchmarked a few. Perhaps what I saw then is no longer true, because this was in pre-GB network times and the networking overhead was really very prominent.

Indeed, with very large implementations the scalability concerns will take precedence, but for smaller implementations I still think it's a good approach.

Contention is not really that much of an issue, as the DB would mostly be waiting for the disk and JDE - for the CPU (unless it's waiting for the DB). So they rarely compete for the same thing.

Perhaps we could design a good test scenario and someone would be able to put it to test, to finally answer this question with science ;-)

[/ QUOTE ]

Hi Alex,

I suppose my shop would be a good place to get results. We have every scenario covered. We have apps that have sql standard. We have apps with sql enterprise. We have tradional JDE architecture with the enterprise server running ubes and we have the newer architecture with the database being a seperate platform and all of the enterprise servers are seperate boxes.

To answer the original question, standard vs enterprise. For us it is decided based on the OS of the database server and what the needs are of the application that it supports. For JDE, it is always the enterprise edition of the OS and the enterprise edition of SQL so that we can scale out the memory and support many CPUs.

If we set up a database server to support a myriad of applications, we will use enterprise server as well. If we need to set up a dedicated SQL server for a small app or a test platform, we will go with sql standard and save the licence expense.

Our older XE systems follow the traditional architecture of running jde on the database server (for the primary enterprise server and the security server) with a constillation of ancenallary batch servers. Our 9.0 system has a seperate set of database servers and JDE on seperate boxes for the enterprise server.

Performance wise, I really haven't seen a huge boost in performance with a UBE running on the enterprise server vs a ube running on a beefy batch server. To Jon's point, we are using high end servers and gigabit or better networking, so there is no noticeable lag of performance from a batch server vs a traditional enterprise box.

On an entirely different note, this is go-live weekend for our 9.0 environment. On Monday morning, the very first Exadata/OVM/9.0 system goes live. No rest for the wicked, because the follow-on project that builds on that kicks off the following week. And we're off!

- Gregg

Thanks, that's helpful. And as real-life as you can get.

A real-life feel is often better than any lab numbers ;-)

BTW, I'm still hoping for those benchmarks...

... I meant the http://www.everestsoftint.com/ESIBenchmark2008.zip benchmarks of the Exadata server, I should have qualified...