Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

question about the ash_wait_chains script #30

Open
slavadba opened this issue Mar 26, 2021 · 1 comment
Open

question about the ash_wait_chains script #30

slavadba opened this issue Mar 26, 2021 · 1 comment

Comments

@slavadba
Copy link

slavadba commented Mar 26, 2021

Hi Tanel,

I have a question about the ash_wait_chains script.

https://drive.google.com/file/d/1hkvCbWN-5ofCv04rFubc_uISiCF4dWma/view?usp=sharing - the full output that it returned, and the picture there is as follows: session 433 has blocked many other sessions, and it is shown as idle. But just below there is this line

-> 433***3bk7zs1qb22p6 - > [idle blocker 1,2020,18565]

 i.e. it turns out that session 433  is blocked by session 2020.
 But why is this not shown in the chains for session 433?
 i.e. in my opinion, it should have looked something like this
 

 -> 2641***7aspktw7mn6w8 -> 3077***68t8xu5nfmw41 - >433***some_sql_id_or_null - > [idle blocker 1,2020,18565]
 -> 136***7aspktw7mn6w8 -> 3077***68t8xu5nfmw41 -> 433***some_sql_id_or_null - > [idle blocker 1,2020,18565]

 
 - and so on in the chains where 433 is set as the final blocker. Or its not possible for some reason?

With regards, Vyasheslav

@tanelpoder
Copy link
Owner

Hi Vyasheslav,

It would be useful to also see the program2||event2 columns to understand which process types and which events were involved in the blocking.

The ash_wait_chains script walks thought the waiting session chains one ASH sample at a time. So, depending on the nature of your application or the process types involved, session A may be blocking session B 50% of the time, but session B blocking session A the remaining 50% of time (or whatever the percentages).

You can zoom in to a single ASH sample (by selecting a very narrow time range) and you shouldn't see this pattern anymore.

There's one special case that I don't report yet: cyclic waits (that end up as deadlocks). That would also show a related pattern where during a single sample, A waits for B and B waits for A (until the deadlock detection forces a rollback for one session). I already use Oracle's CONNECT_BY_ISCYCLE in the script, but I currently don't print it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants