Feeds:
Posts
Comments

Archive for September, 2011

While Loop

CREATE TABLE [dbo].[ID_Table](
	[Id] [bigint] NULL,
	[Name] [varchar](50) NULL
) ON [PRIMARY]

GO

DECLARE @INTX BIGINT
DECLARE @STRSQL NVARCHAR(400)

SET @INTX=1

WHILE (@INTX <= 100)
   BEGIN
      SET @STRSQL='INSERT INTO ID_Table VALUES(' + CONVERT(VARCHAR(50),@INTX) + ',' + CHAR(39) + 'NAME' + CHAR(39) + ')'
      EXEC(@STRSQL)
      SET @INTX=@INTX+1
  END
Advertisements

Read Full Post »

I got a question from Interview. Run the Truncate Command in Log Shipping Primary Database What are the impact will happen in Secondary database.

Truncate Command impacts will  forward to the Secondary Database. another question raised in your mind. since Truncate command is non logged command so how it will make a impact on second Database.

Truncate Table  command will not delete the data’s row by row basic. instead of  SQL Server just deallocating a pages from a table so this operation captured by a log file. when this log backup file will restore to the secondary database the same thing will happen in secondary database.

DBCC Log (<database name>,4)

Read Full Post »

This Post about  during log shipping configuration if we shall provide same location for backup  and copy job then what are the impacts will occur in log shipping?

Log shipping will be working fine with out any impacts. Copy Job not need when we using same location for backup  and copy job in log shipping.

Backup Settings

 

Secondary Database Settings

 History of Copy Job

 

 

Read Full Post »

TORN_PAGE_DETECTION 

Saves a specific bit for each 512-byte sector in the 8-kilobyte (KB) database page and stored in the database page header when the page is written to disk. When the page is read from disk, the torn bits stored in the page header are compared to the actual page sector information. Unmatched values indicate that only part of the page was written to disk. In this situation, error message 824 (indicating a torn page error) is reported to both the SQL Server error log and the Windows event log. Torn pages are typically detected by database recovery if it is truly an incomplete write of a page. However, other I/O path failures can cause a torn page at any time.

CHECKSUM

Calculates a checksum over the contents of the whole page and stores the value in the page header when a page is written to disk. When the page is read from disk, the checksum is recomputed and compared to the checksum value stored in the page header. If the values do not match, error message 824 (indicating a checksum failure) is reported to both the SQL Server error log and the Windows event log. A checksum failure indicates an I/O path problem. To determine the root cause requires investigation of the hardware, firmware drivers, BIOS, filter drivers (such as virus software), and other I/O path components.

Read Full Post »