In most of he databases that suffer a poor performance ,the issue is often caused by the slowness of a single table. A table that lacks indexes or statistics can be responsible for 90% of the total physical or logical reads.
In the past it was hard to determine that table. From version 9 Oracle created the view sys.segment_stats. This is a very powerfull view that shows the used resources per segment.
Below an enhanced SQL based on v$segment_statistics to determine the segment reads compared with the total reads in the database.

When a single segment takes more as 20% of the total reads that segment is a candidate for further tuning. Further tuning can be adding or modifying an index, evaluate the statistics or check the table highwater mark size.

This way of working has proven to be very successfull.
Also databases that do not have a known performance issue can benefit from this method. At the end of the day more tuned databases can run on 1 server, important for reducing the costs.
Only if the performance remains poor after looking at v$segment_statistics more sophisticated ways of tuning have to be followed

Best way of understandig the database sizing is a graph of the database including the different database segment types like: tables, indexes, temporary, rollback and empty space. Together these segment types represent the total database size. The example graphs below show that the empty space can be a significant part of the total database size. Also the tablespaces for Temporary and Rollback/Undo can be easily oversized.

examples graphs of database sizes :

• oversized Rollback /UNDO tablespace
• empty database allocating storage
• oversized indexes / unusual index/table ratio
• normal growth with oversized Rollback/Undo tablespace

Why is an oversized database an issue when disk space is cheap ?

A few common issues caused by oversized storage :
- File systems are almost full and hard to extend.
- The Storage Area Network is not always that flexable as expected.
- Overload of the backup systems.

Beside these technical reasons there is a very important reason to keep the database as small as possible. Total database size is one of the main criteria for many data centers to charge their clients for the database services. Big databases are charged more as small databases. Shrinking the database to an optimal size saves money. On top of that with such a database size graph a client can check easily if the database is oversized or not. If oversized he can negociate about a serious discount for the delivered database services.