Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««1234»»»

The Abstract DBA Expand / Collapse
Author
Message
Posted Monday, December 2, 2013 8:53 AM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Today @ 4:54 PM
Points: 23,298, Visits: 32,035
When I first started working with SQL Server I was also heavily involved with the hardware and OS (NT 4.0). I was the backup for our SysAdmin and helped build and rebuild our servers many times. Installed the OS, SQL Server, upgrades and patches. As time went on I found myself moved further away from the hardware and OS levels dealing exclusively with SQL Server. In many ways I miss working closer with the hardware and OS levels, as it helped me understand more of what was going on when we had problems.

I am hoping to get back some of that knowledge and experience as I look at setting up more of a test environment to work with at home.



Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
Post #1518922
Posted Monday, December 2, 2013 9:09 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 1:14 AM
Points: 5,339, Visits: 3,042
Lynn Pettis (12/2/2013)
When I first started working with SQL Server I was also heavily involved with the hardware and OS (NT 4.0). I was the backup for our SysAdmin and helped build and rebuild our servers many times. Installed the OS, SQL Server, upgrades and patches. As time went on I found myself moved further away from the hardware and OS levels dealing exclusively with SQL Server. In many ways I miss working closer with the hardware and OS levels, as it helped me understand more of what was going on when we had problems.

I am hoping to get back some of that knowledge and experience as I look at setting up more of a test environment to work with at home.


I do think that as more roles move away from dealing with the whole stack then we find it harder learning in our own time as we have to regain skills that have been put to one side and often disallowed involvement at work.


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1518930
Posted Monday, December 2, 2013 10:16 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 4:17 PM
Points: 1,651, Visits: 4,709
Gary Varga (12/2/2013)
Lynn Pettis (12/2/2013)
When I first started working with SQL Server I was also heavily involved with the hardware and OS (NT 4.0). I was the backup for our SysAdmin and helped build and rebuild our servers many times. Installed the OS, SQL Server, upgrades and patches. As time went on I found myself moved further away from the hardware and OS levels dealing exclusively with SQL Server. In many ways I miss working closer with the hardware and OS levels, as it helped me understand more of what was going on when we had problems.

I am hoping to get back some of that knowledge and experience as I look at setting up more of a test environment to work with at home.


I do think that as more roles move away from dealing with the whole stack then we find it harder learning in our own time as we have to regain skills that have been put to one side and often disallowed involvement at work.

Going forward, I expect there will increasingly more abstraction between the logical model of a database and the physical model. For example, we may see a UNIX version of the SQL Server kernel that not only integrates with Hadoop (project Polybase or SQL Server PDW), but also contains it's table space with the HDFS file system. For the DBA and developer, the environment for creating objects, writing T-SQL, or even tuning query execution plans could remain virtually unchanged, but the physical architecture that lay underneath could be significantly different.
http://gsl.azurewebsites.net/Projects/Polybase.aspx
Post #1518945
Posted Tuesday, December 3, 2013 3:11 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Tuesday, August 19, 2014 4:10 PM
Points: 50, Visits: 171
As a few respondents have mentioned, in regard to IT roles in general, larger organizations have to operate differently than smaller ones. When I worked for a global financial services company, the auditors were pretty strict. "DBAs Don't Do Data!!!" was the maxim (for the most part). If a DBA could control the database, control the access, and control the manipulation of the data, it could get pretty ugly. That would be too much power to reside in a single individual for a large company. Yes, I would design databases, review developers' SQL, and performance tune poorly running queries, but I would not write the queries -- the app developers were responsible for this. The closest we came to doing this was within a DBA utility or job. I am now in a smaller shop and sometimes I am called upon to write queries. So it really comes down to the size of the company and the culture.
Post #1519429
Posted Tuesday, December 3, 2013 6:56 PM


SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Today @ 9:18 AM
Points: 627, Visits: 2,168
jim.drewe (12/3/2013)
If a DBA could control the database, control the access, and control the manipulation of the data, it could get pretty ugly. That would be too much power to reside in a single individual for a large company.


I worked in a medium size bank for many years. I was the production DBA, the dev DBA on major systems (SQL, Oracle, etc.) as well as doing ETL between the stove-piped systems.

