Where can I find the SQL Server product content?

SQL Server product content for Denali is available online at MSDN and TechNet. While it is no longer released with the product, you can easily set up the help viewer to either access the content on MSDN or TechNet, or to download the help collections on your local computer. If you click the Books Online icon in the program group after installing CTP3, dialogs will explain how to configure the help viewer. To install Books Online on a server behind a firewall, you can download the files to a server with Internet access, then copy the files to the server behind the firewall. For more information, see Product Documentation for SQL Server Denali and Add or Remove Help Collections.

In the new help system, the help collections you install are combined into help catalogs. Most of the SQL Server tools, such as SQL Server Management Studio, reference a help catalog specific to SQL Server. The SQL Server documentation is installed into the SQL Server Help catalog when you install it using either the Manage Help Settings Start menu shortcut, or the Manage Help Settings Help menu item in SSMS. The BI Developer Studio, however, references the Visual Studio Help catalog for product documentation.

To make product documentation for SQL Server available to BIDS, go to the BIDS Help menu and select the Manage Help Settings item. This will launch Help Library Manager within the context of the Visual Studio Help catalog. Scroll down to the SQL Server “Denali” section and click Add next to the documentation you want to download. Since the content already exists on your machine, it will not be downloaded a second time. Instead, Help Library Manager will update the Visual Studio Help catalog’s index to include the product documentation for SQL Server. Once the index has been updated, you can close Help Library Manager and the documentation will be available for use.

What changes have we made?

Beginning with SQL Server Denali CTP 3, content that has traditionally been included in Books Online is now published to four separate areas on MSDN and TechNet.

• The new Books Online focuses on how to get tasks done and includes language reference topics.
• Tutorials provide scenario-based procedural content.
• The SQL Server Developer Reference provides detailed developer guides and API references for programmers writing applications and administrators building PowerShell scripts.
• When available, SQL Server Technical Guidance provides more prescriptive information on how to use the product to implement your solutions, and conceptual and architectural information to help understand solutions.

How has content in Books Online changed for Denali?

When you need to get something done, the new Books Online tells you how. It focuses on features and tasks, and provides reference content:

• Feature descriptions
• How-to content
• Tool descriptions
• Language reference, including T-SQL and DAX and MDX

We’ve removed and discarded content that is redundant or obsolete—making it easier for you to find what they need. While many changes have been made to the Denali documentation for CTP 3, it is still a work in progress. You may notice inconsistencies between content areas. For example, not all how-to topics show how to perform a task using different methods. Content will continue to change and be enhanced between CTP 3 and the final release.

Where can I find tutorials?

SQL Server tutorials are prescriptive, scenario-based content that enables you to familiarize yourself with SQL Server solutions. SQL Server tutorials are published to MSDN and TechNet separate from BOL and Technical Guidance, giving you up-to-date content.

How about the Developer Reference?

The SQL Server Developer Reference is available online at MSDN and TechNet, and you will be able to download it as a help package and view it using the Help Viewer. Moving the Developer Reference outside of the Books Online should improve discoverability of the content.

What will the Technical Guidance provide?

When you want to get the full story on SQL Server, you can get it in the SQL Server Technical Guidance.

• Prescriptive guidance about solutions
• End-to-end scenarios, including real-world examples
• Best practices
• More detailed conceptual information
• Role-focused information about setup, deployment, administration and management, security, troubleshooting, and performance.

Technical Guidance will be published to MSDN and TechNet separate from BOL. We will begin releasing Technical Guidance in the Fall of 2011.

And the community?

As usual, SQL Server community sites like the SQL Server Resource Center, the SQL Server Developer Center, the MSDN Forum, and the TechNet wiki are open for business.

What do you think?

This is a big change for the SQL Server product content and work is still in progress. We have made these changes to make sure that you can get the right information when you need it. We want your feedback. Let us know what you think about this change in any of the following ways:

• Take this short survey.
• Add a comment here in this article on the TechNet Wiki.
• Click the Rate and Give Feedback link at the top of any topic.
• Ask questions or post feedback on the SQL Server Denali Forum.
• Submit a bug through the Microsoft Connect.

