Voice of the DBA

Tag: TopTenSkills

  • The 80/20 Rule – Top Ten SQL Server Skills

    Over the years that I’ve worked in technology, I’ve found that the 80/20 rule seems to apply pretty well to all the different areas that one can specialize in. It doesn’t matter whether you build PCs, work on the help desk, administer systems or develop software, the rule has pretty well been true for my career.

    The 80/20 rule essentially says this: 80% of your job takes 20% of your time (or skills) and the remaining 20% of your job takes 80% of your time (or skills). It doesn’t matter if this is your daily work or a project that you are assigned. Most of your effort is in finishing the last details, or handling the most complex parts.

    I’ve heard this joked about in software development as the rule of 90s as well, saying that the first 90% of a piece of software takes 90% of your time and the last 10% takes the other 90% of your time.

    I built my presentation, The Top Ten Skills You Need for SQL Server, based on this rule. It includes the most skills that often solve questions I see asked at events or on forums. It seems that these ten skills along with the basics of performing them will solve most of your problems.

  • The Basic Security Model in SQL Server – Skill #3

    This series of blog posts are related to my presentation, The Top Ten Skills You Need, which is scheduled for a few deliveries in 2011.

    Users and Objects

    The basic security model diagram that I use is the one below. It’s not fancy, but it conveys the basics of security in SQL Server.

    security

    From left to right, users or clients are mapped to principals. Those principals are both in the instance (login) and database (user) as well as roles. Permissions are assigned to roles on objects.

    That’s essentially what the basic security model should be for most people. There are other types of structures (credentials, certificates, etc), but in terms of the 80/20 rule, here’s what most DBAs should do:

    • Create a login for a person (either Windows or SQL Server login)
    • Map this login to a user with the same name in those databases that person needs access to. Only pick those databases needed, not all databases.
    • Create a role in each database for each group of users/permissions.
    • Add the users to this role
    • Grant permissions on the objects needed to these roles.

    It’s not complicated, and sticking to this simple scheme, and not granting db_owner or sysadmin to logins or users will allow you to implement basic, easy to understand security in SQL Server.

    References

  • Create a Log Backup Schedule – #1 Skill You Need

    This series of blog posts are related to my presentation, The Top Ten Skills You Need, which is scheduled for a few deliveries in 2011.

    You Need Log Backups

    By default databases in SQL Server are created with the Full Recovery Model. That means that without log backups, the log will continue to grow and grow until it hits the growth limit you’ve set, or it fills the disk. I see questions on this constantly at SQLServerCentral from people who have a 10MB database and a 653GB log file.

    A log backup will mark the transactions in the log as backed up, and that space can be re-used. The log backup aids in space management and also provides recovery to points in time in between full backups. With that in mind, you need to do a few things.

    Schedule Log Backups

    As soon as you create a database, and you create a full backup schedule, schedule log backups as well. It’s easy to schedule a single daily log backup along with your full backup. They don’t block each other, and for most non-production systems, this works fine.

    Note that the total space used for the log backups is the same whether you schedule 1 a day or 86,400 a day. There is a slight overhead to each file, but essentially the space used is the same. However backups scheduled more often result in a smaller log files size for the LDF.

  • When Do You Take a Full Backup?

    This series of blog posts are related to my presentation, The Top Ten Skills You Need, which is scheduled for a few deliveries in 2011.

    When is a Full Backup Taken?

    Most people might answer this with “every day”, or “as often as needed”, but those are a little nebulous, and not necessarily correct.

    I do recommend that you backup as often as you can, which is every day for most people. Those with large databases might go once a week, or even once a month, but you want to get a full backup periodically. If you have a really large database, say 50TB or greater (in 2011), you might opt for a yearly SAN snapshot of some kind, but you need some full backup as a base.

    So when do you backup your database? Here’s a list of some times you might think about:

    • As often as you can on a regular schedule (daily, weekly, monthly, etc)
    • Before applying a Service Pack or CU*
    • Before applying a Windows patch*
    • Before upgrading your application*
    • Before a large data load*
    • After restoring your instance in a DR situation

    That last one might throw people, but I’ve seen more than a couple situations where someone recovered a database in a DR situation and never setup backups. And there was another failure.

    Whenever you create a database, either from scratch or after a restore, make a backup.

    * Note that if you have Enterprise Edition or above, you can use Database Snapshots to substitute for a full backup in some of these situations.