January 27, 2010 at 2:53 am
Sounds like an SME?
I'd love to work for a company where the databases were my responsibility 😀 Lucky thing.
January 27, 2010 at 4:12 pm
I like to make poke fun at us SQL DBA's with our Oracle counterparts in the group. Once you admit to them that SQL Server is just a pretend database system then they lighten up quite a lot.
January 28, 2010 at 7:14 pm
Dave Schutz (1/21/2010)
I've found most of the problems we are discussing are not DBA problems; these problems exist in most business/technical areas. .....
if this is engineers forum, the title must be "How Do You Handle the Stress of Being an Engineer?".. 🙂
January 28, 2010 at 8:18 pm
Nicholas Cain (1/27/2010)
I like to make poke fun at us SQL DBA's with our Oracle counterparts in the group. Once you admit to them that SQL Server is just a pretend database system then they lighten up quite a lot.
Heh... do they like pork chops?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 28, 2010 at 8:22 pm
😛
Ben Moorhouse (1/25/2010)
Ha! So true Jeff!I've been working alongside another person in my team, and I keep having to solve stupid mistakes.
Such as records not being deleted even though I'm using the stored procedure correctly... oh yes, no where clause in one of the checks!
Having said that though, some other DBAs are awesome and it's nice to be able to fall back on their work.
Glad to see someone else have a similar problem. "Whiles and cursors and loops... OH MY!"
--Jeff Moden
Change is inevitable... Change for the better is not.
February 2, 2010 at 5:04 am
Drink Heavily 😉
February 2, 2010 at 5:08 am
hammerheaded (2/2/2010)
Drink Heavily 😉
Sounds like a very good plan today!
February 2, 2010 at 5:43 pm
I've found the key to relieving stress is to not let anything rattle me. Server down? It doesn't get fixed any faster if I'm stressing. I let things roll off my back and just keep my head down working at a steady pace.
If that doesn't work, drink like a fish 😀
February 3, 2010 at 1:48 am
I've recently found that keeping things structured and in writing helps me.
It allows me to have a couple of hours a week of stressful discussion about work and times, but then I can relax, get my head down and do good work with my target clear.
If issues arise, I deal with them based on priority, and then just document and provide updates on what happened.
Your boss shouldn't "have a word" with you if you didn't hit a deadline because something legitimately more important came up.
March 9, 2010 at 7:22 pm
My problem is that I was brought in as a DBA to administer and manager a very stressful OLTP system. However over the years I have began to take a more proactive approach. Realizing that my ability to succeed depends on me being able to control my platform I have begun a crusade across the IT department pushing the database as an api methodology. If I can get the application DAO's from talking directly to the schema it allows me to begin a normalization crusade within the system. By getting the application dependant on exposed stored procedures I only need to guarantee the availability of those items while optimization can be done behind the scenes. "And no development, we can't place another 10 indexes on our 100 million row 100 column wide orders table"! However I am one man against an entire development machine pushing new development down my throat all the time. Not to mention the ORM tool being used to code all sql and write the DAO objects at the same time. How do I get control of this and fight back?
March 10, 2010 at 1:10 am
I think you're absolutely right in what you're doing at the moment. By shifting data access to stored procedures rather than direct table access, not only can you make table changes without affecting the user (translating those change through the stored procedures), but you can also restrict access to the data at certain times or to specific user accounts, and even log how often each procedure is used!.
I'm afraid you're probably not going to be able to say no to people a) until you've proven that you know your stuff and have made big improvements, and b) without some serious evidence to back it up. It may be worth noting the effect the changes you're making are having on peoples queries, and then using that when it comes to proving your point.
It may also help you work if you have a database on which you can develop and test without affecting users, before running your code on the live SQL server (I dont know what setup you have at the moment).
March 10, 2010 at 4:07 pm
Thanks for the reply. Yes we most certainly do have staging and demo environments so I am going to move that direction. The problem is that there are so many political walls being created around how we handle data by those who don't even understand proper architecture or design. It's just about who has been here longer than the next person. Apparently that makes up for a lack of talent and understanding. We have many tables that don't even fit into 1st NF let alone 3rd. The other problem is that the whole data tier is currently handled via ORM tool that writes the sql and codes the data access objects. This is great for development because is allows them to not have to worry about writing sql however it also means the ORM tool can't make intelligent query decisions and it creates extremely chatty interfaces (IE 200 million queries) against our db platform every day! I am part of a very large privately held company and serve within one of their LOB's. Our LOB creates roughly 300 million in annual revenue. Ultimately I want to bring database development and dba work back into visual studio with 2008 database projects. Over time I need to get past the ORM tool and start development within visual studio. Anyway I appreciate your comment and would appreciate any more you may have that would help the process. How do you think we keep our system performing at a decent level? Lots of hardware and lots of indexing! Some of our largest tables have over 20 indexes on them! Not to mention the data distribution problems that occur within the stats because of non-normalized tables. This causes problems for the optimizer to continue and make good plan decisions. Well I am sure you can feel my frustration, but I will try to take hope and continue moving forward. Thanks.
March 11, 2010 at 2:32 am
200m queries?! flippin eck!
I'm assuming once they've finished hammering your database, they want it to produce the same query regularly in most cases?
We're looking at a similar problem and will be going down the route of agreeing a policy that the majority of users design the dataset they need (columns, filters etc.) and then we build a stored procedure to produce that for them. They wont have access to the tables.
Some users will need to make adhoc queries, we'll make sure that they understand SQL to a basic level and the implications of complex queries before letting the handful of users loose on the tables.
March 11, 2010 at 5:31 am
200 million queries... that's a poster child for the horrors of ORM. Yikes. Best of luck with your issues.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 11, 2010 at 7:07 am
A toast to birdmac1 for trying to do the right thing in the face of constant adversity and ignorance! I'm glad I'm not in your shoes but like they say, if you want to catch fish, go where there's fish!
Keep after them... if you need help, folks on this forum are very happy to help on a well formed question.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 61 through 75 (of 79 total)
You must be logged in to reply to this topic. Login to reply