Skip to Main Content
  • Questions
  • Oracle's RDBMS approach to sizing the database server ( versus MongoDB's approach )

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, John.

Asked: September 03, 2024 - 10:34 pm UTC

Last updated: September 04, 2024 - 2:47 am UTC

Version: 19c

Viewed 100+ times

You Asked

Greetings,

My question is in regards to Oracle's recommended process of sizing an Oracle database. When I have participated in sizing an Oracle server, we only estimated the table sizes using the field sizes multiplied by the total number of records. Then, we added 15% of the total table sizes for index space. Next, we ran a few simulated runs with test data. The focus was mostly to make sure that the server had enough disk space and total CPU didn't go over 50% for peak load. That was it. The steps I mentioned were provided by either Oracle support or our Oracle technical contact. Is there now an official Oracle whitepaper that states how an Oracle server should be sized?

I recently been asked to help size a Mongo server. In this case, I do have access to a MongoDB server sizing whitepaper-like. It recommends that we focus on making sure that the entire "working set" fits in memory. The "working set" is the amount of space used up by both the data and its indexes needed for processing "frequently accessed data". The "frequently accessed data" is the data that is needed by normal processing. I still don't know how to accurately determine that size since it doesn't go into much details. Does this sound like a good way to size an Oracle database server, too?

Thanks,

John

P.S. Here is Mongo's whitepaper-like approach: https://www.linkedin.com/pulse/mongodb-sizing-guide-sepp-renfer/

and Connor said...

I did a video a while back on choosing a server (focussed on Standard Edition) but a lot of the info also applies to any edition of Oracle



TL;DR:
- We don't charge for RAM or storage, so you may as well get a server with the fastest RAM/storage you can afford.
- We charge by core, so get the sockets with the fastest performance per core

Thus if I was buying a server, I'd be looking at what anticipated CPU demand is (eg, average active sessions). Once that yields a CPU selection, I'm simply getting as much RAM as a I can for that architecture. In the full scheme of things, the cost of RAM is ~zero.

In terms of official Oracle whitepapers, if you really wanted to get into a full planning exercise (eg, enterprise wide consolidation) then ACS provide a full engagement service for that

https://www.oracle.com/assets/acs-capacity-planning-1930756.pdf

Addenda:

With regard to Then, we added 15% of the total table sizes for index space, you might find a little light. Its not uncommon for indexes to be half of your database size (in a transactional environment, less for warehouses)