From: Henrik J. <hp...@gl...> - 2001-12-21 11:54:08
|
Frits Hoogland wrote: >still love the wait event option. > >some more remarks: >-my collegues use it on windows. >it crashes much. I know you do not put much energy in the windows version >(as I wouldn't do either), but a more stable version would be preferable as >they now can not run it. > I found a very handy tool for debugging crashes which gives me the line it crashed on when I get the 8 digit hexadecimal number that windows coughs up on a crash. I must however compile TOra with debugging turned on and the only release I've done that with so far is the 1.2.1 release (Since I didn't have a clue how to use it I didn't find a need to have this info). It will be in the 1.3.1 release, then I can start hoarding those crash addresses. What version are your Windows users using btw? >-global remarks regarding the server tuning options: >still the pointer turns to the clock if a refresh is specified. Thought it >was solved by a second connection? >al the already open tabs get a refresh. this is only necessary in tabs that >display changable data. options can simply not be changed, parameter changes >can more and more be done in higher oracle versions, but when searching for >a specific parameter, the screen gets refreshed. I find that annoying. > There are a few tabs that still may block the connection. These are the overview and the file I/O and the indicators view. The last one is only updated if it is being displayed so that isn't so much of a problem. I'll try to fix the last ones before the real 1.4.0 release (At least except for the indicators). >with statistics it is very annoying that it is refreshed. When someone >actually uses the statistics, they first going to sort it on name, value or >delta. it is -really- annoying when it is refreshed then. > I'll remove the automatic refresh for all views except the ones with charts in them. I've found this annoying myself. >when above mentioned adaptions are applied, the screens get better workable >on one hand, and have to fetch less data what helps performance on the other > >does the blocking locks tab work? > I think so, I tried it here by creating a few locks and they certainly showed up. Let me know if it doesn't. >-alert tool >My opinion is that the name is not well chosen. Everyone I show this tools >thinks it has something to do the oracle alert log. think of names like >'messaging channel' or something. > >The way it works is not that simple. think of auto-naming, with the option >to rename. something like oracleuser + machine name + numbering if the >combination of the two exists. > >It can be very handy if two tora users are working on a database and need to >share SQL in a simple way. > Ok, I can change the default name you listen to from TOra to something like that (Hmm, how do I get hold of the hostname on Windows). The usage you describe above isn't really what this was meant for, but it sounds like a good idea :). The reason it is called Alert Tool is that it uses the DBMS_ALERT package. I'm probably going to add an alert log viewer before 1.4, I'll try to find a better name for this. >-statistics manager >the statistics manager's viewpoint is from tables. indexes can -seperately- >be analyzed in oracle. think of a object name column, and a type column. > Sure. >-sga trace >haven't look much into this, but get much 'ora-942 table or view does not >exists EXPLAIN PLAN SET STATEMENT_ID='Tora 1.... etc. >-> if the plan table does not exists, as the user if tora must make it. >other tools can create it too (like tkprof) I saw this functionality one in >tora, but sometimes It doesn't do it. oh, wel lets look, the 942 is because >of the next point: >-> the explain plan statement does take the query, but does not put owner >name in front of objects in the from clause. so it sometimes can't find the >objects and gives the ora942. >or 'alter user set current_schema = xxx' > I had no idea you could do this. Will do. >-> all cursors ('sql text') that begin with 'begin' are anonymous sql >blocks. they can not be explained, suggestions for are a small message, or >a search through the package for sql-statements (which can be explained >using the exec.plan tab). > This is a really good idea. Especially since now with the SQL parser I've made for the auto indentation it is pretty easy to do. > > >merry xmas, >will mail more, but need to eat. > You to. /Mauritz GlobeCom AB |
From: Henrik J. <hp...@gl...> - 2001-12-21 14:42:34
|
Frits Hoogland wrote: > >-----Original Message----- >From: Henrik Johnson [mailto:hp...@gl...] >Sent: vrijdag 21 december 2001 18:51 >To: Frits Hoogland; Tora Mailinglist >Subject: Re: Wait event analyzer in TOra. > > >Frits Hoogland wrote: > >>still love the wait event option. >> >>some more remarks: >>-my collegues use it on windows. >>it crashes much. I know you do not put much energy in the windows version >>(as I wouldn't do either), but a more stable version would be preferable as >>they now can not run it. >> >I found a very handy tool for debugging crashes which gives me the line >it crashed on when I get the 8 digit hexadecimal number that windows >coughs up on a crash. I must however compile TOra with debugging turned >on and the only release I've done that with so far is the 1.2.1 release >(Since I didn't have a clue how to use it I didn't find a need to have >this info). It will be in the 1.3.1 release, then I can start hoarding >those crash addresses. What version are your Windows users using btw? > >win2k, winnt, win98 > I actually meant what version of TOra :). >>-global remarks regarding the server tuning options: >>still the pointer turns to the clock if a refresh is specified. Thought it >>was solved by a second connection? >>al the already open tabs get a refresh. this is only necessary in tabs that >>display changable data. options can simply not be changed, parameter >> >changes > >>can more and more be done in higher oracle versions, but when searching for >>a specific parameter, the screen gets refreshed. I find that annoying. >> >There are a few tabs that still may block the connection. These are the >overview and the file I/O and the indicators view. The last one is only >updated if it is being displayed so that isn't so much of a problem. >I'll try to fix the last ones before the real 1.4.0 release (At least >except for the indicators). > >>with statistics it is very annoying that it is refreshed. When someone >>actually uses the statistics, they first going to sort it on name, value or >>delta. it is -really- annoying when it is refreshed then. >> >I'll remove the automatic refresh for all views except the ones with >charts in them. I've found this annoying myself. > >>when above mentioned adaptions are applied, the screens get better workable >>on one hand, and have to fetch less data what helps performance on the >> >other > >>does the blocking locks tab work? >> >I think so, I tried it here by creating a few locks and they certainly >showed up. Let me know if it doesn't. > >no. doesn't on at least oracle version 7.3, 8.0.5, 8.1.6, 8.1.7. > I just tried this by doing a "delete from {table}" in two separate sessions. The second one will lock. Then I go into the blocking locks tuning tab and it clearly shows the locked session. Do you have an example that I can try that doesn't work? >>-alert tool >>My opinion is that the name is not well chosen. Everyone I show this tools >>thinks it has something to do the oracle alert log. think of names like >>'messaging channel' or something. >> >>The way it works is not that simple. think of auto-naming, with the option >>to rename. something like oracleuser + machine name + numbering if the >>combination of the two exists. >> >>It can be very handy if two tora users are working on a database and need >> >to > >>share SQL in a simple way. >> >Ok, I can change the default name you listen to from TOra to something >like that (Hmm, how do I get hold of the hostname on Windows). The usage >you describe above isn't really what this was meant for, but it sounds >like a good idea :). The reason it is called Alert Tool is that it uses >the DBMS_ALERT package. I'm probably going to add an alert log viewer >before 1.4, I'll try to find a better name for this. > >the hostname is fetched when looking at the machine column from the >v$session view. >what was the inteded meaning of the alerting tool? >how are you going to read the alert log? > First of all the name. How about "Alert Messaging". The DBMS_ALERT package can be used as a fast way to pass signals between two database applications. Regarding the alert log reading I was thinking about an application to make it easier to read the logs, you still need to pass the actual logfile to TOra since I don't know any way to read the alert log contents from within Oracle. >>-statistics manager >>the statistics manager's viewpoint is from tables. indexes can -seperately- >>be analyzed in oracle. think of a object name column, and a type column. >> >Sure. > >the view per schema makes sense, an option for all object would be handy, >not necessary. >an option to quickly see all analyzed objects and all not analyzed objects >would be handy also. > Ok. >>-sga trace >>haven't look much into this, but get much 'ora-942 table or view does not >>exists EXPLAIN PLAN SET STATEMENT_ID='Tora 1.... etc. >>-> if the plan table does not exists, as the user if tora must make it. >>other tools can create it too (like tkprof) I saw this functionality one in >>tora, but sometimes It doesn't do it. oh, wel lets look, the 942 is because >>of the next point: >>-> the explain plan statement does take the query, but does not put owner >>name in front of objects in the from clause. so it sometimes can't find the >>objects and gives the ora942. >>or 'alter user set current_schema = xxx' >> >I had no idea you could do this. Will do. > >suggest you try it first. I know the imp/exp utilities use (this is the >correct syntax:) >alter session set current_schema = <schema>; >the schema name must be given without quotes. > >very few tools have the capacity to generate a explain plan for each >statement that comes up in the sga. would be great. > >>-> all cursors ('sql text') that begin with 'begin' are anonymous sql >>blocks. they can not be explained, suggestions for are a small message, or >>a search through the package for sql-statements (which can be explained >>using the exec.plan tab). >> >This is a really good idea. Especially since now with the SQL parser >I've made for the auto indentation it is pretty easy to do. > >> >>merry xmas, >>will mail more, but need to eat. >> >You to. > >/Mauritz >GlobeCom AB > >it would be nice if the wait events can be monitored over a longer period of >time. >it's only necessary if it is stated explicitly. it is for monitoring >batchprocesses. I am not there at night (most of the time). > >I can give you help regarding tuning and internal oracle thingies. not about >plsql. > I think this is a good idea as well. It's quite a big change though so I'm not making any promises when I might get around to adding this. /Mauritz GlobeCom AB |