SQL Server Agent uses SQL Server to store job information. SQL Server Agent can run a job on a schedule, in response to a specific event, or on demand. For example, if you want to back up all the company servers every weekday at 10-pm, you can automate the task as a SQL Server Agent job. Schedule the backup to run after 22:00 Monday through Friday; if the backup encounters a problem, SQL Server Agent can record the event and notify you.

To automate administration, follow these steps:

1. Establish which administrative tasks or server events occur regularly and whether these tasks or events can be administered programmatically. A task is a good candidate for automation if it involves a predictable sequence of steps and occurs at a specific time or in response to a specific event.
2. Define a set of jobs, schedules, alerts, and operators by using SQL Server Management Studio, Transact-SQL scripts, or SQL Server Management Objects (SMO). For more information, see Creating Jobs in SQL Server Books Online.
3. Run the SQL Server Agent jobs you have defined.

If you run multiple instances of SQL Server, you can use multiserver administration to automate tasks common across all instances. For more information, see Automating Administration Across an Enterprise.

Fixed database roles and least privileges

SQL Server Agent has three roles that reside in the MSDB system database. You can use these roles to fine tune privileges for SQL Server Agent jobs. Job management is an area where recent security improvements are a welcome addition compared to previous versions of SQL Server.

Although production DBA’s are likely to have System Administrator rights, SQL Server Agent Fixed Database Roles should be considered for:

• Junior DBA’s
• Developers
• Data Warehouse Developers
• IT Operations
• Management

These rights are granted at the MSDB database level. To grant rights, use the following steps:

1. Open SQL Server Management Studio.
2. Navigate to Databases | System Databases | MSDB | Security | Roles | Database Roles
3. Double-click one of the roles to add members to it.
4. Use the Database Role Properties window to manage users.

Best practices

• Take advantage of granular security privileges to secure your SQL Server Agent jobs using least privileges.
• Carefully evaluate the privileges requested by users and IT personnel. Once you have a clear understanding of their needs, grant the appropriate privileges without compromising the security of your system.

Additional information in SQL Server Books Online:

• Automating Administrative Tasks (SQL Server Agent)
• Automated Administration How-to Topics (SQL Server Management Studio)
• Selecting an Account for the SQL Server Agent Service
• Implementing SQL Server Agent Security
• SQL Server Agent Fixed Database Roles

Maintenance plans provide the following features:

• Create or edit a task work flow. Tasks in each plan can be grouped into subplans that can be scheduled to run at different times.
• Support for multi-server plans that can be used in master/target server environments.
• Support for logging maintenance plan history to remote servers.
• Support for Windows Authentication and SQL Server Authentication. When possible, use Windows Authentication.

Many DBA’s prefer Transact –SQL scripts for database maintenance tasks because scripting can be made more granular and scripts can be customized compared to packaged maintenance plans, especially compared to plans created with the Maintenance Plan Wizard.

Whether you script your solution, create a maintenance plan using the design surface in Management Studio, or create a maintenance plan using the Maintenance Plan Wizard in SQL Server Management Studio, it is important to implement a thoughtful and complete solution, and test it.

The results generated by maintenance tasks in a maintenance plan can be written as a report to a text file, or written to the maintenance plan tables, sysmaintplan_log and sysmaintplan_logdetail, in msdb. To view the results in the log file viewer, right-click Maintenance Plans, and then click View History.

Considerations for maintenance plans include:

• Backup databases and transaction logs
• Store backups both securely and off-site
• Index fragmentation
• Statistics
• Regular consistency checks
• Adequately sizing data files and transaction log files
• Run additional SQL Server Agent jobs
• Testing your backup/restore strategy on another computer or in a different environment

Note that maintenance plans only run against databases set to compatibility level 80 or higher. The maintenance plan designer in SQL Server Management Studio does not display databases set to compatibility level 70 or lower.

