This year I had the privilege of work sending me to VMworld in Las Vegas. I have to say that it was quite the experience and much different than any other conference I have been to. There is just a tremendous community and the experience was great.

Lesson #1 Networking. The value of networking here is fantastic. It was great to meet and speak with some of the great bloggers. It was also a great oppurtunity to meet potential job candidates.

Lesson #2 Bring business cards. See #1 above. I learned this too late for this year and instead found myself tearing off pieces of paper. Not very fun or effecient.

Lesson #3 Hands on labs. These were a great oppurtuniy to play with some of the VMware and storage partners technology without having to build your own lab. My time these days is pretty limited so it was great to sit down for an hour at a time and try out some stuff that we might be interested in implementing.

Lesson #4 Speaker job titles. I found that the content of the sessions were directly correlated to what content was covered in the session. Marketing has its place and sometimes has some important info, however I thought the best sessions were from the architect level guys and those outside VMware. Those were the sessions where real world lessons were shared and discussed.

Lesson #5 Lack of sleep. Be prepared for a very whirlwind week and very little sleep. When there wasn’t something official going on there was probably some sort of community event happening. Each day it got tougher and tougher to get up in the morning. Trudge onward though and every minute is worth it.

Lesson #6 Pack light. I was way over packed. Next year I am going to pack much lighter. A duffle bag with a pair of pants, shorts, and a couple of t-shirts is plenty. You get a backpack with your conference pass so you can throw your stuff in it on the way home. Then use the duffle bag for all of the swag. There is lots of swag and your coworkers who did not get to go will appreciate you sharing.

So those are the things that immediately popped in mind as I set down to write this post. I have made a commitment to start blogging regularly again so I will expand on some of these later. If any of you have your own tips please share with everyone in the comments below.


, ,

Well some of you may have been wondering where I went. Most probably never noticed but I have been MIA for the last several months. A few months ago I took a new job within the same company. There were various reasons for doing so, but most of all it was a good fit and an exciting opportunity. So I am no longer a DBA. I am now a Systems Engineer for our private cloud team.

I have really enjoyed being a part of the SQL community and contributing my little part. While I won’t be blogging about SQL anymore, I do plan to start blogging about virtualization sometime soon.

See ya on the other side!
-Jeremy


Odd Log Shipping Job Failures

The other day I was troubleshooting an issue with log shipping where the copy and restore jobs were failing. Here is an example of the error for the copy job, which was also similar to the restore job.

2010-06-29 09:41:52.80 *** Error: Could not retrieve copy settings for secondary ID '[removed]'.(Microsoft.SqlServer.Management.LogShipping) ***
2010-06-29 09:41:52.81 *** Error: The specified agent_id BECBBCC0-6867-4398-BD96-830D62D88558  or agent_type 1 do not form a valid pair for log shipping monitoring processing.(.Net SqlClient Data Provider) ***

While it is not completely clear, this means that the copy job was not able to login to the instance and query the log shipping tables in MSDB. When I was first trying to gain access to the instance I had noticed that it was configured a bit strange. Basically they had a default instance and a named instance. The default instance was used as the secondary for log shipping while the named instance was being used for dev work. Well that part isn’t so strange… However they had an alias configured to redirect the server name to the named instance. So the log shipping jobs thought it was connecting to the default instance, it was actually connecting to the named instance. To work around this I just had to add the port number to the jobs as in the example below.

"C:\Program Files\Microsoft SQL Server\90\Tools\Binn\sqllogship.exe" -Copy BECBBCC0-6867-4398-BD96-830D62D88558 -server SERVER01,1433

,