Thinking of pre installation and post installation

Question

Hi,
I understand the following is very common question, but I need to know the answer specific to my case.
my case:
My production database has around 100 tables in a single database/instance (no clusterred yet); 3 of tables are growiing very fast, in less than 1 month can use more than 1TB hard disk space, and we have to keep 6 months' data (so in a half year, disk space will be used up 6-10 TB by these 3 tables; every day there are lots of operations on these tables, update, insert and query (no delete, every operation invoked heavy API stored precedure.
questions.
1. if applying cluster, installing in 2 nodes, 5 nodes, 10 nodes, can I expect linear performance increasing to 15%,18%,20%?
2. install nodes in one physical box (usiing vmware) better or 1 node 1 box better, in terms of performance?
3. afer installing Grid, the database install in one of those node or iin another box?
4. any doc telling how to install/configure the database upon cluster/nodes?
Thanks
John

Answer 1

992202 wrote:
Firstly install nodes, to be able to build up a cluster, on top of it, install multiple database instances, then we can configure a RAC database, which will still look like a single database from external client point of view.Correct. Grid installation first to build the cluster. Then RAC installation to provide a cluster database infrastructure across grid nodes. Then create a physical cluster database with a database engine on each cluster node.
now going to the point how I think and expect performance increasing against my case.
without clustered database (say in a standalone or singleton instance), executing 100 database operation (query, insert, update, by calling API, stored procedures) takes 5 minute; now in RAC database in which 5 nodes, 5 database instances in 5 physical machines, 100 operation may distribute to all nodes, namely each database instance may just need to handle 20 request (ideally); this way performance should be increased lots.Emphasis on should.
Yes, RAC provides for scalability. However, no cluster (RAC and anything else) is capable of simply taking any program (or stored procedure), and make that now run faster across multiple cluster nodes.
The program (stored proc or SQL in RAC's case) need to be able to run in parallel, deal with concurrency, and do this in a thread-safe way. The cluster provides the tools for this. The program needs to support or use these tools.
And, I also think, in 10 nodes cluster, it's better that installs 10 database instances than installing only 5, in terms of performance.Of course, you want to use all cluster nodes. But you can for example create server pools in the cluster and more than one cluster database - and run these on your cluster. A cluster does not necessarily mean only supporting a single cluster database.
A report shows CPU usage is very high constantly during executing (now we use 32 CPU in one box), however I/O and network usages look normal.Unlikely that a RAC will do better in this case - running processes within the same h/w boundary on 32 CPUs will usually be faster than running the same processing across 16 server nodes, with 2 CPUs per server.
Can I still expect linear performance increasing? if no, what can RAC database help me out, or any other way can help me my case?As I said - RAC provides incredible scalability (e.g. my biggest RAC does up to 35,000 rows inserts per second, and uses parallel processing to process 30+ million row data sets using several table joins in less than 120 seconds).
But for any cluster - scalability needs to be part and parcel of the software loads run on that cluster. If the workload of the software cannot be parallelised, if workloads are not designed to be scalable, then no amount of clustering will improve the runtimes of such workloads.
My suggestion is to first identify the CPU related performance problem you have. You need to know WHAT the problem is, in order to decide on how to address it. And whether RAC is a solution to the performance problem.