tag:blogger.com,1999:blog-8884584404576003487.post8813172105779754734..comments2024-02-29T09:43:12.251-05:00Comments on ORACLENERD: Good DBA, Bad DBA, Deadlockoraclenerdhttp://www.blogger.com/profile/12412013306950057961noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-8884584404576003487.post-3681156547741370042014-03-18T03:55:36.998-04:002014-03-18T03:55:36.998-04:00Application support/ developer support is not more...Application support/ developer support is not more related to the quality of DBA work than any other facet of DBA work.<br /><br />If the SLA for the specific DB involved includes application support and/or developer support then this is part of your work. If that is not the case then at best the trace file gets send to the devs. If they want support then they can buy it.<br /><br />The SLA is everything.cklammerhttps://www.blogger.com/profile/08483384774775424236noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-20911621859972378562011-10-15T16:13:06.225-04:002011-10-15T16:13:06.225-04:00Martin,
The DBA's responsibility is not to tr...Martin,<br /><br />The DBA's responsibility is not to train developers but to at least help them solve DB issues. Developers should be motivated to learn about the DB on their own once they understand the critical role the DB plays in any application.<br /><br />Regarding your suggestion to update all sets in ascending order of the DATA_SOURCE_ID, I'm afraid that's not possible because the deadlock didn't occur as part of a nightly batch job but as part of an online application that supports multiple concurrent users. Also, the DATA_SOURCE_ID column can't be sorted because it is loaded with a dreadful GUID. <br /><br />I mentioned on my story I don't examine trace files on a regular basis. Maybe that's why I was a "good DBA". If I have the misfortune to deal with the same issue many times I probably would not be as nice :)Enrique Avilesnoreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-13740983666691392632011-10-15T04:51:00.026-04:002011-10-15T04:51:00.026-04:00Interesting that the developer was able to get a t...Interesting that the developer was able to get a trace file. I'd expect anyone who is able to look there would be able to understand a deadlock.<br />Not sure how much the SQL was anonymized, but having an update on PERSON_TAB where the PERSON_ID is updated seems peculiar. I'd expect PERSON_ID to be the PK and so never updated. I'd wonder if they'd missed a predicate from the SQL.sydoraclehttps://www.blogger.com/profile/10404756950638119562noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-83510720592777272492011-10-13T07:50:46.852-04:002011-10-13T07:50:46.852-04:00Is it's the DBAs responsibility to train devel...Is it's the DBAs responsibility to train developers? I see the point to support developers at the best possible level, but I feel Narendras pain also quite vivid. <br />And the explanation is not helping to much at all, as the developer has no idea how to come out of the deadlock. (if he knew about deadlocks, he would never have written the email?)<br />what#s about a suggestion like <i>allways update all your sets in ascending order of <b>DATA_SOURCE_ID</b></i> ? <br />Or <i>if you want to manipulate many rows, insert the new values into a global temporary table and afterwards do an update based on this GTT</i>? SQL is a language for sets, so don't think sequential.Martin Bergerhttps://www.blogger.com/profile/16504572924713610305noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-91459923817797539672011-10-12T04:22:33.583-04:002011-10-12T04:22:33.583-04:00What would a bad DBA do if faced with the same req...<i>What would a bad DBA do if faced with the same request?</i><br />Are you sure? What if, a DBA has acted as a "good DBA" while handling deadlocks previously and when the deadlocks don't go away, decides that it is not worth his time to act like a "good DBA" ? :)<br />It happensNarendrahttps://www.blogger.com/profile/14645699853364658640noreply@blogger.com