Subscribe to Blog via Email
So Brent Ozar’s group of geeks did something that I highly support- a survey of data professional’s salaries. Anyone who knows me, knows I live by data and I’m all about transparency. The data from the survey is available for download from the site and they’re promoting app developers to download the Excel spreadsheet of the raw data and work with it.
Now I’m a bit busy with work as the Technical Intelligence Manager at Delphix and a little conference that I’m the director for, called RMOUG Training Days, which is less than a month from now, but I couldn’t resist the temptation to load the data into one of my XE databases on a local VM and play with it a bit...just a bit.
It was easy to save the data as a CSV and use SQL Loader to dump it into Oracle XE. I could have used BCP and loaded it into SQL Server, too, (I know, I’m old school) but I had a quick VM with XE on it, so I just grabbed that quick to give me a database to query from. I did edit the CSV and removed both the “looking” column and took out the headers. If you choose to keep them, make sure you add the column back into the control file and update the “options ( skip=0)” to be “options ( skip=1)” to not load the column headers as a row in the table.
The control file to load the data has the following syntax:
--Control file for data -- options ( skip=0 ) load data infile 'salary.csv' into table salary_base fields terminated by ',' optionally enclosed by '"' (TIMEDT DATE "MM-DD-YYYY HH24:MI:SS" , SALARYUSD , PRIMARYDB , YEARSWDB , OTHERDB , EMPSTATUS , JOBTITLE , SUPERVISE , YEARSONJOB , TEAMCNT , DBSERVERS , EDUCATION , TECHDEGREE , CERTIFICATIONS , HOURSWEEKLY , DAYSTELECOMMUTE , EMPLOYMENTSECTOR)
and the table creation is the following:
create table SALARY_BSE(TIMEDT TIMESTAMP not null, SALARYUSD NUMBER not null, COUNTRY VARCHAR(40), PRIMARYDB VARCHAR(35), YEARSWDB NUMBER, OTHERDB VARCHAR(150), EMPSTATUS VARCHAR(100), JOBTITLE VARCHAR(70), SUPERVISE VARCHAR(80), YEARSONJOB NUMBER, TEAMCNT VARCHAR(15), DBSERVERS VARCHAR(50), EDUCATION VARCHAR(50), TECHDEGREE VARCHAR(75), CERTIFICATIONS VARCHAR(40), HOURSWEEKLY NUMBER, DAYSTELECOMMUTE VARCHAR(40), EMPLOYMENTSECTOR VARCHAR(35));
I used Excel to create some simple graphs from my results and queried the data from SQL Developer, (Jeff would be so proud of me for not using the command line… :))
Here’s what I queried and found interesting in the results.
The database flavors we work on may be a bit more diverse than most assume. Now this one was actually difficult, as the field could be freely typed into and there were some mispellings, combinations of capital and small letters, etc. The person who wrote “postgress”, yeah, we’ll talk… 🙂
The data was still heavily askew towards the MSSQL crowd. Over 2700 respondents were SQL Server and only 169 were listed their primary database platform as others, but Oracle was the majority:
Now the important stuff for a lot of people is the actual salary. Many folks think that Oracle DBAs make a lot more than those that specialize in SQL Server, but I haven’t found that and as this survey demonstrated, the averages were pretty close here, too. No matter if you’re Oracle or SQL Server, we ain’t making as much as that Amazon DBA…:)
Many of those who filled out the survey haven’t been in the field that long, (less than five years). There’s still a considerable amount of folks who’ve been in the industry since it’s inception.
Of the 30% of us that don’t have degrees in our chosen field, most of us stopped after getting a bachelors to find our path in life:
There’s still a few of us, (just under 200) out there who had to accumulate a lot of school loans getting a masters or a Doctorate/PHD, before we figured out that tech was the place to be…:)
The last quick look I did was to see by country, what were the top and bottom average salaries for DBAs-
Not too bad, Switzerland and Denmark… 🙂
I wish there’d been more respondents to the survey, but very happy with the data that was provided. I’m considering doing one of my own, just to get more people from the Oracle side, but until then, here’s a little something to think about as we prep for the new year and another awesome year in the database industry!