Wednesday, June 17, 2009

Check the last backup date in SQL Server using WIndows PowerShell

This article highlights how to use Windows PowerShell to retrieve database properties using SMO. Notice how easy it is to check the database properties using pretty common syntax

One of the challenges I have when I was starting out as a SQL Server DBA was to check for the last backup date for a database. One way to do this is to find out which tables in the MSDB database contain the records of the backup history. What's really challenging here is the fact that you would have to look at the tables and their corresponding relationships which, apparently, MSDB doesn't have. You simply have to rely on what SQL Server Books Online has to say. Plus, the MSDB database will only contain records for databases with backups. What about those without?

For SQL Server 2005, the script below displays the last backup date of all the databases on your SQL Server instance. This script is from the MSDN Code Gallery

SELECT
T1.Name AS DatabaseName,
COALESCE(CONVERT(VARCHAR(12), MAX(T2.backup_finish_date), 101),'Not Yet Taken') AS LastBackUpTaken
FROM sys.sysdatabases T1 LEFT OUTER JOIN msdb.dbo.backupset T2
ON T2.database_name = T1.name
GROUP BY T1.Name
ORDER BY T1.Name

You can simply replace the sys.sysdatabases table with master.dbo.sysdatabases for SQL Server 2000

Below is the equivalent script using Windows PowerShell.

$instance="Your_SQL_Server_Instance_Name"
[System.Reflection.Assembly]::LoadWithPartialName('Microsoft.SqlServer.SMO')| out-null

# Create an SMO connection to the instance
$s = new-object ('Microsoft.SqlServer.Management.Smo.Server') $instance

$dbs = $s.Databases
$dbs | select Name,LastBackupDate, LastLogBackupDate | format-table -autosize


The only thing to note here are the last two lines - the one that creates an instance of the database object and the one that displays and formats a few of the database object properties. The first few lines will be the same for just about any PowerShell script that will access SQL Server using SMO

Thursday, June 4, 2009

Copying DTS packages from SQL Server 2000 to SQL Server 2005 and SQL Server 2008

I've seen this approach from the CSS SQL Server Engineers blog post and wondered if I can give it a shot. We're migrating a SQL Server 2000 database to a SQL Server 2005 instance (finally!) and that included a lot of DTS packages. While I would highly recommend upgrading the DTS packages to SSIS packages for the long term due to product support lifecycle reasons, that would take quite a while and would impact businesses dramatically.

I've used Method 2A mentioned in the blog post to move the DTS packages from the SQL Server 2000 to SQL Server 2005 as I have like more than a hundred DTS packages stored in MSDB. Remember that the size of the sysdtspackages table in MSDB will depend on not just the number of packages stored but the number of versions of the packages you decide to keep.

After a restore of the MSDB database from the SQL Server 2000 instance and importing the records from the sysdtspackages table, you would definitely want to install the Microsoft SQL Server 2000 DTS Designer Components to modify and edit your DTS packages in SQL Server 2005 to change those connection strings, test them after migration and so on.

Thursday, May 21, 2009

No Drives Found error installing CentOS 5.2 on VMWare

Ok, so this is not my typical blog post that talks about anything Microsoft but it still is technology so it makes a good blog post.

I was installing CentOS 5.2 on a VMWare Workstation image when I suddenly hit a wall with this error

No Drives Found
An error has occurred - no valid devices were found on which to create new file systems. Please check your hardware for the cause of this problem.

Now, this isn't the first time I'm installing CentOS on a virtual machine nor on a physical hardware but it definitely is the first time to install version 5.2. Back in the old versions, everything was pretty straight-forward and that I had never encountered this error message before. I was beginning to be tempted to use an iSCSI disk for the installation with another virtualized iSCSI disk but I wouldn't want to go down that road unless I will be configuring this virtual machine as a clustered server. Having searched thru a ton of newsgroup and blog posts on similar issues, a few of them mentioned changing the Operating System to Red Hat Enterprise Linux or Other Linux 2.4.x kernel to make it work. I did find a recommendation to change the virtual disk from SCSI (which happens to be the default setting when you configure your virtual machine) to IDE. That did the trick, although I needed to create a new virtual machine in the process which was the quickest way to do it.

So, remember - use an IDE disk in your VMWare image when installing CentOS 5.2

Tuesday, May 19, 2009

Backup on shared folders running on a local system account?

I still see a lot of SQL Servers running using the LocalSystem account, particularly, MSDE 2000, which is very popular among third-party applications that requires storing data in a database. Others run a stand-alone SQL Server system and use LocalSystem account for the service accounts. While this may be a security risk, a lot of users still have them configured. And when they need to generate database backups on a shared folder, the SQL Server service's attempt to connect to network resources are denied access because they have no credentials and they are using a null session.Of course, a typical recommendation would be to change the service account to a local Windows or a domain account with least privilege but not everybody is open to that suggestion. So how do you allow SQL Server to generate a backup on a shared folder while using a LocalSystem account? The solution: enable null session shares

While I do not advocate such workarounds as it opens up additional security loopholes, it still is a workaround. And as I usuallly say,
WARNING: This is not a recommended approach. Use at your own risk

Microsoft has a documented procedure to enable null sessions shares and while the KB article mentions Windows 2000, it does work for Windows Server 2003. This should be done on the Windows machine that hosts the shared folder. A word of caution if you intend to use this approach - document every step that you do and make sure you rollback any changes made after generating your database backup. Tasks like enabling the Guest user account (this is disabled by default), modifying the registry, etc. should be rolled back as soon as you're done, otherwise, you're opening up security vulnerabilities across your network.
Google