Is there a standard methodology for determining how much CPU, memory and disk space is needed to support an Oracle database with 500 million rows of sensor data (and counting) ? The system in question is a SCADA database gathering sensor data from hundreds of field devices on a daily basis. The same database is used for reporting and analysis (a watershed and wastewater management system for a major municipality).

  • 1
    It's more art than science. Oracle provides tools such as Database Replay that make it easier, but it still requires deploying a system and running a load test to see how it performs. Commented Jul 14, 2017 at 12:04

2 Answers 2


You can roughly calculate current disk space requirements by using guidelines from the Oracle documentation, once you have defined your schema, including the necessary indexes and materialized views, if any. Do not forget to add space for backups and archived logs.

As for the CPU and memory requirements, they would mostly depend on the exact characteristics of your workload, given the schema defined earlier. In this day and age you should be able to spin up a virtual server with one of the cloud providers and run your load tests (you do have a load test suite, right?) against it much faster than trying to find some magical generic formula on the internets.


Hundreds of devices daily is trivial. Oracle can handle hundreds of transactions per second, depending on the number of CPUs and the size of the instance (memory). In other words, CPU and memory is needed for handling high concurrency.

500 million rows can easily be calculated by various methods, and extrapolated for future growth. I would worry more about concurrent access to your storage, rather than size of storage. So you would need to invest in NAS at the very least, and have a storage array connected to oracle running in a preferably unix or linux environment (due to the scaling that you mentioned).

Oracle can very easily handle billions of rows per table. I know, because we have one 20 billion row table in our warehouse.

Also make sure you have an archive strategy in place, and before your tables grow too large, make sure they are partitioned!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.