1. Tuning SQL and PL/SQL - EagleEye contains all that you require to tune your SQL and PL/SQL within the one Worksheet. The worksheet allows you to format and compress your SQL to simplify the tuning effort, translate bind variables, trace your SQL, view execution plans, drill down to the underlying objects, obtain tuning advice, create outlines and much more.

1.1 EagleEye Worksheet  - The EagleEye Worksheet contains the complete set of Oracle hints and explains how to use each hint effectively. It has real world examples of where the hints have been used effectively at actual sites. There is also a Hot Tips Button where you can find the most common SQL Performance Problems.

1.2. Oracle SQL Tuning Advisor - The Oracle SQL Tuning Advisor provides a valuable insight into actions that can be taken to improve your SQL performance

1.3. Describe Tables - There are three methods of describing a table including keying in "d tname", or select tname and press F4 key on the worksheet where dname is the table/view. The other method is to click the Schema Browser Button.

1.4. Translating Binds Button - The "Translate Binds" button will translate binds within the worksheet. If you have copied a SQL statement from a trace, and are unsure of valid values to place into the SQL, the functionality will literally re-write the SQL to replace the bind with a literal.

1.5. Handling Binds Button - You can add new values to a bind variable in a statement.

1.6.  Becoming Another User -EagleEye has the capability to run SQL as another user. Even though you are logged on as EagleEye, you can view the execution plan and data retrieved as another user.

1.7. SQL History - You can see  the last 100 SQL statements that you have entered into the EagleEye worksheet. This includes SQL that was entered during previous logins.

1.8. Formatting SQL - If your SQL looks quite untidy and is difficult to read, you can format it by highlighting the SQL statement and pressing the "Format SQL" button.

1.9 Simplifying SQL Syntax - Some statements contain various sub selects and unions, which makes them hard to understand and tune. The EagleEye Worksheet has very useful functionality that allows you "close" the sub selects and see just the principal part of your statement.

2. Advanced SQL Tracing  - EagleEye provides a comprehensive "SQL Tracing" facility. It allows you to trace running database sessions. You can also trace your own SQL as part of SQL Tuning exercises to view the effect of changes to code/indexes/statistics and other changes. Once traced, SQL can be captured including the bind variables for replay.

2.1. Tracing from Top Session - This is extremely useful when you are unsure of the bind variables and/or SQL that a particular transaction is running.

2.2. Tracing from Worksheet - You can also obtain a trace file from the Worksheet screen.

2.3. Retrieving Trace Output -EagleEye has the ability to extract the trace file from the server and generate a detailed report, depending on the level of trace selected.
The Report contains information such as: SQL statement runtime, physical reads, buffer gets, the bind variables passed, runtime for each bind, the number of rows returned, the explain plan, the V$SQL_PLAN output (Oracle9i and later), the Wait Events that the SQL experienced and much more.

3. Replaying captured SQL

3.1. Capturing the Trace for Replay  - You can replay all of the Transaction's SQL. EagleEye will put all the SQL and bind variables into Suites. A suite is usually a single transaction, but may contain multiple transactions depending on how granular you wish to make your regression testing.  

3.2. Adding Transaction for Replay - For Test purposes, you may want to add SQL into a suite. You can add a statement manually.

3.3. Replay Transaction for Regression Test - Once you have captured your transactions, you can replay them for regression testing. You can run a Checkpoint before and after the change.
  
There are numerous adjustments that you can make to improve the performance of your transactions. These include:

3.4. Load Testing - Allows you to place load onto your system and to view the impact on your critical transaction response times. The load testing is often used in conjunction with regression testing to see the impact of a loaded system on the end user response times.

3.5. Script Manager - It is possible to share scripts amongst EagleEye users for any given database.

4. EagleEye for DBAs

4.1. Top Session  - Your users are complaining about performance and you need an expressway to find out who is causing the problem and what SQL they are running. The Top Sessions screen display lists the users in descending order of resource usage. Eagle Eye provides you with an option to right hand mouse click on the troublesome session to turn Oracle SQL*Trace on.
The top sessions screen also has a bar chart to show you the Session Id that is utilizing the most disk I/O and CPU on your database server. Perhaps there are a number of users hammering your database simultaneously. The graph will show you this at a glance.

4.2. SQL Button - Pressing the active SQL button allows you to view all SQL currently running on your database. It is sometimes difficult to view this information effectively from the Top Sessions screen.
The screen produces a V$SQL_PLAN in a similar format to the SQL*Worksheet. All Eagle Eye V$SQL_PLAN screens allow you to print a nicely formatted report that lists the SQL statement, along with the explain plan and other relevant details such as the statistics on the objects being referenced in the SQL and the indexes on the tables. You can also save the information into the clipboard, which allows you to copy and paste the information into your tuning report.

4.3. Diagnostic - This button contains a variety of tuning information, which can be accessed via a Sub menu provided when you press the button. The Diagnostic Menu contains information about: Shared Pool, Analyzed Tables/Indexes, I/O, Sort/ Temp Areas, Init. Ora Settings, Outlines, Alert Log.

4.4. Lock - Extensive locking information is provided including the session holding the lock and the session(s) requesting the lock.  Added to this, you can view the SQL that is associated with both the locking and locked sessions.