SELECT name, create_date, modify_date
FROM sys.objects
Tuesday, October 5, 2010
Find the create and modified date of Database Objects
Query
Thursday, September 30, 2010
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.
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.
Saturday, August 14, 2010
Happy Independence Day (I Love my country India)
Tuesday, August 10, 2010
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.
[sourcecode language="sql"]
SELECT * FROM msdb.dbo.syssubsystems WHERE start_entry_point ='PowerShellStart'
[/sourcecode]
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
[sourcecode language="sql"]
Use msdb
go
sp_configure 'allow updates', 1
RECONFIGURE WITH OVERRIDE
[/sourcecode]
/* Update to correct path
For example correct path is “D:\Server_apps\x86\MSSQL\100\Tools\Binn\SQLPS.exe” Than change it accordingly*/
[sourcecode language="sql"]
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
[/sourcecode]
5. Confirm that SQLPS.exe file path has changed by running the below script once again
[sourcecode language="sql"]
SELECT * FROM msdb.dbo.syssubsystems WHERE start_entry_point ='PowerShellStart'
[/sourcecode]
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.
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.
[sourcecode language="sql"]
SELECT * FROM msdb.dbo.syssubsystems WHERE start_entry_point ='PowerShellStart'
[/sourcecode]
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
[sourcecode language="sql"]
Use msdb
go
sp_configure 'allow updates', 1
RECONFIGURE WITH OVERRIDE
[/sourcecode]
/* Update to correct path
For example correct path is “D:\Server_apps\x86\MSSQL\100\Tools\Binn\SQLPS.exe” Than change it accordingly*/
[sourcecode language="sql"]
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
[/sourcecode]
5. Confirm that SQLPS.exe file path has changed by running the below script once again
[sourcecode language="sql"]
SELECT * FROM msdb.dbo.syssubsystems WHERE start_entry_point ='PowerShellStart'
[/sourcecode]
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.
Tuesday, August 3, 2010
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.
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.
Thursday, July 8, 2010
MVP Award Kit
Resource System Database
The system objects are physically stored in the resource database, they are logically presented as the sys schema in each database.
The following code returns the build number of the resource database:
SELECT SERVERPROPERTY('ResourceVersion')
To return the date and time the resource database was last updated, the following code can be executed:
SELECT SERVERPROPERTY('ResourceLastUpdateDateTime')
The following code returns the build number of the resource database:
SELECT SERVERPROPERTY('ResourceVersion')
To return the date and time the resource database was last updated, the following code can be executed:
SELECT SERVERPROPERTY('ResourceLastUpdateDateTime')
Wednesday, July 7, 2010
Dedicated Administrator Connection (DAC)
SQLCMD is particularly useful for creating batch scripting jobs for administrative purposes. SQLCMD has replace OSQL. It is using OLEDB to connect the SQL Server. However, as an emergency utility to diagnose and hopefully correct server problems, it has no peer. By Using the –A argument, the SQLCMD utilizes an exclusive connection to SQL Server. If no other connection is possible, the SQLCMD –A command is the last and best hope for diagnosing server problems and preventing data loss. By default, only local DACs are allowed because the DAC components only listen on the loopback connection. However, remote DACs can be enabled using the sp_configure stored procedure by changing the remote admin connections option to true, as the following code illustrates:
sp_configure ‘remote admin connections’, 1
RECONFIGURE
sp_configure ‘remote admin connections’, 1
RECONFIGURE
Thursday, July 1, 2010
SQL Server Full Backup Internally
Q. What are the steps SQL Server performs internally at the time of FULL backup?
Ans. SQL Server follow the below steps once you execute the BACKUP command
1.Backup Process will lock the database and block all the transaction
2.Place a mark in the transaction log
3.Release the database lock
4.Extract all the pages in the data files and write them to the backup device
5.Lock the database and block all the transactions
6.Place a mark in the transaction log
7.Release the database lock
8.Extract the portion of the log between the marks and append it to backup
Q. Which operations do not allowed during the full backup?
1.Adding and removing database files
2.Shrinking the database
Ans. SQL Server follow the below steps once you execute the BACKUP command
1.Backup Process will lock the database and block all the transaction
2.Place a mark in the transaction log
3.Release the database lock
4.Extract all the pages in the data files and write them to the backup device
5.Lock the database and block all the transactions
6.Place a mark in the transaction log
7.Release the database lock
8.Extract the portion of the log between the marks and append it to backup
Q. Which operations do not allowed during the full backup?
1.Adding and removing database files
2.Shrinking the database
Subscribe to:
Posts (Atom)