One simple way around the 'alter system' issue is to make a package that kills sessions and create it in a DBA user account. Then give people access to it. You can set it up so they can't kill the PMON fairly easily... to be safe. If you dont trust your non-oracle developers then you can set it up so they can only kill sessions with their name in it or the name of some connect user. Killing sessions all day long gets old... I'd rather try to find a way for them to do it. Guy Harrisons book is 'ok'. It's more of a how about trying this and a how about trying that than a real tuning book. The best one is SQL Tuning by Dan Tow. It's short, but it uses graph theory so its a very slow read. I dont think anyone other than a true database person would be willing to read it. I found one major error in Harrisons tuning book where he says to use pl/sql instead of some form of update(its been two years, I can't remember what exactly). Tested it in 8i and 9i and his way took twice as long. Leads me to wonder if everything in his book has been properly tested even though I only found one major error. It's still a worthwhile read. Unlike most people, I dont think SQL tuning is that big of a deal. This may raise some eyebrows, but my argument is that you can tune SQL either early in a life cycle or late and the cost is the same. However, if you do a poor design and you try to fix it late, you have to tear up alot of what you already did. Plus bad SQL is easy to spot. You want to get it right, but I think there are other priorities. During the last life cycle I was on, I was given about 200 SQL statements to tune during System Test Phase(test team seperate from the development team). Fixes were easy to make even though development and unit testing was over. The bigger concern was functionality. They often were not retrieving the correct pieces of data. -------------- Original message -------------- > This is an interesting question, where is the overlap between developers and > DBAs... > > After applications have been written and are in production, sometimes > developers want to administer the applications. > > That may or may not be appropriate, depending on your shop. > > The grey area begins when they want control over the underlying database. -- http://www.freelists.org/webpage/oracle-l