Important security considerations:  You must be a member of the sysadmin role to create and manage maintenance plans, and to view them in Object Explorer. The SQL Server Agent node in Object Explorer is only displayed for members of the sysadmin fixed server role, SQLAgentReaderRole, SQLAgentUserRole, or SQLAgentOperatorRole fixed database roles. Members of the db_ssisadmin role and the dc_admin role may be able to elevate their privileges to sysadmin. This elevation of privilege can occur because these roles can modify Integration Services packages and Integration Services packages can be executed by SQL Server using the sysadmin security context of SQL Server Agent. To guard against this elevation of privilege when running maintenance plans, data collection sets, and other Integration Services packages, configure SQL Server Agent jobs that run packages to use a proxy account with limited privileges or only add sysadmin members to the db_ssisadmin and dc_admin roles.

Back up user databases

User databases must be backed up on a regular basis. Also, do an additional round of backups after a new database or index is created, and after non-logged operations are performed.

There are four different backup strategies you can incorporate into your maintenance plans, each with its own strengths and weaknesses. As a DBA, you must weigh each aspect of the database application to reach a decision about the best solution for the system, the users, and the application administrators. Database size and frequency of data modification help determine the time and resources required to implement a database backup strategy.

The four types of backups supported for SQL Server are:

• Back up only the database
• Back up the database and the transaction logs
• Differential database backups
• Back up files or filegroups

Back up only the database

With this strategy, the entire database is backed up regularly. In case of failure, all the committed transactions that occurred after the most recent database backup are lost. The primary advantage of using this strategy is simplicity. The backup is obtained with a single operation, usually scheduled at regular intervals. When a database restore is required, it can be performed in one step.

Use full database backups when:

• The database is small so that the backup can be completed in a reasonable amount of time.
• The database has few data updates or modifications between backups.
• You are willing to accept the loss of changed data if the database fails between backups and must be restored to its previous state.

Back up the database and the transaction logs

With this strategy, the entire database is backed up less frequently because the transaction log is backed up frequently between database backups. In case of failure, you will be able to recover all backed-up transactions and possibly committed – complete - transactions that have occurred since the last transaction log backup. In this scenario, only uncommitted – incomplete - transactions will be lost.

Use database and transaction log backups when:

• The database is large or predicted to grow large in the near future.
• There are substantial updates or data modifications taking place on the database between backups.
• If you have a requirement to recover the database to as recent a state as possible – for example, to not lose any transactions already committed.
• You cannot afford to lose changes since the most recent database backup.

Differential database backups

This strategy is used in addition to either the database backup strategy or a database and transaction log backup strategy. Differential backups contain only database changes since the last database backup. The first step in this strategy is to perform a complete database backup. Then you can schedule the transaction log backups, followed by a differential backup. The differential backup strategy combined with the transaction log backup strategy reduces the number of transaction log backups that need to be restored during a recovery operation.

Use differential backups when:

• If you have a requirement to recover the database to as recent a state as possible – for example, to not lose any transactions already committed.
• You cannot afford to lose changes since the most recent database backup.
• The amount of time spent in recovering the database from transaction logs is not acceptable.

File or filegroup backups

File or filegroup backups are a specialized method of database backup where only certain files or filegroups from a database are backed up. This is usually done when there is not enough time to perform a full database backup. To make use of file and filegroup backups, you must utilize transaction log backups, as well.

Use file or filegroup backups when:

• For example, the databases to be backed up are very large databases partitioned among four files. If you are limited to a 60-minute maintenance window each night, but a database backup would take three hours, take a backup of one file each night, and ensure data consistency by taking transaction log backups at short intervals during the day.

Rebuild indexes

• Reorganize the data on the data and index pages by rebuilding indexes with a new fill factor. Rebuilding indexes with a new fill factor makes sure that database pages contain an equally distributed amount of data and free space. It also enables faster growth in the future. For more information, see Fill Factor.
• Compress data files by removing empty database pages.
• Update index statistics to make sure the query optimizer has current information about the distribution of data values in the tables. This enables the query optimizer to make better judgments about the best way to access data, because it has more information about the data stored in the database. Although index statistics are automatically updated by SQL Server periodically, this option can force the statistics to update immediately.

