DAX fallbacks

Martin PRESSLABER

Hi,

could you explain what DAX fallbacks mean in detail and how to avoid them? Or is it ok to have fallbacks?

Unfortunately googling does not help...

MANpage says: fallbacks == Number of commands completed by the software, which DAX could not complete

OK, but why and what does it mean for the DB?

Running RAC on M7 with InMemory:

1st node=DAX commands 35.608.411 with 18 fallbacks

2nd node=DAX commands 63.563.607 with 2.656.188 fallbacks

Is it just a bad day for the second node? Any ideas how I could dig deeper at OS or DB level?

Thanks in advance and regards

- Martin

Mike LaRosa -Oracle

Hi Martin,

This is the Sparc T-Series Server area, Looks like your asking about a DataBase function ?  can you add more details so we can try and move this to a better suited area for questions ?

What database application ?  what version ?

Thanks

Mike

Martin PRESSLABER

Hi Mike,

it is database related, but I am talking about a SPARC hardware feature:

Perhaps I could ask that question in an In-Memory database sections; but it is a hardware feature :-)

Thanks for your support and kind regards

- Martin

Martin PRESSLABER

That's also a good explanation:

https://swisdev.oracle.com/DAX/DAXwhatis.php

Regards M

Mike LaRosa -Oracle

Hi Martin,

Did some research, You are correct the DAX functionality is done in hw aka at the chip level....  back to your questions....

=== Caveat, These answers coming from a hardware guy, you may get more detail from the DB guys who code for this.

could you explain what DAX fallbacks mean in detail and how to avoid them? Or is it ok to have fallbacks?

MANpage says: fallbacks == Number of commands completed by the software, which DAX could not complete

=== As you found in the manpage,  simply telling us how many transactions DAX completed and how

=== many it did not aka fallbacks.

OK, but why and what does it mean for the DB?

=== It would seem node 2 may have hit the wall so to speak in DAX's capability and the fallbacks snowballed,

=== might be evidence that DAX does retry transactions....

Running RAC on M7 with InMemory:

1st node=DAX commands 35.608.411 with 18 fallbacks

2nd node=DAX commands 63.563.607 with 2.656.188 fallbacks

Is it just a bad day for the second node? Any ideas how I could dig deeper at OS or DB level?

=== suggest running this by the RAC/DB guys for more details on what DAX is doing and how to resolve this issue.

Martin PRESSLABER

Hi,

did an update to QFSDP Apr18 and now both nodes are using DAX with less fallbacks now:

n1 53.235.926 commands with 10 fallbacks

n2 33.866.192 commands with 18 fallbacks

And that within a week... seems that patching increased the usage, but it is very difficult to say, what queries took advantage from DAX...

But still I think that these 2 million fallbacks where an issue before... (without a negative effect, perhaps for the run time)

I will need to compare some AWRs ...

Any how... still very strange that it seems no one is knowing or caring about these DAX engines... but the idea behind is very very cool so I am wondering about that... ;-)

Thank you for your interest,

regards

- Martin

Mike LaRosa -Oracle

Morning,

Hoping someone here can answer Martin's questions more fully than I am able too

Thaanks

Mike

Martin PRESSLABER

Hi,

thanks for your support...

a good documentation would be enough... "fallback" does not sound good :-)

thx and regards

- martin