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.
 
[Frits Hoogland] 
No oracle is NOT smart enough to do so. In fact, TORA asks for everything (now "where" clause), so you get everything.... I think you make a lot of DBA's happy if it selects only as much as the screen, and depending on user action gets more...just think about it.
Ok I didn't know this. This is kind of a complicated change and I don't feel comfortable doing it in a release candidate. However, I will add a functionality to read lets say the first 1000 rows
from one query (Using ROWNUM < 1000) and if the user is interested in more it will reexecute a full scan of the table. This will help the problem a bit a least won't it?
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?
[Frits Hoogland] 
in my opinion there shouldn't be much more. I think of a rectangle in the upper 50% of the screen with some lines to see at what time what happened, and the lower part to enable and disable events. some events are so called "idle waits" (like a user session that's doing nothing, it gets "SQL*Net message from client", pmon and smon time their activities with their timers, "pmon timer" and "smon timer" are the result. etc. That's why i think it should be a tab that is not the first page, but somewhere at the other tabs. the first and second screens (tabs) are much prettier and attractive when enabled.
Mayby a remembered option to disable tabs in the statistics gathering would do the trick. This is also a pretty complicated change to make for the 1.2 release though.
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.

[Frits Hoogland] yep. in databases where there are a large number of objects it CAN degrade performance severely. Like oracle financials databases for instance. The method you are thinking about is much more intelligent
I'm testing this as I type and it will be in the 1.1.5 release and enabled by default.
* 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.

[Frits Hoogland] When I work with the tool, I'm spending much time in the objects screen (schema browser) and server tuning. those get their info from the same connection. that is why I get the "stopwatch". some of our customers are connected with low-bandwith lines, so it waits get worse, especially when several sqls are executed to provide info for the screens
I've just added an option to only allow UI blocking SQL to run in the main connection, this would move most of the statistics gathering to the other connection and also some of the browser stuff. Hopefully this should lead to a more responsive UI on slow connections. It will be in the 1.1.5 release.

/Mauritz
GlobeCom AB