The TAB of Doom

In the Session Browser, in the lower details section of the screen,
there is a tab labeled ACCESS. We are hoping you will rename it to
“DANGER” or “DOOM” or “DEATH AWAITS”. :wink:

For some reason, whenever (and it has happened at least once to every
DBA using the TOAD session browser… and more than once to most all of
us) when that tab is select on any of our production (or dev/test
clones, doesn’t matter. Just has to be a big DB) systems, the
corresponding process spins out of control. If left to its devices, it
will freeze Oracle on the server, and sometimes, even make it so that we
have to go to the console and reboot the machine. IF you hit CANCEL in
the first 1 or 2 seconds, you might be lucky enough to stop it before
the spiral of death. It will show the cancelling screen, but you are
still just waiting for the inevitable.

If you are quick enough to log on to the machine and kill the deadly
process (usually by blind luck, unless you have the SPID column showing
on the screen, you can most times halt the death march. If you aren’t
quick enough, then …

Am I too dramatic? I’m glad it isn’t Friday, cuz I’d have to use other
trite phrases like “walkin’ the plank” and “keel-haulin” to get my point
across. You can probably guess that I accidentally hit the tab today. I
brought the wrath of many on my head. My neck will be in a collar for
months.

Please, give me some relief!

David A. Hicken
UtahToad at gmail dot com
---------- Kiva.org - Make a Small Loan. Make a Big difference.
Change does not necessarily assure progress, but progress implacably requires change. Education is essential to change, for education creates both new wants and the ability to satisfy them.
– Henry Steele Commager

If you are quick enough to log on to the machine and kill the deadly
process (usually by blind luck, unless you have the SPID column showing
on the screen, you can most times halt the death march. If you aren't
quick enough, then ....

Am I too dramatic?

I hope so! I was just looking at that tab today on our 1TB dev 10.1.0.5 DB
with a 24GB SGA -- no issues (believe me, John D would know if I had
issues).

Any more details you can give on the Death Spiral? Sounds like if one were
to accidentally query V$ACCESS on their own that a similar fate would find
them, although that fate seems awfully severe.

Rich -- [TeamT]

Disclaimer: It's late. I'm running outta disclaimers for today.

This is one thing it is difficult to test/debug. Who wants to intentionally
bring the wrath of a company upon our heads!

This has happened several (4 or 5?) times since I've been with the company in 4
years, and it is consistent. I have seen results with that tab on a small
(gigabytes), less-used database, but our 11 TB production system and our 7 TB
companion system both have hit the road with that tab.

We all know that it is deadly for us, but accidents do happen (as I showed
today).

David A. Hicken
UtahToad at gmail dot com
---------- Kiva.org - Make a Small Loan. Make a Big difference.
It is much more comfortable to be mad and know it, than to be sane and have one's doubts.
-- G. B. Burgin

Rich Jesse wrote:

If you are quick enough to log on to the machine and kill the deadly
process (usually by blind luck, unless you have the SPID column showing
on the screen, you can most times halt the death march. If you aren't
quick enough, then ....

Am I too dramatic?

I hope so! I was just looking at that tab today on our 1TB dev 10.1.0.5 DB
with a 24GB SGA -- no issues (believe me, John D would know if I had
issues).

Any more details you can give on the Death Spiral? Sounds like if one were
to accidentally query V$ACCESS on their own that a similar fate would find
them, although that fate seems awfully severe.

Rich -- [TeamT]

Disclaimer: It's late. I'm running outta disclaimers for today.

Oh, and it has been the same with all versions that we've used here. Don't
remember where we started, but I am on 10.5.1.3 right now.

And I just remembered, but I don't have documentation to prove it, that it
happened at my previous job, too.

Could be the amount of user/data traffic, but like I said, I'm not going shoot
my foot.

David A. Hicken
UtahToad at gmail dot com
---------- Kiva.org - Make a Small Loan. Make a Big difference.
It is much more comfortable to be mad and know it, than to be sane and have one's doubts.
-- G. B. Burgin

Rich Jesse wrote:

If you are quick enough to log on to the machine and kill the deadly
process (usually by blind luck, unless you have the SPID column showing
on the screen, you can most times halt the death march. If you aren't
quick enough, then ....

Am I too dramatic?

I hope so! I was just looking at that tab today on our 1TB dev 10.1.0.5 DB
with a 24GB SGA -- no issues (believe me, John D would know if I had
issues).

Any more details you can give on the Death Spiral? Sounds like if one were
to accidentally query V$ACCESS on their own that a similar fate would find
them, although that fate seems awfully severe.

Rich -- [TeamT]

Disclaimer: It's late. I'm running outta disclaimers for today.

Hi David, It’s a pretty straightforward query that we execute when you
click that tab. Just a “select * from v$access where…”. How
many sessions are typically on your database at one time? If nothing else, I
could make a way to configure/hide the tabs of the session browser. Then you
could hide it so it would never be accidentally clicked again. -John From:
toad@yahoogroups.com [mailto:toad@yahoogroups.com] On Behalf Of David A. Hicken
Sent: Thursday, May 20, 2010 4:05 PM To: toad@yahoogroups.com Subject: Re:
[toad] The TAB of Doom Oh, and it has been the same with all versions that we've
used here. Don't remember where we started, but I am on 10.5.1.3 right now. And
I just remembered, but I don't have documentation to prove it, that it happened
at my previous job, too. Could be the amount of user/data traffic, but like I
said, I'm not going shoot my foot. --David A. HickenUtahToad at gmail dot
com---------- Kiva.org - Make a Small Loan. Make a Big difference.It is much
more comfortable to be mad and know it, than to be sane and have one's doubts.--
G. B. Burgin

Rich Jesse wrote:

If you are quick enough to log on to the machine and kill the deadly
process (usually by blind luck, unless you have the SPID column showing
on the screen, you can most times halt the death march. If you aren't
quick enough, then ....

Am I too dramatic?

I hope so! I was just looking at that tab today on our 1TB dev 10.1.0.5 DB
with a 24GB SGA -- no issues (believe me, John D would know if I had
issues).

Any more details you can give on the Death Spiral? Sounds like if one were
to accidentally query V$ACCESS on their own that a similar fate would find
them, although that fate seems awfully severe.

Rich -- [TeamT]

Disclaimer: It's late. I'm running outta disclaimers for today.

Many times we have in excess of 400-500 sessions connected to our database.
Perhaps it is because of WebLogic, and its connection pooling capability.
There might be several reasons. Being able to get rid of the tab would be
fine for me. I’m sure it serves a purpose for others, but the only purpose
it serves me is to force me to polish up my resume. – David A. Hicken
UtahToad at gmail dot com ---------- Kiva.org - Make a Small Loan. Make a
Big difference. To make pleasures pleasant shorten them. – Charles Buxton
John Dorlon wrote: Hi David, It’s a pretty straightforward query that
we execute when you click that tab. Just a “select * from v$access
where…”. How many sessions are typically on your database at one
time? If nothing else, I could make a way to configure/hide the tabs of the
session browser. Then you could hide it so it would never be accidentally
clicked again. -John

Hi David,

The tab just executes a simple query to V$ACCESS.
In a couple of my databases (10.2) these queries where very slow,
also when executed in SQL*Plus.

After generating statistics for fixed objects the query want back from

20sec to sub second!

Just perform as SYS-user (or let your DBA do it):

EXEC DBMS_STATS.GATHER_SCHEMA_STATS('SYS',GATHER_FIXED=>TRUE)

You'll be amazed! :slight_smile:

cheers,
Peter

Op 20-05-2010 22:41, David A. Hicken schreef:

For some reason, whenever (and it has happened at least once to every
DBA using the TOAD session browser... and more than once to most all of
us) when that tab is select on any of our production (or dev/test

Exactly – that’s why we post this on the Toad FAQ:

http://asktoad.com/DWiki/doku.php/faq/answers/database_versions#why_can_toad_some
times_seem_to_run_slower_on_10g

For example my Toad screen DB Probe took 45 minutes to do a refresh. I performed
the stats gathering – then screen took 1 second.

The problem is that many DBA’s do NOT know or understand that when the
optimizer switched from rule to 100% stats based – they are required to
collect stats on their SYS schema. The common belief by DBA’s is that
Oracle auto does this with the gather_stats job. They simply need to reed the
oracle docs – as there are dozens of ways for this job to not do
what’s expected, and even then it does not relieve the DBA from doing
proper database maintenance ….

Hi David,

OK, starting next beta, you can right-click on the session browser tabs, choose
“Configure”, then you’ll get the same dialog as you do in the
schema browser, where you can rename, rearrange, or hide tabs.

-John

Been doing that for years (well for quite a while, at least). But, as I referred
in the past, I’m not willing to test the hypothesis!

David A. Hicken
UtahToad at gmail dot com
---------- Kiva.org - Make a Small Loan. Make a Big difference.
A faithful friend is a strong defense, and he who has found one has found a treasure.
– Anonymous

Peter van Rijn wrote:

Hi David,

The tab just executes a simple query to V$ACCESS.
In a couple of my databases (10.2) these queries where very slow,
also when executed in SQL*Plus.

After generating statistics for fixed objects the query want back from
>20sec to sub second!

Just perform as SYS-user (or let your DBA do it):

EXEC DBMS_STATS.GATHER_SCHEMA_STATS('SYS',GATHER_FIXED=>TRUE)

You'll be amazed! :-)

cheers,
Peter

Op 20-05-2010 22:41, David A. Hicken schreef:
>
>
>
> For some reason, whenever (and it has happened at least once to every
> DBA using the TOAD session browser... and more than once to most all of
> us) when that tab is select on any of our production (or dev/test