Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2000 Forums
 SQL Server Administration (2000)
 Logshipping

Author  Topic 

ras2a
Yak Posting Veteran

66 Posts

Posted - 2005-11-24 : 10:16:52
Due to a recent disaster recovery situation, I've decided that we need an additional 'stand-by' server. Is this possible with Windows 2000 Server (std edition) and SQL 2000 Server (std edition)? I've been reading aobut logshipping...is this possible and how easy is it to setup?

Many thanks in advance peeps

Craig

drewsalem
Constraint Violating Yak Guru

304 Posts

Posted - 2005-11-24 : 10:43:27
It is possible with the SQL Server Standard Edition, but a bit of a headache compared to the EE:

[url]http://www.windowsitpro.com/Article/ArticleID/23231/23231.html[/url]
Go to Top of Page

chaitu1385
Starting Member

1 Post

Posted - 2005-11-24 : 23:51:31
Hi for logshipping
we require enterprise edition or developer edition.

http://support.microsoft.com/default.aspx?scid=kb;en-us;314515


Krishna Chaitanya.s
Project Engineer - SQL DBA
Go to Top of Page

ras2a
Yak Posting Veteran

66 Posts

Posted - 2005-12-01 : 12:04:42
Many thanks guys...sorry for taking so long to reply. I'd forgotten I posted this question - lol

cheers

ras
Go to Top of Page

Sitka
Aged Yak Warrior

571 Posts

Posted - 2005-12-01 : 15:04:14
Woo Hoo awesome topic,
ras2a, Do it man, do it!

nr from this site maintained some great stuff
http://mindsdoor.net/SQLAdmin/LogShipping.html

http://www.sql-server-performance.com/sql_server_log_shipping.asp

Truely if you want to advance your skills writing your own log shipping is a great way to do it.
Jobs, Backup, Permissions, Server renaming, Orphaned users, it's cheap and you will sleep like a rock.

"it's definitely useless and maybe harmful".
Go to Top of Page

ras2a
Yak Posting Veteran

66 Posts

Posted - 2005-12-08 : 09:20:04
Hi Sitka, thanks a lot mate :)

Once the new server goes up, I'll be testing this out.

cheers
Go to Top of Page

Sitka
Aged Yak Warrior

571 Posts

Posted - 2005-12-08 : 11:31:49
with reference to the sql-server-performance article.
I did a couple things different.
The author talks about logical backup devices.
I didn't need to establish them. Just used a TO DISK.

and made fancy names for the files based on date


CREATE PROCEDURE ls_backup

AS SET NOCOUNT ON

CREATE TABLE #dblist (IDxxx int identity(1,1), dbname varchar(255))

INSERT #dblist (dbname)
SELECT dbname FROM ls

DECLARE @ID int, @MAXID int
DECLARE @thisdbname varchar(255)

SELECT @MAXID = MAX(IDxxx), @ID = 0 FROM #dblist

WHILE @ID < @MAXID
BEGIN
SELECT @ID = MIN(IDxxx) FROM #dblist WHERE IDxxx>@ID

SELECT @thisdbname = dbname FROM #dblist WHERE IDxxx= @ID

DECLARE @localdirectoryname varchar(255)
DECLARE @filename varchar(255)
DECLARE @fulllocalpath varchar(255)

SELECT @localdirectoryname = 'F:\MSSQL\BACKUP\LSBackup\' + @thisdbname + '\'
SELECT @filename = @thisdbname + '_' + CONVERT(CHAR(10),GETDATE(),110) + '_' + REPLACE(CONVERT(VARCHAR(5),GETDATE(),108), ':','') + '.bak'
SELECT @fulllocalpath = @localdirectoryname + @filename

BACKUP DATABASE @thisdbname TO DISK = @fulllocalpath WITH RETAINDAYS = 2, INIT
WAITFOR DELAY '00:00:05'

