And to add, even yourself and somebody else posted on this thread agree..
http://groups.google.co.uk/group/comp.databases.oracle.misc/browse_frm/thread/82afa5ae6196114e/88ac9dc643514a55?lnk=st&q=oracle+deadlocks&rnum=10&hl=en#88ac9dc643514a55
--
Tony Rogerson
SQL Server MVP
http://sqlserverfaq.com - free video tutorials
"Tony Rogerson" <tonyrogerson_at_sqlserverfaq.com> wrote in message
news:dt83b6$b31$1$830fa79f_at_news.demon.co.uk...
> And another one....
>
> http://www.akadia.com/services/ora_locks_survival_guide.html
>
> Application developers can eliminate all risk of enqueue deadlocks by
> ensuring that transactions requiring multiple resources always lock them
> in the same order. However, in complex applications, this is easier said
> than done, particularly if an ad hoc query tool is used. To be safe, you
> should adopt a strict locking order, but you must also handle the ORA-60
> exception appropriately. In some cases it may be sufficient to pause for
> three seconds, and then retry the statement. However, in general, it is
> safest to roll back the transaction entirely, before pausing and retrying.
>
> Note, the owness on 'application developers', also note 'handle the ORA-60
> exception' appropriately.
>
> This advice is the same in ANY database, make sure objects are always in
> the same order when you are manipulating the data in them.
>
> You can avoid deadlocks in SQL Server exactly using the same methods and
> locking behaviour you use in Oracle 'period', I not sure as to what
> qualifies you to give the SQL Server advice - may be you have some
> experience or are justing repeating hear-say, most probably the latter.
>
> So you are now saying that Oracle installations need a DBA to work,
> actually that is my experience - its usually several though, thats
> definitely not true in the SQL Server world! The DBA role is vanishing
> quickly, their skills are moving more into Business Intelligence (comes as
> part of the SQL Server product) and some also do development, its mostly
> BI though.
>
> Anyway, we can keep going on with these exchanges; I've proved my point a
> couple of times that Oracle does have deadlocks and that you as a coder
> need to cater for them or certainly code round them.
>
> --
> Tony Rogerson
> SQL Server MVP
> http://sqlserverfaq.com - free video tutorials
>
>
> "Galen Boyer" <galen_boyer_at_yahoo.com> wrote in message
> news:ulkw8gr05.fsf_at_rcn.com...
>> On Sat, 18 Feb 2006, tonyrogerson_at_sqlserverfaq.com wrote:
>>> Here is just one from:
>>> http://www.orafaq.com/faq/RDBMS_Server/Internals/faq503.htm
>>>
>>> 1, "ITL shortage deadlocks"
>>
>> Yes, so increase them. A dba activity. Not something that the code
>> should check.
>>
>>> 2, High transaction activity on tables with bitmap indexes.
>>
>> And one shouldn't use bitmap indexes on tables that are involved in
>> high-transactions. Any Oracle 101 would tell you that. Those are for
>> Data warehousing.
>>
>>
>>> Would you like me find and quote more?
>>
>> I'd like you to find one, yes.
>>
>>> I'd say thats architecture, i doubt you would though or is the point
>>> where you backtrack and spout some other "factual" information?
>>
>> You haven't pointed out one time where one should put things in their
>> application code that check for deadlocks. I can find quote after quote
>> on how you must code it in SQLServer. The SQLServer newsgroups are
>> littered with them, most authored by the SQLServer MVPs.
>>
>>> Deadlocks can be avoided in any database system by coding properly.
>>
>> Not in SQLServer. They cannot be avoided no matter how you code the
>> application. You must, instead, check for them and react to them.
>>
>> Keep trying.
>>
>> --
>> Galen Boyer
>
>
Received on Sat Feb 18 2006 - 15:38:12 CST
