Oracle DB Scalability [message #470405] |
Mon, 09 August 2010 15:09 |
prax_14
Messages: 64 Registered: July 2008
|
Member |
|
|
Dear Friends,
Off late few of our customers data have grown and started facing performance issue, we are also plaining for new features in our future release, where the database could grow to 150 billion records on some tables.
Please pour in your thoughts and suggestions for the following questions.
1) Will Oracle support having such a huge database and be scalable.
2) Will implementing some or all of the following items help.
a)Adding More Memory to the servers and increasing the SGA
b)Adding More storage space, better processor
c)Implementing Oracle RAC.
d)De-normalizing on some area's for performance.
e)Partitioning tables.
f)Using in memory cache features.
Please mention any other ways which will help and not mentioned in the above list.
I understand apart from all the above mentioned a proper database design is the platform to handle such a big database.
Any inputs and suggestions are highly appreciated.
Regards,
Prakash R
|
|
|
|
Re: Oracle DB Scalability [message #470409 is a reply to message #470408] |
Mon, 09 August 2010 15:37 |
prax_14
Messages: 64 Registered: July 2008
|
Member |
|
|
BlackSwan,
Thanks for your reply,What ever the numbers I have mention is just a estimate what our customers database could grow to in next few years. My question was, what are the things we need to put in to consideration to get ourself prepared to manage such a huge database in future.Sorry if I was not clear in my previous post.
|
|
|
|
|
Re: Oracle DB Scalability [message #470430 is a reply to message #470405] |
Mon, 09 August 2010 18:42 |
prax_14
Messages: 64 Registered: July 2008
|
Member |
|
|
BlackSwan/Mahesh,
Thanks for you replies.
Let me give a brief about the product I work on , Its not OLTP, Its all few windows services and some front end GUI which interface with the database.
SLA's is our support ppl are responsible for taking backup. Currently we have customers with 2 to 10 million record tables and the current back plan they have is working so far.
I definitely agree with the future estimate of database growing in billion they we will also have to come up with a solution for that. Any suggestions?
Can you also please help me understand on the following.
1) If using RAC is the not the right solution , how will RAC with Data Guard help? Is it because we can avoid backups as we will have a standby database with data guard?
2) Is there any other parameters we need to consider for designing a huge database like this.
For Example:
a) Switching to 64 bit Operating system
b) Switching the servers to Oracle recommended Solaris OS.
Any inputs is highly appreciated.
Thanks in advance.
|
|
|
Re: Oracle DB Scalability [message #470439 is a reply to message #470430] |
Mon, 09 August 2010 20:28 |
|
Mahesh Rajendran
Messages: 10708 Registered: March 2002 Location: oracleDocoVille
|
Senior Member Account Moderator |
|
|
>>1) If using RAC is the not the right solution , how will RAC with Data Guard help? Is it because we can avoid backups as we will have a standby database with data guard?
First, we never told RAC is not the right solution.
We said, RAC is meant for high volume transactions.
Say, your database needs to handle hundreds/thousands of transactions every second.
With RAC, you can mount the same DB in multiple nodes and enable load balancing.
If one node goes down, others will be still up and available.
If Database goes down, RAC is no use. You need a DataGuard like environment
where you can just failover.
So what I meant is, if your DB is critical enough for a RAC, use RAC and DataGuard.
>>Its not OLTP
Now you are using right buzzwords.
You still need to define whether it is a warehouse/hybrid/does ETL etc.
Look up the Oracle datawarehousing guide for a generic idea.
>>2) Is there any other parameters we need to consider for designing a huge database like this.
As BlackSwan already said,
huge/small means nothing to Oracle. If there a setting to be enabled for a DB of size more than xx Tb/Gb,
Oracle could have made it default.
It really depends on how you use the database.
Quote:
For Example:
a) Switching to 64 bit Operating system
b) Switching the servers to Oracle recommended Solaris OS.
what is the question here?
Are you worried about cross-platform migration?
I have used RMAN to migrate TB sized databases between different OS.
|
|
|
Re: Oracle DB Scalability [message #470810 is a reply to message #470405] |
Tue, 10 August 2010 19:36 |
prax_14
Messages: 64 Registered: July 2008
|
Member |
|
|
Mahesh,
Thank you very much for your replies, It was really helpful and I really appreciate it.
>>You still need to define whether it is a warehouse/hybrid/does ETL etc.
Yes It is a Hybrid Type.
Regarding My question "Is there any other parameters we need to consider for designing a huge database like this. "
What I meant was, is there any other design practices or Oracle feature that we need to consider for implementing a huge database like this.
Regarding the question
a) Switching to 64 bit Operating system
b) Switching the servers to Oracle recommended Solaris OS.
I saw some articles mention there is a limitation on the size of SGA (1.7GB) on a 32 bit operation systems, I was trying to get your opinion ,if it will be a good decision to switch to 62 bit OS to accommodate larger SGA for huge databases.
Thank you.
[Updated on: Tue, 10 August 2010 19:38] Report message to a moderator
|
|
|
Re: Oracle DB Scalability [message #470861 is a reply to message #470810] |
Wed, 11 August 2010 03:42 |
cookiemonster
Messages: 13959 Registered: September 2008 Location: Rainy Manchester
|
Senior Member |
|
|
prax_14 wrote on Wed, 11 August 2010 01:36Yes It is a Hybrid Type.
Regarding My question "Is there any other parameters we need to consider for designing a huge database like this. "
What I meant was, is there any other design practices or Oracle feature that we need to consider for implementing a huge database like this.
Not enough detail to comment, hybrid can mean all sorts of things.
Answers to these questions might help:
1) How many users
2) How many transactions per second/minute/hour
3) How much data is modified by the average transaction.
|
|
|