http://www.microsoft.com/learning/en/us/certification/cert-sql-server.aspx

2008 or 2012, up to you. If you work mostly with 2008, get the 2008 cert. If you work mostly with SQL 2012, get the 2012 cert

Since you'd only decrypt and fetch the columns when you need to decrypt then, no it doesn't make any sense to do that.

Page splits are caused by inserts into the middle of indexes and updates that grow the row, nothing else. They're internal to SQL.

As for thresholds, take them with a grain...

Table definition and easily usable data would be a great help, but this may be a start...

SELECT <stuff> FROM Policies p INNER JOIN PolicyDetails pd ON p.PolType = pd.PolType WHERE...

Table scan - read of the entire table

Table seek - no such thing

Index scan - read of the entire index

Index seek - search into an index for a specific value...

Sure, often a lot higher that what you have there.

Have a look in Books Online for the Unpivot keyword, that's what you're looking for here, probably followed by a Pivot.

Depends on the IO subsystem, memory, CPU, concurrent connections, etc.

Well, hopefully people will take my word for it...

We used to use , as the decimal marker, but that practice stopped many years ago (while I was still at school)....

Please ask new questions in a new thread. Thanks

Read less data (optimise queries), add memory, optimise the IO subsystem

Not unless you like doing your index maintenance twice.

PageIOLatch isn't a lock, it's a latch. Usually used when SQL is moving pages around from memory to disk or disk to memory. Probably you don't have enough cache memory...

Increase the frequency of your log backups.

Why on earth would you try to shrink a full log? Full means no free space left in the log, surely that would suggest...

I'd start by getting rid of the table variable. Any more advice than that will need the stuff Anthony asked for.