Dissertation theme in MS SQL Server for a DBA

Question

Dissertation theme in MS SQL Server for a DBA

elea.grig

Ten Centuries

Points: 1231
More actions
September 12, 2018 at 11:45 am

#377297

In this forum I want to ask a question like this. I know it does not actually touch problems in MS SQL Server, but I am a DBA using MS SQL Server and I'd like to write a dissertation on a topic considering database administration. I'd like to write a useful system using TSQL scripts and I want to ask which themes and aspects do need research nowadays in administration theme?
Suggestions are very welcome in any topic.
Thanks for consideration.

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply

Grant Fritchey SSC Guru Points: 398909 More actions · Answer 1

I'd suggest focusing primarily in the area of DevOps. Automation as administration or administration through automation if you like. I think this is the area that is most challenging, most interesting, and where people need the most information.

"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

Jeff Moden SSC Guru Points: 1004406 More actions · Answer 2

Grant Fritchey - Thursday, September 13, 2018 6:10 AM
I'd suggest focusing primarily in the area of DevOps. Automation as administration or administration through automation if you like. I think this is the area that is most challenging, most interesting, and where people need the most information.

This is a bit of a sore spot with me... automation and administration isn't what DevOps is (IMHO). In fact, DevOps isn't a person, place, thing, or method. It's a culture. The culture can certainly lead to what you say but DevOps itself isn't one of those things... its "just" an awesome culture.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Grant Fritchey SSC Guru Points: 398909 More actions · Answer 3

Jeff Moden - Thursday, September 13, 2018 7:04 AM
Grant Fritchey - Thursday, September 13, 2018 6:10 AM
I'd suggest focusing primarily in the area of DevOps. Automation as administration or administration through automation if you like. I think this is the area that is most challenging, most interesting, and where people need the most information.
This is a bit of a sore spot with me... automation and administration isn't what DevOps is (IMHO). In fact, DevOps isn't a person, place, thing, or method. It's a culture. The culture can certainly lead to what you say but DevOps itself isn't one of those things... its "just" an awesome culture.

Agreed. No arguments from me. In fact when I present on this stuff, I spend more time talking about culture than I do talking tech. However... the conversation inevitably comes back around to tech and then it's all about automation.

"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

Jeff Moden SSC Guru Points: 1004406 More actions · Answer 4

Grant's suggestion is a good one but a keynote in the dissertation should include the fact that automation should never be used as a substitute for knowledge because if you don't no how to do things when the automation fails (and it will, eventually... just the nature of things), then you're soggy toast that has just landed butter side down on the floor.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

TomThomson SSC Guru Points: 104773 More actions · Answer 5

Jeff Moden - Thursday, September 13, 2018 11:44 AM
Grant's suggestion is a good one but a keynote in the dissertation should include the fact that automation should never be used as a substitute for knowledge because if you don't no how to do things when the automation fails (and it will, eventually... just the nature of things), then you're soggy toast that has just landed butter side down on the floor.

That may be a litte optimistic Jeff. The real worry if you don't know is that you may not realise that the toast than landed wrong side down would still have been wrong if it had landed the opposite way up, because the butter and marmalade layers were on opposite sides of the toasted bread layer. Yes, automate everything (I did, why waste my time doing things I could automate?) - but do include some sanity checks like making sure that where the toast is three-layered the butter layer is between the bread and the marmalade (or jam or preserve or whatever the third layer is).
Automation without aggressive search for errors is rather pointless, so it's not as easy and straightforward as some people think, and it needs monitoring unless you are the sort of genius that never makes a mistake (and people who think they are that sort of person are inevitably wrong, of course).

Tom

Jeff Moden SSC Guru Points: 1004406 More actions · Answer 6

TomThomson - Sunday, September 16, 2018 4:07 PM
Jeff Moden - Thursday, September 13, 2018 11:44 AM
Grant's suggestion is a good one but a keynote in the dissertation should include the fact that automation should never be used as a substitute for knowledge because if you don't no how to do things when the automation fails (and it will, eventually... just the nature of things), then you're soggy toast that has just landed butter side down on the floor.
That may be a litte optimistic Jeff. The real worry if you don't know is that you may not realise that the toast than landed wrong side down would still have been wrong if it had landed the opposite way up, because the butter and marmalade layers were on opposite sides of the toasted bread layer. Yes, automate everything (I did, why waste my time doing things I could automate?) - but do include some sanity checks like making sure that where the toast is three-layered the butter layer is between the bread and the marmalade (or jam or preserve or whatever the third layer is).
Automation without aggressive search for errors is rather pointless, so it's not as easy and straightforward as some people think, and it needs monitoring unless you are the sort of genius that never makes a mistake (and people who think they are that sort of person are inevitably wrong, of course).

I have to tell you that the automatic deployment of database code scares the hell out of me if that's all that is done. I can't think of a faster way to deploy bad code if there are no peer reviews and, like many shops do, go straight from Development to Prod with no QA or UAT. I'll take relatively-slow but sure over fast and who-knows any day.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

TomThomson SSC Guru Points: 104773 More actions · Answer 7

Jeff Moden - Sunday, September 16, 2018 10:27 PM
I have to tell you that the automatic deployment of database code scares the hell out of me if that's all that is done. I can't think of a faster way to deploy bad code if there are no peer reviews and, like many shops do, go straight from Development to Prod with no QA or UAT. I'll take relatively-slow but sure over fast and who-knows any day.

Well, I mostly agree with that - code should not get into production without extensive desk checking, peer reviews at several stages (starting with outline designe and architecture, before any code is actually written), thorough unit testing of all components, thorough system testing in development, clearance through QA, and complete review of how the code addresses error management (with separate reviews for error detection, error containment, error reporting, and error recovery where appropriate - but I think it's always appropriate), and clearance by QA. UAT should then be run by the users, not by QA or development, but when the users say the release/upgrade it passed UAT there UAT process should be reviewed by QA before final sign-off.
It'll still have problems, perhaps, but far less than stuff which isn't properly validated before release. I've been in places where I was allowed to run development on that basis, and also in places where the management wouldn't put up with that approach. And when I was young and inexperienced I failed to get peer reviews of design/architecture at the pre-code stage, but learnt not to leave that out after the first time it led to needing a significant rewrite after first release of the product (and that was when I decided to get thoroughly up to date on queuing theory, because for stuff involving a lot of data transfer by 1972 vintage telecomm facilities queuing theory was vastly more important than I had realised - and a review at the early design stage would have brought that out in time to avoid the mistake of not taking that part of the performance-maths into account).

Tom