Friday, February 25, 2011

Lessons learned from job hunting

These may be obvious, but I'm ranting on writing this to sum up some of my experiences of releasing my CV into the wild...

Recruiters...

Vary greatly
Some understand technology terms, others just match acronyms from your cv.

Love to talk
Well I don't. Not about the same stuff another recruiter told me 5 minutes ago anyway!
Email me the job spec as I don't have to slip out the office to talk to you all.

Have poor geography skills

Guildford and Sutton might both be in Surrey, but they are 23 miles apart. These locations are not interchangeable on a job advert.
Similarly, look at my home counties location before contacting me about 2 week contracts in Edinburgh or Belfast.

Are sparing with the truth
Queue a couple of interviews where the job role and my requirements were vastly different.

Are pushy ****ers
Which part of 'I'm not interested' don't you understand?

WILL send your CV WITHOUT your permission.
Even when asked not to.

Like to post fictitious roles to attract CVs
One recruiter even admitted this.

Like to take their time...
In responding to your communication, even though they expect the opposite behaviour from you.

Are slow to respond to polite requests
How many times have I asked you to remove me from your system?

Obviously the above rant cannot be leveled at ALL recuiters. Sadly though there exists a young, commission hungry and unscrupulous element who let the rest down. Parallels with the reputation of estate agents can be drawn.


London
Is a very expensive place. To commute to, to travel around, to get lunch in.
Money to compensate this has got to be good.


DBA
Is a 'catch all' job title.

At 3 different roles, it has been  -
  1. Development focused
  2. Maintenance focused
  3. Architecture focused
Maybe I can forgive recruiters a little as duties range so wildly...

Anyway, I've signed a new contract for an exciting new challenge in April, so all the above is behind me.
Phew! Breath deeply, and relax....

Thursday, February 24, 2011

TSQL : Removing a filegroup

Check no objects sit on the filegroup.
(If they do, then remove them)
SELECT i.*
FROM sys.indexes i
LEFT JOIN sys.filegroups AS fg
ON fg.data_space_id = i.data_space_id
WHERE fg.name = 'myfilegroup'

When all objects are gone, remove the file...
ALTER DATABASE mydatabase
REMOVE FILE mydatabaseFile

When the file has gone, remove the filegroup...
ALTER DATABASE mydatabase
REMOVE FILEGROUP mydatabaseFileGroup

Friday, February 11, 2011

Database Maintenance Checklist

Manually Check (Daily)
  1. SQL Server Logs
  2. SQL Agent Jobs
  3. Windows Event Logs
  4. Drive Space (unless you have a trustworthy tool/script that does so)

Automate these via Maintenance Plans / TSQL Agent Jobs -
  • Backups - Full
  • Backups - Transaction Log
  • Backups - Delete old backup files from file system
  • Indexes  - Rebuild vs Reorganise
  • Statistics - Update (if reorganising indexes)
  • History tables - Trim regularly
  • SQL Server Error logs - Cycle Regularly

Schedule them so they do not clash and are appropriate to the
  • RPO (Recovery Point Objective)
  • RTO (Recovery Time Objective)

Recovery Point Objective (RPO)
What time do we need to restore to? (acceptable data loss).
1 day / 1 hour / none

Recovery Time Objective (RTO)
How long is acceptable for data recovery to take? (in the event of issues)

Thursday, February 10, 2011

Using @@ROWCOUNT to test data existance

-- test data existence like this...

SELECT 1 FROM Staff WHERE DivisionID = @DivisionId
IF (@@ROWCOUNT > 0)
-- Data found
BEGIN
RAISERROR('Cannot delete Division, it has staff',16,1)
END

DELETE Division WHERE @DivisionId = DivisionId

Wednesday, February 9, 2011

Using @@IDENTITY to return an identity value

Returning an identity value...

-- given a table like this..
CREATE TABLE Division
(DivisionId INT IDENTITY(1,1) PRIMARY KEY,
DivisionName varchar(100))

-- retrieve ID like this...
INSERT INTO Division (DivisionName)
VALUES (@DivisionName)
SELECT @DivisionID = @@IDENTITY