Check database consistency

• Perform internal consistency checks of the data and data pages within the database to make sure that a system or software problem has not damaged data.

Run SQL Server Agent Jobs

• SQL Server Agent jobs can be used to perform a variety of actions made up of job steps, and also to run the actions and jobs that make up a maintenance plan.

Store backups off-site

• The primary objective of taking database backups and testing restore procedures is to enable data recovery in case of data loss or disaster, so you must store backup media away from the physical location of your production environment.

Additional resources

SQL Server 2008 R2 Books Online:  How to: Create a Maintenance Plan

Brad McGehee’s free online e-book:  Brad’s Sure Guide to SQL Server Maintenance Plans

Script an existing maintenance plan:  https://social.msdn.microsoft.com/forums/en-US/sqltools/thread/52d71331-908d-4d5e-a14a-c665ce4cbc6a/

About the Accidental DBA:  https://blogs.technet.com/b/accidental_dba/archive/2011/05/23/introducing-the-accidental-dba.aspx

Contact the Accidental DBA:  Accidental_DBA_MSFT@hotmail.com

It is true that SQL Server installation is different for SQL Server 2000 compared to SQL Server 2005, SQL Server 2008, and SQL Server 2008 R2.  However, if you plan ahead, an instance of SQL Server is fairly easy to install, regardless of version, and there is good documentation and community support for all scenarios. Keep in mind that all SQL Server customers must successfully clear the Setup hurdle before moving forward with SQL Server, so you are not alone. Leaving version differences aside for the moment, these strategies remain constant for all versions of SQL Server:

Installation:

• Instance Naming - Your organization might have standards for SQL Server instance naming, so investigate existing standards before doing additional work here. Basically, you can install a named instance or a default instance of SQL Server.  This decision will affect SQL Server service names and the connection strings used by applications that connect to the instance. A computer can host one default instance of SQL Server, a default instance and multiple named instances, or one or more named instances. For more information, see Instance Configuration in SQL Server Books Online.

• Multiple Instances – You can run multiple instances of SQL Server on a single computer as long as you have, at most, one default instance.  Many organizations choose to run only named instances of SQL Server. Before running multiple instances of SQL Server on a single computer, consider:
  • Resource allocation – network traffic, CPU capability, physical disk space, and memory allocation.
  • Expected growth for a given database - Estimate growth in 6-month or 12-month increments and plan accordingly. The expected growth rate is also a consideration for a computer hosting a single instance of SQL Server.
  • Service Level Agreement requirements – For example, don’t mix instances of SQL Server that have different availability requirements.    

• Editions of SQL Server – SQL Server is available in multiple editions.  SQL Server Express is free, but has a limited set of features, and it has intentional performance limitations. On the other end of the spectrum, SQL Server Enterprise and SQL Server Datacenter are engineered for mission-critical online transaction processing (OLTP), business intelligence, and other high-demand, real-time applications. They are used by major airline reservation systems, banking, finance, and inventory systems, and other applications with high availability requirements that scale to five-9’s:  99.999% uptime. For more information about features of SQL Server supported by various editions, see Features Supported by the Editions of SQL Server. Note that this topic is updated for every major release of SQL Server. The link I provided is for SQL Server 2008 R2. For pricing information, see How to buy SQL Server.     

• Hardware and Software Requirements – You must install SQL Server on hardware and software configurations that have been tested by Microsoft. Hardware and software requirements do not demand the most expensive cutting edge equipment. Rather, they ensure that you experience the performance and functionality you expect and deserve from enterprise software. The section below includes links to version-specific hardware and software requirements, as well as links to system configuration requirements that will block installation if not present when you run SQL Server Setup.

• Feature Selection – SQL Server includes components and features to develop, update, transform, store, analyze, report, and manage data. New PowerPivot features allow data to be pulled from SQL Server and manipulated in Excel, SharePoint, and MapPoint through a concept called self-service BI. For more information, see Microsoft SQL Server PowerPivot Planning and Deployment. The Feature Selection page during SQL Server Setup allows you to specify features to install. For more information, see the Books Online topic for Feature Selection in SQL Server 2008 R2 Setup.

