I typically use a ‘management’ server for most of my needs and have therefore written the script to use UNC type pathing for the primary as well as mirror server. You will also notice I defaulted several of the parameters. This is handy when working on a set of servers for multiple databases.

I hope you find the script useful. You can also find a copy of the script at www.scriptinganswers.com.

<#
	.SYNOPSIS
		Set up an SQL Server mirrored database
	.DESCRIPTION
		Backs up a database and tlog, copies it to the destination,
		Restores the database on the mirror server, sets up the partner,
		and starts the mirror.
	.PARAMETER  database
		The name of the database to be mirrored
	.PARAMETER  SourceServer
		The name of the primary server
	.PARAMETER  SourcePath
		Local Path for the backup
	.PARAMETER  DestServer
		The name of mirror server
	.PARAMETER  DestPath
		Local path for restore file
	.EXAMPLE
		PS C:\> Invoke-Mirror -database 'string value' `
			-SourceServer 'string\string' -SourcePath 'string' `
			-DestServer 'string\string' -DestPath 'string'
	.NOTES
		The SQL connections rely on Windows authentication and assumes Endpoints
		already exist. Error checking is minimal (i.e. no check is made to
		verify the recovery model is FULL).
	.AUTHOR
		John P. Wood
		07/28/2010
#>
Param(
	[Parameter(Mandatory=$true)]
	[string]$database,
	[string]$SourceServer='Server1\Instance',
	[string]$SourcePath='K:\SQL Backups',
	[string]$DestServer='Server2\Instance',
	[string]$DestPath='K:\SQL Backups'
	)
