Fixing PRIMARY KEY constraint issues in SQL Server 2005 Replication

Wednesday, January 7, 2009(copied from: http://bassplayerdoc.blogspot.gr/2009/01/fixing-primary-key-constraint-issues-in.html) 

Fixing PRIMARY KEY constraint issues in SQL Server 2005 Replication

I must admit that I had to stay away from replication for quite a while since most of the work I've done in my previous job has a lot to do with disaster recovery. Nonetheless, I'm presented with new challenges every single day which I need to face. I got notified for an error regarding a transactional replication issue between two SQL Server 2005 instances. The error went something like this

Replication-Replication Distribution Subsystem: agent INSTANCE-db-Publication-SUBSCRIBER_INSTANCE-21 failed. Violation of PRIMARY KEY constraint 'PK_Whatever'. Cannot insert duplicate key in object 'dbo.table1'

The error message simply says that replication between the publisher and the subscriber could not push thru due to an existing record in the subscription that is causing a violation of the PRIMARY KEY constraint. Either a record is manually inserted in the subscriber or its just an annoying application which is not properly configured. Here's how you can fix this

1. Open Replication Monitor and check for the publication that is causing the error. You should see some error messages in the details that display something about the transaction sequence number, publisher id and command id values
2. Next, you retrieve the command associated with the transaction sequence number using the system stored procedure sp_browsereplcmds. This will return a result set of the replicated commands stored in the Distribution database at the Distributor. The query should look something like this

EXEC Distribution..sp_browsereplcmds @xact_seqno_start = '0x000B5103000043B7000700000000' ,@xact_seqno_end = '0x000B5103000043B7000700000000',@command_id =2 , @publisher_database_id = 1
This will give you an idea on the possible INSERT/UPDATE/DELETE statement that is inside this transaction. Based on the error message, we are looking at either an INSERT or an UPDATE statement.
3. Next, run a SELECT query on the subscriber instance against the table specified in the subscription passing the values you retrieved from the sp_browsereplcmds system stored procedure.
4. If the record already exists, simply delete the record since it will be written over by the replication (of course, this is not always the case and would depend on your business requirements)

This is just an overview of what you can do when you see such errors in replication. There are a few more articles and tips to help you get by from this website by Paul Ibison

vSphere Client over SSH Tunnel

ports 443, 902 and 903 forwarded to the Service Console IP on the host.

--BEGIN OF VMWARE SECRECY--

vshpere would NOT accept either localhost or 127.0.0.X in the login prompt !

you need to add a line to the C:\WINDOWS\system32\drivers\etc\hosts file:

127.0.0.1 esxserver

--END OF VMWARE SECRECY--


for more details, you may check: 

             TCP and UDP Ports required to access vCenter Server, ESX hosts, and other network components

GRUB2 hangs on "Welcome to GRUB!"

GRUB2 hangs on "Welcome to GRUB!"

Roberto Bifulco — Sat, 09/11/2010 - 21:42   ( http://robertobifulco.it/node/336 )

    edited by Elias Chatzigeorgiou :)  — Wed, 04/01/2012 - 19:30 ( http://elias-chatzigeorgiou.blogspot.com/2012/01/grub2-hangs-on-welcome-to-grub.html )

Today i played with debian "squeeze", that is currently under test and is the next Debian release. I encountered some problems while installing GRUB2 using the Debian Installer from a USB pen, infact i had to switch to a kubuntu live edition in order to install grub2 manually to enable the boot procedure without the live media (that in my case was again a USB pen).

Unfortunately on system reboot i found GRUB2 hang on the "Welcome to GRUB!" message. After some research on Google i came with this BUG: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594967

The problem is in the GRUB graphical console, so it was sufficient to:

1. boot the system again through the live distribution
2. mount the linux partition (e.g. /dev/sda5)

   mkdir /mnt/sda5
   mount /dev/sda5 /mnt/sda5
   

3. mount --bind /dev, /sys and /proc so that you will retain them after the chroot

   mount --bind /dev /mnt/sda5/dev
   mount --bind /sys /mnt/sda5/sys
   mount --bind /proc /mnt/sda5/proc 

4. do the chroot

   chroot /mnt/sda5
   

5. modify the configuration of GRUB2 (/etc/deafult/grub)  to uncomment GRUB_TERMINAL=console
6. update the GRUB configuration (update-grub)
7. reboot the system

Booting GRUB from text console solved the problem, and now the system is correctly working.

Here you can found a guide to configure/install GRUB from a live distribution, in case you need it: https://wiki.ubuntu.com/Grub2 (Recover GRUB2 via Live CD paragraph)