• SQL Server Books Online – SQL Server Books Online is the official Microsoft documentation for SQL Server, and it is available on MSDN. Books Online is updated with changes that affect features and functionality for each major release. Topics are carried forward unchanged for a new release if product functionality remains the same. Use the links below to get to SQL Server Books Online on MSDN. You can also use public search engines to search for SQL Server topics of interest, but be sure that the results you drill down to are for the version of SQL Server you are using.
  • Books Online for SQL Server “Denali”
  • SQL Server 2008 R2 Books Online
  • SQL Server 2008 Books Online
  • SQL Server 2005 Books Online
  • SQL Server 2000 Books Online

• Setup documentation - To prepare for installation, read the following Books Online topics for the version of SQL Server you will install. Links to topics for recent versions of SQL Server are included below.
  • Hardware and Software Requirements
  • Security Considerations for a SQL Server Installation
  • System Configuration Checks for a SQL Server Installation
  • How to: Install SQL Server

•  
  •  For SQL Server “Denali” (Still in pre-release.  We call this a CTP, or a Customer Technology Preview release.)
    • Hardware and software requirements for installing SQL Server “Denali”
    • Security Considerations for a SQL Server Installation
    • System configuration checks during Setup:
      • Installing “Denali”
      • Upgrading to “Denali”
    • Install SQL Server “Denali”(Setup)

•  

  • For SQL Server 2008 R2

    • Hardware and software requirements for installing SQL Server 2008 R2
    • Security considerations for a SQL Server installation
    • System configuration checks during installation
    • How to: Install SQL Server 2008 R2 (Setup)

•  

  • For SQL Server 2008

    • Hardware and software requirements for installing SQL Server 2008
    • Security considerations for a SQL Server installation
    • System configuration checks during installation
    • How to: Install SQL Server 2008 (Setup)

•  

  • For SQL Server 2005

    • Hardware and software requirements for installing SQL Server 2005
    • Security considerations for a SQL Server installation
    • System configuration checks during installation
    • How to: Install SQL Server 2005 (Setup)

•  

  • For SQL Server 2000

    • Hardware and software requirements for installing SQL Server 2000
    • Setting up Windows Service Accounts for SQL Server 2000
    • How to Install SQL Server 2000 (Setup)

Upgrade:

The most common methods to upgrade from one version of SQL Server to another are to:

1. Use the Upgrade Advisor tool to identify blocking issues, mitigate those issues, and then upgrade your instance of SQL Server using SQL Server Setup. This is referred to as direct upgrade or in-place upgrade.
2. Install a new instance of SQL Server of the higher version, and then use detach/attach to move user databases from the old instance of SQL Server to the new one. This is referred to as indirect upgrade. The disadvantage of indirect upgrade is that you have to manually move your user information to the new instance of SQL Server.

Resources for upgrading:

Upgrading to SQL Server 2008 R2:

• Using Upgrade Advisor to upgrade to SQL Server 2008 R2
• How to: Upgrade to SQL Server 2008 R2 (Setup)

Upgrading to SQL Server 2008:

• Using Upgrade Advisor to upgrade to SQL Server 2008
• How to: Upgrade to SQL Server 2008 (Setup)

Upgrading to SQL Server 2005:

• Using Upgrade Advisor to upgrade to SQL Server 2005
• How to: Upgrade to SQL Server 2005 (Setup)

Migration:

Database migration refers to an operation that moves a database from a platform like Oracle, Sybase, DB2, Access, or MySql to SQL Server. Microsoft has a migration assistant tool to assist with the steps for such a migration. The migration assistant converts database objects to SQL Server objects, migrates data to SQL Server, and validates the migration of code and data. For information about migrating to SQL Server, see the SQL Server 2008 migration whitepapers. There is also a team blog for the SQL Server Migration Assistant to assist with migration from MySQL.

Migration Assistant tools:

Migrating to SQL Server 2008

