Editorials

Tips for using jobs in SQL Server 2005 (Part 2)

Featured Article(s)
Tips for using jobs in SQL Server 2005 (Part 2)
Here are some helpful tips to use SQL Server 2005 jobs.

Make Sure Everyone Can Understand Your Recovery Plan
Unless you want to be on-call for all types of things that may happen with your SQL Servers, considering having plans in place and tools that make recovery more straightforward. I don’t know if you’ve seen this yet, but the Acronis toolset will actually let you use a wizard to create a plan and automatically create a detailed recovery plan that almost anyone can use. You might even get a vacation without being asked to continually monitor status messages. Check it out here and see how it may help your shop take some of the guesswork out of recovery.

Webcast Today!
SQL Server 2005 Tuning Tools and Approaches
We’ll look into the tools and techniques you have available to you in SQL Server 2005 for investigating performance issues, understanding what your server is doing and how you can use this information to tune your system. From Performance Monitor to watching queries that are executing we’ll show you some of the tools at your disposal for diagnosing server issues of performance and possible tuning targets.

> Register Now
> Live date: 6/11/2008 at 12:00pm Noon Pacific

One Approach to More Granular Security
David
wrote in with a fantastic look at their approach to managing security. I wanted to pass it along here.

"Well I looked at this issue many years ago and developed a security model database that allowed data owners to control access to their data instead of relying on the complications of SQL based security.


Each application ran under a special AD account for the connection to SQL Server with only Data Reader and Data Writer privileges and selected Stored procedure Execute permissions.

Here is a breakdown of the tables that supported the security app.

Users – Well no problem visualizing this one.
Applications – No issues here either.
ApplicationObjects – This is a listing of all of the objects within the Application, Examples would be forms or reports, but could also be selected fields on the form
UserRoles – here was the logical grouping of the user community
ApplicationPermissions – this is the resolving table where the UserRoles are tied to the ApplicationObjects.
ObjectPermissions – This table holds the permission choices for the objects

There are no direct logins to SQL server by any user.

In the startup method of the form, a simple query is ran against the Security database passing the object ID to resolve the rights of the user upon entry of the form. These are then applied via code during the refresh method.

So no users had any sort of advanced permissions, and the data owners are responsible to the user rights. Where you have strong ownership rules and many layers of data access for possibly thousands of users, there just is no way to do that appropriately using AD groups or SQL Roles without having a dedicated security staff for all of the constant changes and also the time to coordinate the security accesses with the actual data owners.

So this is how I have been doing it for about 10 years."

Featured White Paper(s)
ESG Lab Validation Report of the HP PolyServe Database Utility for SQL Server
ESG Lab, the testing facility of industry analyst firm Enterprise Strategy Group, reports its comprehensive testing of HP’s s… (read more)

The Shortcut Guide to SQL Server Infrastructure Optimization
In The Shortcut Guide to SQL Server Infrastructure Optimization, the new eBook from Realtime Publishers, leading IT author Do… (read more)