DECLARE @cmd varchar(255)
SET @cmd = 'copy ' + @fulllocalpath + ' \\linkedSTANDBYSERVER\F$\MSSQL\BACKUP\LSBackup\' + @thisdbname
EXEC master..xp_cmdshell @cmd , NO_OUTPUT
WAITFOR DELAY '00:00:05'

DECLARE @sourcefilenameout varchar(255)
SELECT @sourcefilenameout = @filename
EXEC linkedSTANDBYSERVER.abdba.dbo.ls_backup_restore @dbnamels = @thisdbname, @sourcefilename = @sourcefilenameout

INSERT ls_files (lsfilename,createdate) VALUES (@fulllocalpath, GETDATE())

END

DROP TABLE #dblist


another thing that came around in my second version of this was
an Admin database, it's usefullness has been good, I keep utility procs from the great folks here, (a script library so to speak), and general IT network application stuff there to. This Admin database is where I built two support tables for the logshipping operations and keep the procs for the logshipping process. One table is merely a list of the databases that you do want to elevate to log shipping and the other is a list of files that are involved in the ongoing operations.

The first table is great because if you evey want to begin logshipping a database(rollout) you just add it to the list and make sure your destinations folders are where they should be. And often not all databases need this kind of recovery. For example we have two apps that use a model databases that never changes so no sense shipping those etc.

The second table really came into it's own with respect to disk space,
nice granular control of your files that you are leaving resident or going to tape on either machine. I keep two a days worth live on the live server (to tape nightly) and only one days worth on the standy, It really is short of disk space as it is real old and cramped and when the shit hits the fan I don't want to be looking for room.

Next is the configuration strings for many of our apps were just a bear to reconfigure. So I opted with the full server rename model to fail over. This is a little tricky because on 2000 the most effective way to do it is to fein a reinstall from the CD. Once you do it once you will get it, and it's fast.

Next proper domain interaction makes it all go much smoother.
Run the SQL AGENT and SERVICE under the same dedicated domain account you hopefully have set up for your main server. This clears up a lot of the token passing/impersonation issues jobs can have with network access.

Lots more stuff to but way worth it. I'm on a 30minute ship right now, takes about 6 minutes per. Full backup restore at night is about 45, then to tape.

On trial runs I was back online after the imaginary shotgun blast through the motherboard in about 25 minutes. (review some notes, rename, chase down some orphans) That I imagine would probably get quite a bit bigger in the heat of the moment. But still lots less than Ordering a new server and rebuilding or praying some kind of canned System restore stuff is gonna work when I'm not the one who configured it.

"it's definitely useless and maybe harmful".
Go to Top of Page

Sitka
Aged Yak Warrior

571 Posts

Posted - 2005-12-08 : 14:25:46
[code]


-- two little tables to act as lists for the log shipping process