Migrating to SQL Server 2005

Other Setup Resources:

SQL Server Installation Portal - https://technet.microsoft.com/en-us/sqlserver/ff625277.aspx

Installation and upgrade forum - https://social.msdn.microsoft.com/Forums/en-US/sqlsetupandupgrade/threads

Peter Saddow’s blog. Peter is a SQL Server program manager who works on SQL Server Setup improvements - https://blogs.msdn.com/b/petersad/

A complete inventory is essential because it enables you to troubleshoot and quickly move to solutions.

SQL Server instance discovery and inventory is a one-time task that will produce a table you can update when significant changes are made.  You can also transfer the information to runbooks or to create new information stores if your organization does not have them already.  Note that it might take some time to complete your discovery, and that proprietary information must be distributed and stored according to the policies of your organization.

Use the information in Table 1. to identify the build numbers for SQL Server versions. 

  Related topics:

 4-part naming

SQL Server provides functionality to reference objects within a database, in another database, or to reference a different instance of SQL Server. This method uses a taxonomy called four-part naming. The four parts that are used to reference a database object in a hierarchy:

For SQL Server 2000:  server.database.owner.object

For SQL Server 2005 and higher:  server.database.schema.object

SQL Server Support Life Cycle

For information about the SQL Server support life cycle, see https://support.microsoft.com/gp/lifeselectindex.

The path to success as a SQL Server database administrator (DBA) is a known path. There are certain tasks that every DBA must perform on a regular basis in order to maintain database health, application availability, and business continuity. However, SQL Server is a complex set of features and components that can be overwhelming for a new or accidental DBA.

Maintaining mission-critical applications that utilize SQL Server can be harrowing, tense, nerve-wracking. In addition, not all DBA resources are in the DBA role by choice. Some were assigned DBA responsibilities with little notice and no formal training. If this describes you, you might be an accidental DBA.

This site is a collection of resources that will reduce the complexity of SQL Server and simplify regular DBA tasks so that you can - quickly, effectively, and efficiently – master the most important DBA tasks to learn the basics of database administration in an orderly fashion. The objective is to make your most important tasks understandable and repeatable.

The SQL Server DBA Guide was developed to help new users learn and understand the most important DBA tasks. The method for this guide is simple:  Collect best practices from SQL Server experts as well as from those who are fairly new to work as a SQL Server DBA, collect the best articles, tutorials, videos, and topics from SQL Server Books Online and from the SQL Server community, and present them in a logical progression that is easy to follow and easy to learn.

We continually add and update information based on top task analysis:  What are the most important tasks to others who do similar work, and what do you have to do to successfully complete them?

Presentation of topics and information architecture are designed to provide you with tasks, resources, and checklists that others have found most valuable as they learned to be a SQL Server DBA. If you are new to SQL Server and want to know more, you’ve come to the right place.  Read on!

Content Outline

The following topics will be covered in detail in a series of blogs. Selected blogs will be posted to the TechNet wiki site for this project - pointer forthcoming for "The SQL Server DBA Survival Guide" - where the Accidental DBA topics will be expanded and opened to the SQL Server Community for further development.

• SQL Server Instance Discovery/Inventory
• Installation, Upgrade, Migration, and Patching
• SQL Server Versions and Build Numbers
• Application Runbooks
• SQL Server Consolidation
• Multi-Instance Management
• Scripting Best Practices with Transact-SQL and PowerShell
• Correctness, Concurrency
• Storage, Storage Optimization
• Maintenance, Maintenance Plans
• SQL Server Best Practices Analyzer
• Files:  Data, Log, and Backup Files
• Automating Administrative Tasks with SQL Server Agent
• Resource Governance
• Security
• Policy-Based Management
• Change Tracking, Change Data Capture, and SQL Server Audit
• Connectivity
• Performance Tuning
• Monitoring
• AlwaysOn – High Availability, Disaster Recovery
• Replication, Database Mirroring
• Administering SQL Azure
• SQL Server Development

To contact the Accidental DBA, send e-mail to Accidental_DBA_MSFT@hotmail.com