There is a great debate about the rapidly-falling costs of RAM and the performance benefits of full caching of Oracle databases. Let's take a closer look at the issues over large RAM data buffers, tuning by adjusting system parameters and using fast hardware to correct sub-optimal Oracle code:
Prior to Oracle9i, the only two cost-based optimizer modes were all_rows and first_rows optimization. One of the shortcomings of traditional first_rows SQL optimization was that the first_rows goal did not know the scope of the query and generally favored index access over full-table scans.
Sometimes it is a rouge query, sometimes a simple data clean up effort by the users, whatever may the cause be, inadvertent data-loss is a very common phenomenon. Backup and recovery capabilities are provided by the database management systems which ensure the safety and protection of valuable enterprise data in case of data loss however, not all data-loss situations call for a complete and tedious recovery exercise from the backup. Oracle introduced flashback features in Oracle 9i and 10g to address simple data recovery needs.
Prior to Oraclre10g, capturing wait event information was a cumbersome process involving the setting of special events (e.g. 10046) and the reading of complex trace dumps. Fortunately, Oracle10g has simplified the way that wait event information is captured and there are a wealth of new v$ and wrh$ views relating to Oracle wait events.
The performance-improvement process is an iterative, long-term approach to monitor and tune various aspects of a database. Depending on the result of monitoring, the DBA should adjust the configuration of the database server and make changes to the applications that use the database server. But before embarking on the journey to tune the database server, the Application itself should be tuned to remove inefficient sql code. So is there a method to the madness?
Managing large DML operations against a live database is one of the most common challenges Oracle professionals face on a regular basis. Such operations often cause serious performance problems and can cause inconsistencies in the data, especially when many referential integrity constraints exist among the tables. This article will explore how Workspaces can be used to solve these problems.
Oracle SQL tuning is one of the most important areas of Oracle optimization. This article explains how one can tune Oracle Full-table Scans.
Even Oracle Certified DBAs cringe at the thought of performing a real-world database recovery. As disk and hardware has become super-stable, many Oracle DBAs have never experienced the adrenaline rush of a full-blown Oracle recovery.
Many Oracle shops are plagued with slow I/O intensive databases, and this tip is for anyone whose STATSPACK top-5 timed events shows disk I/O as a major event.
With Oracle Database 10g, there are some new arguments available for the dbms_stats package subprograms. Those parameters are as follows: