Author Archives: Jugal Shah

Unknown's avatar

About Jugal Shah

Jugal Shah has 19 plus years of experience in leading and managing the data and analytics practices. He has done the significant work in databases, analytics and generative AI projects. You can check his profile on http://sqldbpool.com/certificationawards/ URL.

Peer-to-peer transactional replication and conflict

Peer-to-peer transactional replication
Peer-to-peer transactional replication allows you insert, update, or delete data at any node in a topology and have data changes propagated to the other nodes.

Because we can change data at any node, data changes at different nodes could conflict with each other.

In SQL Server 2008, peer-to-peer replication introduces the option to enable conflict detection across a peer-to-peer topology. This option helps us prevent the issues that are caused by undetected conflicts.

When we enable conflict detection, a conflicting change is considered a critical error that causes the Distribution Agent to fail. In the event of a conflict, the topology remains in an inconsistent state until the conflict is resolved and the data is made consistent across the topology.

To use conflict detection, all nodes must be running SQL Server 2008 or a later version, and detection must be enabled for all nodes. You can enable and disable detection in Management Studio either by using the Subscription Options page of the Publication Properties dialog box or the Configure Topology page of the Configure Peer-to-Peer Topology Wizard.

You can also enable and disable conflict detection by using the sp_addpublication or sp_configure_peerconflictdetection stored procedures.
Syntax
sp_configure_peerconflictdetection [ @publication= ] ‘publication’
[ , [ @action= ] ‘action’]
[ , [ @originator_id= ] originator_id ]
[ , [ @conflict_retention= ] conflict_retention ]
[ , [ @continue_onconflict= ] ‘continue_onconflict’]
[ , [ @local= ] ‘local’]
[ , [ @timeout= ] timeout ]

sp_help_peerconflictdetection stored procedure returns information about the conflict detection settings for a publication that is involved in a peer-to-peer transactional replication
topology.

Unable to start execution of step (reason: The PowerShell subsystem failed to load [see the SQLAGENT.OUT file for details];The job has been suspended). The step failed.

Problem:
Unable to start execution of step 3 (reason: The PowerShell subsystem failed to load [see the SQLAGENT.OUT file for details];The job has been suspended). The step failed.

Cause of the failure: This is due to invalid location of SQLPS.exe file

Solution:

1. We can use the below script check the location of SQLPS.exe file.

SELECT * FROM msdb.dbo.syssubsystems WHERE start_entry_point ='PowerShellStart'

2. Go to the server and check whether the file ‘SQLPS.exe’ is located in the path as per step1.

3. There may be chance that the path is different on Node1 and Node2.

4. Find out the correct path of the SQLPS.exe and re-configure it using below command

Use msdb
go
sp_configure 'allow updates', 1
RECONFIGURE WITH OVERRIDE

/* Update to correct path
For example correct path is “D:\Server_apps\x86\MSSQL\100\Tools\Binn\SQLPS.exe” Than change it accordingly*/

UPDATE msdb.dbo.syssubsystems SET agent_exe='E:\Server_apps\x86\MSSQL\100\Tools\Binn\SQLPS.exe' WHERE start_entry_point ='PowerShellStart'

sp_configure 'allow updates', 0
RECONFIGURE WITH OVERRIDE

5. Confirm that SQLPS.exe file path has changed by running the below script once again

SELECT * FROM msdb.dbo.syssubsystems WHERE start_entry_point ='PowerShellStart'

6. Restart the respective SQL agent service. For the cluster server you have to use cluster administrator to restart the service.

7. Re – run the job.

SQL Server Upgrade Startegies

An upgrade is any kind of transition from SQL Server 2000 or SQL Server 2005 to SQL Server 2008.

Upgradation Startegies

In-place upgrade: Using the SQL Server 2008 Setup program to directly upgrade an instance of SQL Server 2000 or SQL Server 2005 to SQL Server 2008. The older instance of SQL Server is replaced.

  • Side-by-side upgrade: Using steps to move all or some data from an instance of SQL Server 2000 or SQL Server 2005 to a separate instance of SQL Server 2008. There are two types of side-by-side upgrade strategy:
    • One server: The new instance exists on the same server as the target instance.
    • Two servers: The new instance exists on a different server than the target instance.