February 2012

Featured Presentation

SQL Server Security for Developers

Speaker: Andy Warren

Summary: SQL Server has a robust and granular system for granting and denying access to users, but all too often we see applications running as DBO or even sysadmin. Why? Part of is that same granular system can be overwhelming and part is that many developers don't see the point in applying such granular security. In this introductory level presentation we'll start at the beginning with creating and managing logins, take a quick look at system roles, and then get into the nitty gritty of users and roles and permissions at the database level. Along the way we'll talk about why its so important to set security at the database and not just rely on the application enforced security.

About Andy: Andy Warren is an independent consultant specializing in SQL Server based in Orlando. Over the course of his career he has written more than 100 technical articles, was a founder of, relaunched the Orlando SQL Server User Group (oPASS), served for three years on the PASS Board of Directors, and has been a SQL MVP since 2008. He blogs most days at on a wide range of topics and spends a lot of time teaching and thinking about professional development and mentoring.


Pre-Meeting Presentation

What Happened? Exploring the Plan Cache

Speaker: Kalen Delaney (Video replay from 2011 PASS Summit DVDs)

Summary: Being pro-active,and using one of the various tracing capabilities of SQL Server, is the best way to keep track of what is going on in your SQL Server and what might be causing performance problems. But does that mean if you haven't set up any tracing, there is nothing you can do to find out what problematic queries might be running? The answer is no. In this session, we'll explore SQL Server's plan cache, from the way it is managed in memory, to the tools and techniques for discovering what plans are in cache, how long they've been there, how often they've been run, and whether they contain any suspected sub-optimal operators, such as table scans and hash joins. Knowing what's happened is the first step in knowing what needs to be fixed.

Back to Top