[Void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.ConnectionInfo")
[Void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.SMO")
[Void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.SmoExtended")
Function New-SMOconnection {
    Param (
		[string]$server
	)
	$conn = New-Object Microsoft.SqlServer.Management.Common.ServerConnection($server)
	$conn.applicationName = "PowerShell SMO"
	$conn.StatementTimeout = 0
	$conn.Connect()
	if ($conn.IsOpen -eq $false) {
		Throw "Could not connect to server $($server) for database backup of $($dbname)."
	}
	$smo = New-Object Microsoft.SqlServer.Management.Smo.Server($conn)
	$smo
}
Function Invoke-SqlBackup {
	$dbbk = new-object ('Microsoft.SqlServer.Management.Smo.Backup')
	$dbbk.Action = [Microsoft.SqlServer.Management.Smo.BackupActionType]::Database
	$dbbk.BackupSetDescription = "Full backup of " + $database
	$dbbk.BackupSetName = $database + " Backup"
	$dbbk.Database = $database
	$dbbk.MediaDescription = "Disk"
	$device = "$SourcePath\$bkpfile"
	$dbbk.Devices.AddDevice($device, 'File')
	$smo = New-SMOconnection -server $SourceServer
	Try {
		$dbbk.SqlBackup($smo)
		$dbbk.Action = [Microsoft.SqlServer.Management.Smo.BackupActionType]::Log
		$dbbk.SqlBackup($smo)
		$smo.ConnectionContext.Disconnect()
	}
	Catch {
		$ex = $_.Exception
		Write-Output $ex.message
		$ex = $ex.InnerException
		while ($ex.InnerException)
		{
			Write-Output $ex.InnerException.message
			$ex = $ex.InnerException
		};
		continue
	}
	Finally {
		if ($smo.ConnectionContext.IsOpen -eq $true) {
			$smo.ConnectionContext.Disconnect()
		}
	}
}
Function Invoke-SqlRestore {
	Param([string]$filename)
	$restore = new-object Microsoft.SqlServer.Management.Smo.Restore
	$restore.Action = 'Database'
	$restore.Database = $database
	$device = "$DestPath\$filename"
	$restore.Devices.AddDevice($device, 'File')
    $restore.ReplaceDatabase = $true
    $restore.NoRecovery = $true
	$smo = New-SMOconnection -server $DestServer
	Try {
		$restore.SqlRestore($smo)
		$restore.Action = [Microsoft.SqlServer.Management.Smo.RestoreActionType]::Log
		$restore.FileNumber = 2
		$restore.SqlRestore($smo)
		$smo.ConnectionContext.Disconnect()
	}
	Catch {
		$ex = $_.Exception
		Write-Output $ex.message
		$ex = $ex.InnerException
		while ($ex.InnerException)
		{
			Write-Output $ex.InnerException.message
			$ex = $ex.InnerException
		};
		continue
	}
	Finally {
		if ($smo.ConnectionContext.IsOpen -eq $true) {
			$smo.ConnectionContext.Disconnect()
		}
	}
}
Function Set-Mirror {
	Param([string]$server,[string]$database,[string]$partner)
	$conn = "Server=$server; Integrated Security=SSPI; Database=Master"
	$cn = New-Object "System.Data.SqlClient.SqlConnection" $conn
	$cn.Open()
	$cmd = New-Object "System.Data.SqlClient.SqlCommand"
	$cmd.CommandType = [System.Data.CommandType]::Text

	$cmd.CommandText = "ALTER DATABASE $database SET PARTNER = 'TCP://" + $partner + ":5022'"
	$cmd.Connection = $cn
	$cmd.ExecuteNonQuery()
	$cn.Close()
	Trap {
		$ex = $_.Exception
		Write-Output $ex.message
		$ex = $ex.InnerException
		while ($ex.InnerException)
		{
			Write-Output $ex.InnerException.message
			$ex = $ex.InnerException
		};
		continue
	}
}
$srcUNC = Join-Path "\\$($SourceServer.Split('\\')[0])" $($SourcePath.Replace(':','$'))
if (-not(Test-Path $srcUNC)) { New-Item $srcUNC -ItemType directory | Out-Null}
$destUNC = Join-Path "\\$($DestServer.Split('\\')[0])" $($DestPath.Replace(':','$'))
if (-not(Test-Path $destUNC)) { New-Item $destUNC -ItemType directory | Out-Null}
$bkpfile = $($SourceServer.Replace("\", "$")) + "_" + $database + "_FULL_" + $(get-date -format yyyyMMdd-HHmmss) + ".bak"
Invoke-SqlBackup
Copy-Item $(Join-Path $srcUNC $bkpfile) -Destination $destUNC -Verbose
Invoke-SqlRestore -filename $bkpfile
# Establish Mirroring from the mirrored database
Set-Mirror -server $DestServer -database $database -partner $($SourceServer.Split('\\')[0])
# Start the mirror
Set-Mirror -server $SourceServer -database $database -partner $($DestServer.Split('\\')[0])

I recently found the “Jobs” cmdlets in Powershell V2.0. With “Jobs” you can asynchronously process multiple tasks (e.g. copying backups from many remote machines to data storage on the current local machine). In my case, running the copies synchronously results in the process spanning over to the next morning. Backups are stored daily. If a backup is taken on Wednesday, I can’t have it being stored in our warehouse under Thursday.

Using Powershell “Jobs”, I can accommodate copying all the backups within the daily timeframe. However, I did wrestle with using “Jobs” at first. Mainly because I couldn’t see what happened with a JOB on my console! The trick is to make sure you issue a Receive-Job cmdlet after a JOB has finished.

Here a a couple of examples to try:

These example assume you are running Powershell V2.0 and you have enabled remoting on the machine your running this. Remoting does not have to be enabled on the remote servers but must be enabled on your local machine.

Begin with a simple copy you know works.

# Copies a directory and all files and sub-directories, I would
# suggest using something small to quickly see results
$source = "\\RemoteServer\d$\Backups # your remote path
$target = "W:\WoodyzTest"            # your local path
Copy-Item -Path $source -Destination $target -Recurse Verbose

Next, we’ll take the Copy-Item and put it in a Start-Job

$source = "\\RemoteServer\d$\Backups # your remote path
$target = "W:\WoodyzTest"            # your local path
$job Start-Job -Scriptblock {
Copy-Item -Path $source -Destination $target -Recurse -Verbose
}
Wait-Job $job  # For this test, we’ll wait for the job to complete

Run the above script, look at what is returned in the console, and then check to see of the copy worked.

Surprise! The directory was not copied! What happened? I have no idea because I did not see anything in the console. There were no error messages!

OK, let’s now add a Receive-Job

$source = "\\RemoteServer\d$\Backups # your remote path
$target = "W:\WoodyzTest"            # your local path
$job Start-Job -Scriptblock {Copy-Item -Path $source -Destination $target -Recurse -Verbose }
Wait-Job $job  # For this test, we’ll wait for the job to complete
Receive-Job $job  # will now display any results from the job

Now what do you see on the console? We have yet another surprise! The console shows we have an error in our Copy-Item. But why? It worked before when we ran it outside of a JOB.

I took a SWAG at it and decided to try enclosing the entire original script inside the JOB Scriptblock:

Here is the entire, final, working script:

$job = Start-Job -ScriptBlock {
    $source = "\\Lcfltr01\d$\SQL Backups\lcfltr01"
    $target = "W:\WoodyzTest"
    Copy-Item -Path $source -Destination $target -Recurse -Verbose
}
Wait-Job $job
Receive-Job $job

I have not read up on it yet, but deductive reasoning implies: because the JOB creates a new background process, the local variables are not available to the newly created thread. Makes sense to me. ]]> http://www.webofwood.com/2010/03/17/asynchronous-powershell-jobs/feed/ 0 http://www.webofwood.com/2010/03/03/oracle-backup-deployment/ http://www.webofwood.com/2010/03/03/oracle-backup-deployment/#comments Wed, 03 Mar 2010 20:52:53 +0000 John Wood http://www.webofwood.com/?p=88 I recently installed GRID Control and while “playing around” with it, I discovered the fantastic capability to build a job once and deploy over many targets. I thought this is very cool after experiencing so many problems with Dbconsole.

I found you can create a Job with minimal effort and deploy it to various targets with minimal effort. Database backups fit this mold exceptionally well. In my shop, all of our backups are rather routine and all share common properties: complete backup, daily at 6PM. All of our databases are small enough for complete backups rather than incremental.

If you want to quickly and easily build the backups for a dozen or more databases, you can try this process. I’m sure you will find it simple and effective. The basic steps involved are:

1. Build a Job “template” and save it in the Job Library
2. Choose between submitting the Job for scheduling against multiple targets or submitting the Job for each target. This process submits the Job for each target. I chose this method because I believe it gives me more flexibility to accommodate future changes for individual target requirements. You can try both methods to see which best suits your needs.

To start, bring up Oracle Grid Control and then choose the Jobs tab at the top. My screen is shown below. Now click on Job Library tab of that screen.

You should now be in the Job Library. Follow the numbered sequences on the next image below to create a new Library Job

Fill in General information about the Job

Key or paste in your RMAN script into the Parameters screen. I use a very generic script which uses all of the defaults I had previously established in Backup Settings for the target. A copy of my RMAN script is available here for cut & paste.

run {
backup device type disk database;
backup device type disk archivelog all not backed up delete all input;
delete noprompt obsolete device type disk;
}

After entering the script you’ll go on to specifying the Schedule. We won’t worry about the Credentials tab until we deploy to a target.

Set up your Schedule. Because we are deploying to individual targets, you will be able to change this later per target. In my case, all the targets have the same schedule so I can set it here and not worry about it when I deploy.

Deploy your new Job by selecting it from the list and then clicking the Submit button.

Now you will see another Job creation screen with the General settings. However, this one is now in the Jobs category and not the Job Library. You may notice, the Job name has been filled in with the name from your Job Library along with a suffix (most likely .1).  This is the time to add a Target or Targets.

Select one or more from the Targets List. I chose to use one target for each deployment. However, you can deploy one Job to multiple targets at the same time. My preference is to run the deployment for each target thereby creating a Job for each.

We’re back to the General information screen of the Job creation. At this time I also change the suffix for the Job name to match the Instance name of my target.

The Credentials screen gives you the opportunity to choose which credentials you want to use. In my case I am using the preferred credentials which I had already set up for each target.

The final Job scheduled to run every day at 6PM according to the time of the target ( you could have targets in differing time-zones).

If you chose, as I did, to deploy to individual targets, you would now return to the Job Library, select your job, and click submit. This would be repeated for each target.

Using Powershell and a simple script to execute Sp_Cycle_Errorlog, I now have a weekly, Windows scheduled task which executes the sproc to cycle the logs for all my SQL Servers.

foreach ($svr in get-content D:\Scripts\Servers.TXT ){
    $svr
    Invoke-Expression 'SQLCMD -E -S $svr -Q "Exec Sp_Cycle_Errorlog"' | Out-Null
	}

After creating a linked server on a 64bit SQL Server 2005 instance, I then needed to create a view which referenced the linked server. The linked server is a SQL Server 2000 32bit instance. However, when I tried to create the view, I got this error:  Cannot obtain the schema rowset “DBSCHEMA_TABLES_INFO” for OLE DB provider “SQLNCLI”.

This really proved to be a conundrum because I had just recently created the same linked server and view on another SQL 2005 instance. However, I had not yet connected the fact the 2005 instance was 32bit as opposed to the one I was now working on, which is 64bit.

I wrestled with it being a permissions issue for a while but ruled that out when I could not create the view even while using a domain admin account having authority of all the instances. A search on Google, using the above mentioned error message, turned up Joel’s blog. His specific problem was relative to SQL Server 7 but the answer applied to SQL Server 2000 also. He had found the original post of the ultimate solution and was good enough to include it in his blog which I have an excerpt here.

I found an extremely helpful post by Marek Adamczuk at http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=62887&SiteID=1. Marek  explains the 32-bit editions are missing a stored procedure on the master database called sp_tables_info_rowset_64.

Marek’s solution is to create a wrapper on the master database as follows (his code not mine):

create procedure sp_tables_info_rowset_64
    @table_name sysname,
    @table_schema sysname = null,
    @table_type nvarchar(255) = null
as
declare @Result int set @Result = 0
exec @Result = sp_tables_info_rowset
    @table_name,
    @table_schema,
    @table_type

It would appear the existing sproc does the same thing but just needs to be referenced using the 64bit name. Kudos to both Joel and to Marek for making this solution available!