In the 10+ years we had only one high level embezzlement case. That also caused us to rebuild the whole Fixed Asset system. (He embezzled from a different source but built the FA system in his head and had no documentation.)

But the whole system we developed worked off the two "man" rule. Basically I would do whatever as commanded by the accountant. She had to verify it. The list of changes were written down.

But realistically if you hire people without honor, honesty, and respect -- they are going to find a hole in the system to exploit.




----------------
Jim P.

A little bit of this and a little byte of that can cause bloatware.
Post #1519456
Posted Wednesday, December 4, 2013 3:45 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 1:14 AM
Points: 5,339, Visits: 3,042
Jim P. (12/3/2013)
...But realistically if you hire people without honor, honesty, and respect -- they are going to find a hole in the system to exploit.


We could all do a lot of mischief but where is the fun in that?1 I could easily2 steal money, write digital graffiti, create a virus and so on. So could we all but because we all know we all can do any of it there isn't really any kudos to be had either.

1 I was tempted to pull a lot of cables out when I was left alone in Europe's biggest data centre (a security breach that should not have occurred). The employee of the large IT company bragged about the different clients' websites some of the machines were hosting. I could have made the news, perhaps globally, but for me the little chuckle to myself at that thought was more than enough.

2 Given a bit of time/practice/research etc. It's all out there on the internet - for some things there are even downloadable frameworks and utilities e.g. rootkits.


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1519548
Posted Wednesday, December 4, 2013 11:05 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Tuesday, August 19, 2014 4:10 PM
Points: 50, Visits: 171
The problem for most (if not all) bigger shops is offshore outsourcing. I had talks with my management (CTO level) concerning the risk of having non-employees, non-citizen offshore residents (meaning they come under a different legal system) having administrator rights to the database. So it really doesn't have anything to do with who **we** hire, but who the outsourcing company hires. Yes, there are legally binding contracts and there are company policies, but the risk of a rogue DBA running amok is a real possibility.

Let me give you an example. I was on a conference call one day discussing a database problem. I could tell from the telephone connection that one of the persons was not local -- also because I detected a southern Asian accent. After we wrapped up the call, I asked where he was from. I was familiar with most of the outsourcing centers in India. He responded "Lahore". Now I am not trying to broad-brush all Pakistanis, but Pakistan is not the model of political stability. I asked my CTO if there was any vetting of the individuals. He believed there was. But I am not talking about technical screening. What I am concerned about is terrorist screening. The CTO said he would take the matter up with the Chief IT Security Officer -- but nothing changed.

Think of all the mission-critical databases your enterprise has to maintain. Even with the best DR policies, there could be the prospect of a catastrophic event caused by a DBA that might threaten the existence of the company. What would happen if it took two weeks to recover? Most businesses would tell you they would have to shut their doors if they were honest.

Returning to our original discussion, audit is very important as the size of the enterprise grows. Sure, I would like to be trusted (and I am). But it is foolish to ignore the separation of duties.
Post #1519725
Posted Wednesday, December 4, 2013 11:28 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 4:17 PM
Points: 1,651, Visits: 4,709
jim.drewe (12/4/2013)
The problem for most (if not all) bigger shops is offshore outsourcing. I had talks with my management (CTO level) concerning the risk of having non-employees, non-citizen offshore residents (meaning they come under a different legal system) having administrator rights to the database. So it really doesn't have anything to do with who **we** hire, but who the outsourcing company hires. Yes, there are legally binding contracts and there are company policies, but the risk of a rogue DBA running amok is a real possibility.

Let me give you an example. I was on a conference call one day discussing a database problem. I could tell from the telephone connection that one of the persons was not local -- also because I detected a southern Asian accent. After we wrapped up the call, I asked where he was from. I was familiar with most of the outsourcing centers in India. He responded "Lahore". Now I am not trying to broad-brush all Pakistanis, but Pakistan is not the model of political stability. I asked my CTO if there was any vetting of the individuals. He believed there was. But I am not talking about technical screening. What I am concerned about is terrorist screening. The CTO said he would take the matter up with the Chief IT Security Officer -- but nothing changed.

Think of all the mission-critical databases your enterprise has to maintain. Even with the best DR policies, there could be the prospect of a catastrophic event caused by a DBA that might threaten the existence of the company. What would happen if it took two weeks to recover? Most businesses would tell you they would have to shut their doors if they were honest.

