Edwin M SarmientoSQL Server 2005 – Edwin M Sarmiento

Fixing Orphaned Database Users in SQL Server 2005

Edwin M Sarmiento — Fri, 03 Apr 2009 01:12:00 +0000

I see this on almost all SQL Server instances I work on – existing user in a database with dbo permissions yet they could not access anything in the database. This is because SQL Server doesn’t really look at the user or login name but rather the SID values (I’ve talked about this in here). Maybe they restored a database back from a development server to the production server without synchronizing the logins. If this was SQL Server 2000, you’d probably end up dropping logins, recreating the logins using the script provided by Microsoft in this KB article and recreate the database users. Unfortunately, this is not a straight-forward task. Good thing Microsoft has provided the sp_change_users_login stored procedure to fix orphaned users. Using the UPDATE_ONE parameter will ‘re-map’ an orphaned database user to an existing SQL Server login with the same name. That in itself will spare you the trouble of going thru the process mentioned above (although you will still have to worry about orphaned database users that own schemas which is very much common among databases that have been upgraded from SQL Server 7.0 and 2000). Below is a syntax for ‘re-mapping’ an orphaned database user to an existing SQL Server login

EXEC sp_change_users_login ‘UPDATE_ONE’,‘user’,‘user’
GO

You still need to run the stored procedure with the REPORT parameter to return a list of orphaned database user

EXEC sp_change_users_login ‘Report’

The Return of the Living Dead:Job Owners who Keep Coming Back

Edwin M Sarmiento — Fri, 13 Mar 2009 03:57:00 +0000

Have you ever had the feeling that SQL Server was playing a trick on you? I had those moments. I was updating a database maintenance plan and ran the corresponding job associated with it. I got an error saying that the job owner did not have permissions to execute the task. So I did what I would do as part of my testing procedure- change the job owner to sa and re-ran. And so it completed successfully until I realized I need to change some parameters in the database maintenance plan. After updating the maintenance plan, I again re-ran the same job and unexpectedly, it failed throwing the same error. When I checked the job owner, it reverted back to the original login prior to me changing it to sa. This login happens to be the user account that created the database maintenance plan. The worse part is, the maintenance plan has like 20+ subplans, each creating a SQL Server job. Now, you wouldn’t want to change the job owner for each job associated with the maintenance job every time you change something, would you? Well, there’s just no way you can do it directly. But there’s always a workaround. This blog post provided a workaround for this case. You just modify the sysdtspackages90 table in the msdb database

UPDATE
msdb.dbo.sysdtspackages90
SET
OWNERSID = SUSER_SID(‘DOMAINnew_user’)
WHERE
OWNERSID = SUSER_SID(‘DOMAINold_user’)

For SQL Server 2008, this query should do the trick

UPDATE msdb.dbo.sysssispackages
SET OWNERSID = SUSER_SID(‘DOMAINnew_user’)
WHERE name = ‘MaintenancePlan’ AND OWNERSID = SUSER_SID(‘DOMAINold_user’)

There’s currently a Microsoft Connect item for this case so feel free to vote on it if you think it’s worth having a solution that just a workaround

Trying to attach an MDF file to SQL Server 2005?

Edwin M Sarmiento — Fri, 27 Feb 2009 00:20:00 +0000

While this is not recommended especially when you’re a bit paranoid about disaster recovery and data integrity, I still find a lot of people doing it. I guess a lot of independent software vendors don’t understand the underlying concepts behind the database engine. While it may have worked in SQL Server 2000 using Enterprise Manager, trying to attach an MDF file in SQL Server 2005 Management Studio will fail. To work around this, you can use the sp_attach_single_file_db system stored procedure. This will attach the MDF file and create an LDF file as well. This will only work if your database only has one datafile. Using this if your database has multipe datafiles won’t work. You do have to run the DBCC CHECKDB command to validate your database

I’d still prefer the backup/restore approach. Nothing beats having a peace of mind

Why Windows Instant File Initialization for SQL Server 2005 (and higher) matters

Edwin M Sarmiento — Wed, 17 Sep 2008 08:08:00 +0000

SQL Server 2005 supports Database Instant File Initialization which skips zeroing out data pages that can reduce the time when performing operations like creating databases, adding files to an existing database, increasing the size of an existing database file manually or thru autogrowth or restoring a database or filegroup. I’ve written an article in MSSQLTips.com highlighting it’s importance both in a disaster recovery and operational performance scenarios. I ran a few tests as well to simply answer a query in the forum regarding the topic. I ran my tests on a VMWare image on a DELL PowerEdge 2650 with 4 X 2.8 GHz CPU and 3GB RAM. The image is running Windows Server 2003 Enterprise Edition with SQL Server 2005 Enterprise Edition as this is an “Enterprise Edition only” feature. I’ve created a 10GB-sized database which took only 0.1 seconds using instant file initialization. Without it, the same took about 2:10 minutes. Imagine doing a restore for a 500GB-sized database. That will save you a lot of time on the restore process. Same goes with file auto growth. The difference in the amount of time it takes to do a restore would definitely matter when you’re dealing with very large databases. Imagine trying to restore a 500GB-sized database. You’ll probably agree after trying it out for yourself

>And so I need a GRANT IMPERSONATE permission

Edwin M Sarmiento — Thu, 28 Aug 2008 08:27:00 +0000

>SQL Server 2005 has given us the ability to allow more granular permissions, one of which is the EXECUTE AS clause. This would give the user the ability to impersonate a more privileged user should there be a need to do so. But before a user can do impersonation, it must be given the permission to impersonate. This is where the GRANT IMPERSONATE permission is needed – where a lower privileged user needs to impersonate a higher privileged user and not the other way around, I presume.

I’ve written an article on MSSQLTips.com to demonstrate how to use the EXCECUTE AS clause with the REVERT clause to impersonate users

>Did you check your MSDB.dbo.suspect_pages after a database restore?

Edwin M Sarmiento — Fri, 25 Jul 2008 06:47:00 +0000

>In SQL Server 2005, the default behavior of a RESTORE command is to simply continue even if there are corrupted pages in your backups. The only way to find out if there are corruptions is when a user gives you a call saying that they could not query some records and probably gets an error similar to the one below

Msg 824, Level 24, State 2, Line 1
SQL Server detected a logical consistency-based I/O error:
incorrect checksum (expected: 0xf93a020c; actual: 0xf93a820c).
It occurred during a read of page (1:69) in database ID 10 at offset 0x0000000013c000 in file
‘C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLDataSalesDB.mdf’.
Additional messages in the SQL Server error log or system event log may provide more detail.
This is a severe error condition that threatens database integrity and must be corrected immediately.

The first thing you need to do after a database restore is to check the MSDB.dbo.suspect_pages to see if there are suspect pages that need to be repaired. Books Online describes the structure of this system table and gives you an idea on what to restore should there be suspect pages. Bear in mind though that this system table can only hold up to a maximum of 1000 records and everything get cycled out so you need to do your own housekeeping.

The Enterprise Edition gives you an option to do a page-level restore should you have corrupt databases. A more low-level discussion on fixing damaged pages can be found on the SQL Server Storage Engine blog