Frits Hoogland wrote:
If someone is hired as a performance monitorer and specialist, this is generally because of problems in a environment, and it is supposed to be the database that is generating the problem. in this scenario, the utmost care must be taken in not making the problems worst when researching on the database.
this leads to being as carefull as you can be in these environments. That is why it is my opinion that by clicking on buttons the screens must appear, but it must be manually turned on, so everyone can use just what he wants to use, and not that massive I/O is generated just because some clicked somewhere.
Good point. It's a bit late for the 1.2 release, but I'll add something like this for the 1.4 release.
ever wondered why DBA's hate it when developers are using TOAD in production sites? just because of the above standing reasons.
I don't know if in the schema browser, by clicking on the data tab,  ALL the data is fetched? It would be much better if only the number of rows that the screen can show is fetched, so full table scans are eliminated. This is one of the BIGGEST problems TOAD has which (i think) all dba's suffer from.
Even though TOra will do a "SELECT * FROM {table}" it will only read a specified number of rows until you scroll down (Default is 50). I hope Oracle is smart enough to not keep on reading this query when it is not read from again.
I know that making the wait events a seperate tab with the top statistics does ruin your current standard in the manual alterable selects.......
I have no problem making a new first page showing something like "essential statistics" and disabling all the other tabs until you click a button. What do you think should be on this page except for the events graph?

Even so I can tell you right now TOra does do some things that you will consider a bad idea in a production environment. They are (As I can recall them):

* It will do a "SELECT * FROM all_objects" and "SELECT * FROM all_synonyms" on connect. This cache is then used in many places in TOra to get information about what objects exists, most specifically for code completion and describing tables. I've been thinking about only starting to read the cache when it is needed the first time.

* It will open at least two connections to Oracle. One for diagnostics and for running SQL worksheet queries (Also used to read the object cache). If you open more than one worksheet it can open any number of connections, one for each running query. TOra will always try not to block the user interface to access Oracle.

Thats about it. Will try to at least add options to limit the influence of this. The most important would be to add an option not to read the object cache until it is first needed, come to think of it this is pretty easy and will be on by default. If you set this option on and start with tuning settings TOra would only open one connection to the database.

GlobeCom AB