OraFAQ Forum: Performance Tuning » Performance Standard Edition without partitioning

Home » RDBMS Server » Performance Tuning » Performance Standard Edition without partitioning (Oracle 11g - RHEL 5)

Show: Today's Messages :: Polls :: Message Navigator
E-mail to friend

Performance Standard Edition without partitioning [message #511949]

Thu, 16 June 2011 04:31

pbaldanta
Messages: 1
Registered: June 2011

Junior Member

Hi everybody:

How many records could I have in a single table without performance degradation with Standard Edition without partitioning with cutting-edge server (8 or 12 cores, 72 GB RAM, FC 4 Gbit, etc...) and good storage?

300 Millions in only one table with 500K transactions / day is too much?

Simple database with simple schema.

How many records begin to be too many?

Experiences / examples?

Thanks.

Report message to a moderator

Re: Performance Standard Edition without partitioning [message #511951 is a reply to message #511949]

Thu, 16 June 2011 04:39

Michel Cadot
Messages: 68732
Registered: March 2007
Location: Saint-Maur, France, https...

Senior Member
Account Moderator

As far as you can store.
There is no too many.

Regards
Michel

Report message to a moderator

Re: Performance Standard Edition without partitioning [message #514168 is a reply to message #511951]

Sat, 02 July 2011 01:05

Kevin Meade
Messages: 2103
Registered: December 1999
Location: Connecticut USA

Senior Member

If your queries are only looking at the rows they need then the number of rows in a table is in many ways irrelevant since if your queries are looking only at the rows they need, then they are doing the minimum amount of work they can do regardless of how many rows they actually look at.

That said, there are ways to make some query operations faster using techniques that rely on limiting the number of rows being worked with during the operation (partitioning for example).

I would offer three liberal answers to your question of WHEN IS A TABLE TOO BIG:

1) your table is getting too big when accessing the table is taking longer as you add more rows to it.

2) your table is getting too big if maintenance operations are encroching upon your SLAs (backups are not finishing on time or row cleanup operations are not finishing on time).

3) your table is getting too big if partitioning strategies can be used to reduce your runtimes dramatically but you have failed to take advantage of them.

See how this aligns with

1) your normal day-to-day operations are suffering performance problems.
2) your support operations are suffering based on specific table sizes.
3) there is an opportunity you are not exploiting which could have helped you do better.

Notice that in these gross definitions of "A TABLE TOO BIG", I have not anywhere referenced a specific number of rows. TOO BIG is all about your pain level.

Where do you think you are at?

Good luck, Kevin

Report message to a moderator

Previous Topic:	Oracle hash join
Next Topic:	SQL tuning

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sun Jan 26 13:35:58 CST 2025