CREATE TABLE ls (
dbname varchar (50) NOT NULL ,
lastfulldate smalldatetime NULL , --not used
lasttlogdate smalldatetime NULL , --not used
CONSTRAINT PK_ls PRIMARY KEY CLUSTERED
(
dbname
)

CREATE TABLE ls_files (
IDxxx int IDENTITY (1, 1) NOT NULL ,
lsfilename varchar (255) NULL ,
createdate smalldatetime NULL
)
--SELECT COUNT(*) from ls_files returns about 1000 at 2:30PM on 21 databases.


-- this is the log backup proc,
-- previous post is the full

CREATE PROCEDURE ls_backup_tlog

AS SET NOCOUNT ON

CREATE TABLE #dblist (IDxxx int identity(1,1), dbname varchar(255))

INSERT #dblist (dbname)
SELECT dbname FROM ls

-- huh? here's some old stuff that I left around from the days before I added tables
-- to drive the selectivity of the scripts
-- you get the idea (why hardcode the list?)
-- also note this was pre table variables SQL 7.0
--SELECT dbname FROM ls WHERE dbname IN ('logshipthisdatadase')
--SELECT * FROM #dblist
--DROP TABLE #dblist

DECLARE @ID int, @MAXID int
DECLARE @thisdbname varchar(255)

SELECT @MAXID = MAX(IDxxx), @ID = 0 FROM #dblist

WHILE @ID < @MAXID
BEGIN
SELECT @ID = MIN(IDxxx) FROM #dblist WHERE IDxxx>@ID

SELECT @thisdbname = dbname FROM #dblist WHERE IDxxx= @ID

DECLARE @localdirectoryname varchar(255)
DECLARE @filename varchar(255)
DECLARE @fulllocalpath varchar(255)

SELECT @localdirectoryname = 'F:\MSSQL\BACKUP\LSBackup\' + @thisdbname + '\'
SELECT @filename = @thisdbname + '_' + CONVERT(CHAR(10),GETDATE(),110) + '_' + REPLACE(CONVERT(VARCHAR(5),GETDATE(),108), ':','') + '.trn'
SELECT @fulllocalpath = @localdirectoryname + @filename

BACKUP LOG @thisdbname TO DISK = @fulllocalpath WITH RETAINDAYS = 2, NO_TRUNCATE
WAITFOR DELAY '00:00:05'

DECLARE @cmd varchar(255)
SET @cmd = 'copy ' + @fulllocalpath + ' \\linkedSTANDBYSERVER\F$\MSSQL\BACKUP\LSBackup\' + @thisdbname
EXEC master..xp_cmdshell @cmd , NO_OUTPUT
WAITFOR DELAY '00:00:05'


DECLARE @sourcefilenameout varchar(255)
SELECT @sourcefilenameout = @filename
EXEC linkedSTANDBYSERVER.abdba.dbo.ls_backup_tlog_restore @dbnamels = @thisdbname ,@sourcefilename = @sourcefilenameout

INSERT ls_files (lsfilename,createdate) VALUES (@fulllocalpath, GETDATE())

END

DROP TABLE #dblist
[/code]

"it's definitely useless and maybe harmful".
Go to Top of Page

Sitka
Aged Yak Warrior

571 Posts

Posted - 2005-12-08 : 14:39:21
And the procs that reside on the Standby server.

called from the SQL Jobs on the Live server.



CREATE PROCEDURE ls_backup_restore (@dbnamels varchar(255), @sourcefilename varchar(255)) AS

DECLARE @fulllocalpath varchar(255)

SELECT @fulllocalpath = 'F:\MSSQL\BACKUP\LSBackup\' + @dbnamels + '\' + @sourcefilename

DECLARE @a varchar(255)
DECLARE @b varchar(255)
DECLARE @c varchar(255)
DECLARE @d varchar(255)
DECLARE @e varchar(255)


SET @a = 'F:\MSSQL\BACKUP\LSBackup\' + @dbnamels +'\undo_'+ @dbnamels +'_logship.ldf'
SET @b = @dbnamels+'_Data'
SET @c = 'F:\MSSQL\Data\'+ @dbnamels +'_data.mdf'
SET @d = @dbnamels+'_Log'
SET @e = 'D:\SQL-Logs\'+ @dbnamels +'_log.ldf'

RESTORE DATABASE @dbnamels
FROM DISK = @fulllocalpath
WITH
DBO_ONLY,
REPLACE,
STANDBY = @a,

MOVE @b TO @c,
MOVE @d TO @e

INSERT ls_files (lsfilename,createdate) VALUES (@fulllocalpath, GETDATE())

WAITFOR DELAY '00:00:05'




CREATE PROCEDURE ls_backup_tlog_restore (@dbnamels varchar(255), @sourcefilename varchar(255)) AS

DECLARE @fulllocalpath varchar(255)
SELECT @fulllocalpath = 'F:\MSSQL\BACKUP\LSBackup\' + @dbnamels + '\' + @sourcefilename

DECLARE @a varchar(255)

SET @a = 'F:\MSSQL\BACKUP\LSBackup\' + @dbnamels +'\undo_' + @dbnamels + '_logship.ldf'


RESTORE LOG @dbnamels
FROM DISK = @fulllocalpath
WITH
DBO_ONLY,
STANDBY = @a


INSERT ls_files (lsfilename,createdate) VALUES (@fulllocalpath, GETDATE())

WAITFOR DELAY '00:00:05'



CREATE PROCEDURE ls_delete_old_backup_files (@timeoffset int = -20)

-- SELECT * FROM ls_files

AS SET NOCOUNT ON

DECLARE @backdate smalldatetime
SET @backdate = DATEADD(mi,@timeoffset,GETDATE())

DECLARE @ID int, @MAXID int
DECLARE @thisfilename varchar(255)

SELECT @MAXID = MAX(IDxxx), @ID = 0 FROM ls_files WHERE createdate < @backdate

WHILE @ID < @MAXID
BEGIN
SELECT @ID = MIN(IDxxx) FROM ls_files WHERE IDxxx>@ID AND createdate < @backdate

SELECT @thisfilename = lsfilename FROM ls_files WHERE IDxxx= @ID

DECLARE @cmd varchar(255)
SET @cmd = 'del ' + @thisfilename
EXEC master..xp_cmdshell @cmd , NO_OUTPUT

END

DELETE FROM ls_files WHERE createdate < @backdate




"it's definitely useless and maybe harmful".
Go to Top of Page

Sitka
Aged Yak Warrior

571 Posts

Posted - 2005-12-08 : 14:55:20
There is more to it than just that, but those are the
2 tables and 5 total procs I use,
In the jobs you can expand it as much as you want, send mail on success and stuff
I send to a netsend client, "log ship OK!" or "log ship failed"
which can happen (standby cord plug kick) But for some reason I have never had
the log backup or full back up on the live server fail. It depends how you set your job
to react at each step. With 21 databases and half hour log backups, and limited horsepower
resynching the whole mess is a bit of a pain and some database are getting up there 6 Gig.
So I just let it run through the night and the full resyncs it all again. That auto healing
is real nice.

Conceptually more stuff to come.

But this is pretty important to

quote:

RECOVERY
Instructs the restore operation to roll back any uncommitted transactions. After the recovery process, the database is ready for use.
If subsequent RESTORE operations (RESTORE LOG, or RESTORE DATABASE from differential) are planned, NORECOVERY or STANDBY should be specified instead.
If neither NORECOVERY, RECOVERY, or STANDBY is specified, RECOVERY is the default. When restoring backup sets from an earlier version of SQL Server, a database upgrade may be required. This upgrade is performed automatically when WITH RECOVERY is specified. For more information, see Transaction Log Backups .

STANDBY = undo_file_name

Specifies the undo file name so the recovery effects can be undone. The size required for the undo file depends on the volume of undo actions resulting from uncommitted transactions. If neither NORECOVERY, RECOVERY, or STANDBY is specified, RECOVERY is the default.
STANDBY allows a database to be brought up for read-only access between transaction log restores and can be used with either warm standby server situations or special recovery situations in which it is useful to inspect the database between log restores.
If the specified undo file name does not exist, SQL Server creates it. If the file does exist, SQL Server overwrites it.



I think I used No Recovery at first then switched to STANDBY, probably real proud of that at the time, kind of like getting the rust proofing.

"it's definitely useless and maybe harmful".
Go to Top of Page

Sitka
Aged Yak Warrior

571 Posts

Posted - 2005-12-09 : 08:55:26
Here is an explaination of renaming the standby server once the live one has taken the shotgun blast to the motherboard.

http://www.sql-server-performance.com/sql_server_maintenance.asp

halfway down, rename a server running SQL Server:

you have to practice this, it is easy but strange.

When the live server comes offline. I like to go into Active Directory and formally remove the computer from the domain.
Wait a minute or so then check the DNS records to make sure it's gone, then take the standby server and have it join a workgroup
reboot, again check the AD and DNS for it's old name.

The idea is that it's like neither of them ever existed. Then join the Domain with the original live name on the standby server and do what it says in the article to get the SQL name correct.

Also this is kind of a good way to upgrade hardware as well.

"it's definitely useless and maybe harmful".
Go to Top of Page
   

- Advertisement -