Returning to our original discussion, audit is very important as the size of the enterprise grows. Sure, I would like to be trusted (and I am). But it is foolish to ignore the separation of duties.

Any organization with an IT department large and funded enough to have a designated CTO and Chief Security Officer should also keep their database and network administrators in-house, well compensated, and on a short leash. You can out-source your web developers, your marketing team, payroll, help desk support, and even members of your executive management... but don't out-source (much less off-shore) they guys who hold the keys to your data. I'd much rather deal with the aftermath of a rogue graphic artist or accountant than I would a rogue database administrator.
Post #1519737
Posted Wednesday, December 11, 2013 7:48 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Tuesday, August 19, 2014 4:10 PM
Points: 50, Visits: 171
Eric ... I would heartily agree. Unfortunately, executives in publicly held companies listen to Wall Street, not the common sense from subordinates. If Wall Street says a particular metric is too low (or too high), the CEO sets the goals and barks out orders. You might at the higher levels get to ask questions for clarification, but you generally don't get to challenge the decision (I mean, you can, but that will last as long as you stepping in front of a train).

What it will take is for a calamity of the highest order to hit a major corporation before the investment bankers will include it on their checklist. Just as I used DR as an example in my previous post, there are plenty of companies which did not survive the 1993 World Trade Center bombing (the prelude to the 9-11 attack). Law enforcement wouldn't let people back in to their offices and there some small firms went out of business as a result of having no DR plan. After that, DR became a big deal and DR validation tests were mandated in many companies. After 9-11, some firms still were hit hard with poor DR planning. This same financial services company I worked for at time (located in lower Manhattan) went into insanity mode because of all the non-IT business departments in a location near Ground Zero had their own SQL Server database systems. They had offsite backup tapes, but no real DR plan. The insanity lasted for about a month restoring SQL Server databases (that we in IT didn't manage) in alternative locations.

Would top management have eventually seen the light without these disasters? Yeah, eventually, but not with the same urgency or sense of need. But to go back to your comment, I would agree that there are some IT functions that are too critical to outsource.
Post #1521911
Posted Wednesday, December 11, 2013 9:05 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 4:17 PM
Points: 1,651, Visits: 4,709
jim.drewe (12/11/2013)
Eric ... I would heartily agree. Unfortunately, executives in publicly held companies listen to Wall Street, not the common sense from subordinates. If Wall Street says a particular metric is too low (or too high), the CEO sets the goals and barks out orders. You might at the higher levels get to ask questions for clarification, but you generally don't get to challenge the decision (I mean, you can, but that will last as long as you stepping in front of a train).

What it will take is for a calamity of the highest order to hit a major corporation before the investment bankers will include it on their checklist. Just as I used DR as an example in my previous post, there are plenty of companies which did not survive the 1993 World Trade Center bombing (the prelude to the 9-11 attack). Law enforcement wouldn't let people back in to their offices and there some small firms went out of business as a result of having no DR plan. After that, DR became a big deal and DR validation tests were mandated in many companies. After 9-11, some firms still were hit hard with poor DR planning. This same financial services company I worked for at time (located in lower Manhattan) went into insanity mode because of all the non-IT business departments in a location near Ground Zero had their own SQL Server database systems. They had offsite backup tapes, but no real DR plan. The insanity lasted for about a month restoring SQL Server databases (that we in IT didn't manage) in alternative locations.

Would top management have eventually seen the light without these disasters? Yeah, eventually, but not with the same urgency or sense of need. But to go back to your comment, I would agree that there are some IT functions that are too critical to outsource.

What it will take is for a calamity of the highest order to hit a major corporation before the investment bankers will include it on their checklist. Just as I used DR as an example in my previous post, there are plenty of companies which did not survive the 1993 World Trade Center bombing (the prelude to the 9-11 attack).

If we need a calamity to use as an example for why database administrators should not be outsourced, I'd present as evidence Edward Snowden. This guy was not even a federal employee of the NSA, he as a contractor hired to manage the SharePoint website and file share network where the NSA held classified documents.
Post #1521953
« Prev Topic | Next Topic »

Add to briefcase ««1234»»»

Permissions Expand / Collapse