![SQL Server 2005 Administration, Scalability and Reliability Dr Greg Low Readify [email_address]](https://image.slidesharecdn.com/sql2005highavailability-100514093228-phpapp02/85/sql-2005-high-availability-1-320.jpg)
![Prerequisite Knowledge ,[object Object],[object Object],[object Object],[object Object],Level 200](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (19)
Semelhante a Sql 2005 high availability
Semelhante a Sql 2005 high availability (20)
Mais de Information Technology
Mais de Information Technology (20)
Último
Último (20)
Sql 2005 high availability
- 1. SQL Server 2005 Administration, Scalability and Reliability Dr Greg Low Readify [email_address]
- 12. Database Server Failure or Disaster Failover Clustering Shared Disk Array 2 nd Private ‘Heartbeat’ network Clustered Servers Clients Virtual Server Primary Network
- 16. Database Server Failure or Disaster Database Mirroring With Automatic Failover Separate Disk Arrays Principal Server Mirror Server Clients Witness Server
- 17. Database Server Failure or Disaster Database Mirroring With Automatic Failover
- 18. Configuring and Using a Database Mirror demonstration
- 19. User or Application Error Comparison of High Availability Options Feature Hot Standby Warm Standby Cold Standby Database Mirroring Failover Clustering Peer-to-Peer Transactional Replication Log Shipping Backup / Restore Detach / Copy / Attach Data Loss No data loss option No data loss Some Data Loss possible Some data loss possible Some data loss possible Some data loss possible Some data loss likely Automatic Failover Yes Yes Optional No No No No Transparent to Client Yes, Auto-Redirect Yes, Reconnect to same IP Optional No, NLB helps No, NLB helps No No Downtime < 3 Seconds 20 Sec + DB Recovery None Seconds Seconds + DB Recovery Detect, Restore, Manual failover Detect, Attach, Manual failover Standby Read Access Continuously accessible Snapshot No Continuously accessible Continuously accessible Intermittently accessible No No
- 20. User or Application Error Comparison of High Availability Options Feature Hot Standby Warm Standby Cold Standby Database Mirroring Failover Clustering Peer-to-Peer Replication Transactional Replication Log Shipping Backup/ Restore Detach/ Copy/ Attach Data Granularity Database Only All System and User Databases Table or View Table or View Database Only Database Only Database Only Masks Disk Failure Yes No, Shared Disk Yes Yes Yes Yes Yes Special Hardware Needed No, Dup. system needed Specialized Hardware from Cluster HCL No, Dup. system needed No, Dup. system needed No, Dup. system needed No, Dup. system needed No, Dup. system needed Complexity Some More More More More Some Some
- 23. User or Application Error How Database Snapshots Work
- 25. Implementing and Using Database Snapshots demonstration
- 36. Implementing and Using Database Partitions demonstration
- 39. Microsoft Learning Training Resources for IT Professionals To see the detailed syllabus or to locate a training provider please visit www.microsoft.com/learning Course Title Available MS-2733 Updating Your Database Administration Skills to Microsoft SQL Server 2005 Now MS-2734 Updating your Development skills to Microsoft SQL Server 2005 Database Now MS-2087 Implementing Microsoft Windows 2000 Clustering Now
Notas do Editor
- <SLIDETITLE>Title Slide</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>Introduce the session.</KEYMESSAGE> <SLIDEBUILDS>0</SLIDEBUILDS> <SLIDESCRIPT> Hello and welcome to this Microsoft TechNet session A Technical Overview of SQL Server 2005 High Availability. My name is {insert name} </SLIDESCRIPT> <SLIDETRANSITION></SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION>
- <SLIDETITLE>Prerequisite Knowledge</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>List the prerequisites of the session.</KEYMESSAGE> <SLIDEBUILDS>4</SLIDEBUILDS> <SLIDESCRIPT> This session assumes you have some knowledge of SQL Server 2000 or 7.0. [Build 1] You need to know basic T-SQL syntax. For this session, you will really only need to understand the SELECT and UPDATE operators. [Build 2] You need to understand how to execute stored procedures and DBCC statements. [Build 3] You need to understand how SQL Server uses transaction logs to store transactions. It is important that you know the difference between the three recovery models and understand how SQL Server uses the transaction log in the recovery process. [Build 4] You need a basic understanding of how SQL Server handles locking and blocking. </SLIDESCRIPT> <SLIDETRANSITION>Let’s get started…</SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION>
- <SLIDETITLE>Agenda Topic 1</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>Introduce the first agenda topic.</KEYMESSAGE> <SLIDEBUILDS>0</SLIDEBUILDS> <SLIDESCRIPT> The first topic is barriers to availability. </SLIDESCRIPT> <SLIDETRANSITION>Specifically, we will start by examining the business requirements for availability…</SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION>
- <SLIDETITLE>Barriers to Availability overview</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>There are several factors that affect database availability, and this session focuses on those that can be mitigated by SQL Server 2005 features and client applications that use those features.</KEYMESSAGE> <SLIDEBUILDS>8</SLIDEBUILDS> <SLIDESCRIPT> Database availability is a complex concept with several competing factors and requirements. [Build 1] Availability is usually defined by business requirements. [Build 2] These business requirements include consideration of business hours and locations. High numbers of business hours or locations in a greater number of time zones will create a definition of availability significantly different from one with a few business hours in one or a few time zones. [Build 3] Business processes will have their own impact on the definition of availability to an organization. How business transactions are handled could affect whether the database must always be available or whether business can continue when failure occurs. [Build 4] User and management expectations will place their own availability requirements on your organization .
- <SLIDETITLE>Primary Server or DBMS Failure</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>Describe the possible causes of database failure or disaster</KEYMESSAGE> <SLIDEBUILDS>4</SLIDEBUILDS> <SLIDESCRIPT> [Build 1] The first barrier we will cover is database failure or disaster. A server or database can fail for a couple of reasons. [Build 2] Despite the increasing reliability of hardware, hardware failure is still probably the most common reason an entire database will fail or become unavailable. The failure could be the server itself, the hard drive controller, or the hard disks that the database resides on. The general procedure to handle this kind of failure is a second server with different hardware that hosts a second copy of the database. [Build 3] Disaster is a second reason a database or server will become unavailable. These disasters can be human-made, such as terrorist attacks, or accidents or errors that result in loss of function to your data center. Network or Internet connectivity or power failure are perhaps the most common, whether it is only the room or floor your data center resides on, or the entire building, block, city, or region that is affected. Depending on your availability requirements, you could wait until the situation is fixed, if that is possible, or you may need another server with a copy of the database in a separate physical location. [Build 4] Another type of disaster that can occur is natural disaster. This could be fire, flood, earthquake, volcanic eruption, and so on. These disasters frequently will damage the hardware or infrastructure past the point of quick repair, so a database on a server in another physical location is required. You will see several solutions to preparing for these situations. </SLIDESCRIPT> <SLIDETRANSITION>Let’s cover two other availability barriers before we see some solutions to the barriers…</SLIDETRANSITION> <ADDITIONALINFORMATION><ITEM></ITEM></ADDITIONALINFORMATION>
- <SLIDETITLE> Primary Server or DBMS Failure </SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>Two other barriers are user or application errors that damage data, and concurrency limits that limit access to the database.</KEYMESSAGE> <SLIDEBUILDS>6</SLIDEBUILDS> <SLIDESCRIPT> [Build 1] The next barrier we will cover is user or application error. This error could be one of several events. [Build 2] The most common error is accidental data modifications. These usually are the result of an UPDATE or DELETE statement without a WHERE clause. An implemented stored procedure could have a bug so that causes the application to damage that data. Other possibilities include an administrator, developer, or user programming and executing the statement directly, or the application programmer programming the statement incorrectly. Developers or administrators connecting to the production database, instead of the testing or development database, and modifying data or changing the schema is also a possibility. [Build 3] Malicious data modifications can also damage data in a database. All of the previous options, combined with malicious intent, apply here as well. [Build 4] Another availability barrier to consider is concurrency limitations. The DBMS is designed to maintain data integrity. [Build 5] To do this, concurrency controls have been implemented to prevent simultaneous modifications of data. From a business requirement and user perspective, having to wait for certain operations can reduce the availability of the database. [Build 6] Making changes to Persistent Data Structures, namely tables and indexes, can also prevent access to data. The operations frequently will move and sort data. Allowing access, particularly update access, would be dangerous for data integrity. You will see in this session how new features in SQL Server 2005 can help recover and repair data and limit these concurrency restrictions. </SLIDESCRIPT> <SLIDETRANSITION>Let’s move on to solutions to these availability barriers…</SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION>
- <SLIDETITLE>Agenda Topic 2</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>Introduce the second agenda topic.</KEYMESSAGE> <SLIDEBUILDS>0</SLIDEBUILDS> <SLIDESCRIPT> Now that you know the barriers to availability we are considering, you will want to know about the features and options available to reduce their impact on your databases. </SLIDESCRIPT> <SLIDETRANSITION>We’ll begin with database server failure or disaster.</SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION>
- <SLIDETITLE>Database Server Failure or Disaster Overview</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>The main solutions we’ll cover are failover clustering, database mirroring, and peer-to-peer replication.</KEYMESSAGE> <SLIDEBUILDS>6</SLIDEBUILDS> <SLIDESCRIPT> [Build 1] We’ll begin by covering failover clustering. There are several new features in SQL Server 2005 that make clustering an even better solution for server failure. Clustering works to protect an entire server, or servers, against failure, if more than two nodes are configured. Clustering has the weakness of single point of failure, where there are shared hard disks. [Build 2] Database mirroring is another new feature in SQL Server 2005 that can be used to protect against server failure. Database mirroring protects only one database, but two copies of the data are maintained on separate disks and separate servers. [Build 3] Peer-to-peer replication is yet another option to help protect against server failure. Peer-to-peer replication can work for just one table or for an entire database. It requires more administrative maintenance but provides multiple update and reporting servers unlike clustering or mirroring. All three of these technologies can be used for hot standby servers. [Build 4] There are several other alternatives for server failure high availability. We will only compare them to the above features because they have changed very little from SQL Server 2000. [Build 5] Standard hierarchical replication topologies and log shipping can both be used to maintain warm standby servers that require more administrative intervention to fail over than the hot standby solutions. [Build 6] You can use two other methods to help protect against server loss. Backing up and restoring database files onto other SQL servers can create a cold standby server that requires even more administrative intervention than the warm standby solutions. A similar alternative of manually copying the data to another server is to detach the database, copy it to the new server, and attach the copies at each server. This also produces a cold standby server and has the additional problem of making the original database unavailable while it is detached. </SLIDESCRIPT> <SLIDETRANSITION>Let’s look at failover clustering in greater detail...</SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION>
- <SLIDETITLE>Failover Clustering</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>Clustering can be an effective but expensive solution to protect against server failure.</KEYMESSAGE> <SLIDEBUILDS>8</SLIDEBUILDS> <SLIDESCRIPT> [Build 1] Failover clustering provides a hot standby server. Hot standby servers are available immediately, or almost immediately, for failover. [Build 2] SQL Server failover clustering is built on Microsoft Cluster Services, or MSCS. It can therefore take advantage of all the benefits that MSCS provides. [Build 3] If you are running SQL Server 2005 on Windows Server 2003, this means that you can now have 8 nodes in your SQL Server clusters. [Build 4] MSCS provides for automatic failover in approximately 20 seconds plus the time to complete the recovery process. SQL Server 2005 allows access to a database after all committed transactions have been written to disk but before the uncommitted transactions have been rolled back. This facilitates faster access than SQL Server 2000 when failing over to a secondary cluster node. [Build 5] Microsoft Cluster Services does require special certified hardware. The special hardware requirement is a shared disk array and controllers that are certified by Microsoft for use in a cluster. Some of these products can be very expensive. [Build 6] Zero committed data is lost since the clustered servers all share the same database file and transaction log. You will lose any uncommitted transactions because the secondary server initiates the recovery process on all SQL Server instance databases. [Build 7] Clustering uses shared disk arrays, so only one copy of the database exists. Clustering does not protect against disk failure nor does it protect the database from a disk controller card that writes bad data to the disk array.
- [Build 8] The standby servers are not available for any other use for the clustered SQL Server instance. Other instances can be run on the standby servers. [Build 9] SQL Server 2005 failover clustering now supports more SQL services. In addition to the SQL Server Service for OLTP databases, you can now use clustering for Analysis Services, Reporting Services, and Notification Services. </SLIDESCRIPT> <SLIDETRANSITION>Let’s take a visual look at a two-node failover clustering configuration…</SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION>
- <SLIDETITLE>Failover Clustering Diagram</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>Clustering can be an effective but expensive solution to protect against server failure.</KEYMESSAGE> <SLIDEBUILDS>0</SLIDEBUILDS> <SLIDESCRIPT> The best implementations of failover clustering use a second private network for the clusters so the server will not fail over in the event of a network hardware failure. Clients access a cluster virtual server that has its own name and IP address. The use of a virtual server prevents the clients from needing to manually reconnect if a node fails. You should note the shared disk array is a single point of failure. The shared disk array does create a distance constraint. Clustered servers almost always will reside in the same data center, making them susceptible to disasters, both human-made and natural. </SLIDESCRIPT> <SLIDETRANSITION>Let’s move on to a high availability solution that does not have a single point of failure…</SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION>
- <SLIDETITLE>Database Mirroring</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>List the features of database mirroring.</KEYMESSAGE> <SLIDEBUILDS>8</SLIDEBUILDS> <SLIDESCRIPT> Database mirroring is a new technology designed specifically for high availability solutions without the drawbacks of clustering. [Build 1] Database mirroring provides, like clustering, a hot standby server. The failover, when configured, occurs faster than clustering does. [Build 2] Database mirroring can be configured to provide automatic failover. The automatic failover requires a third database instance to act as a witness server. It also requires the Synchronous with Automatic Failover option. This option requires the transaction to be able to be committed at both servers before it commits in the principal database. This ensures that, in the case of server failure, the mirror has all committed transactions. You can use database mirroring using asynchronous transactions and no automatic failover for a warm standby solution. [Build 3] Database failover occurs very quickly with database mirrors, usually in less than 3 seconds. [Build 4] If the client application was programmed using ADO.NET 2.0, the client can implicitly fail over to the mirror. The ADO.NET libraries automatically perform this operation without the programmer needing to program it. If the client application is not programmed using ADO.NET 2.0 libraries, then the application will need to programmatically, or explicitly, handle the server failover. [Build 5] You will not lose any committed data if database mirroring is configured with synchronous transactions. If configured with asynchronous transactions, then some committed data loss can occur.
- [Build 6] Using database mirroring in synchronous transaction mode for high availability will result in some performance impact. Transaction throughput, or number of transactions per second, will likely be minimally impacted. Transactional latency, or the time required for an individual transaction, will be affected by the round-trip communication time between the two mirroring servers. If you are using asynchronous transaction mode, transactional latency will not be affected. [Build 7] You can configure a maximum of one mirror for each database you configure for mirroring. You can, however, mirror separate databases to different SQL Server instances on separate servers. [Build 8] The standby database, or database mirror, is unavailable for any other use. It cannot be queried or used for reporting. You can, however, create database snapshots of a database mirror, and use those for reporting purposes. </SLIDESCRIPT> <SLIDETRANSITION>Let’s take a look at the hardware requirements for database mirroring.</SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION>
- <SLIDETITLE>Database Mirroring Hardware</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>No special hardware is required for database mirroring, and hence there is virtually no distance limitation for database mirrors.</KEYMESSAGE> <SLIDEBUILDS>6</SLIDEBUILDS> <SLIDESCRIPT> [Build 1] No special hardware is required for database mirroring as is required for failover clustering. [Build 2] Database mirroring just requires a second server. [Build 3] The two servers do not even have to have the same hardware. [Build 4] Database mirroring has virtually no distance limitations because… [Build 5] it does not have any shared hardware like the shared disk arrays used with failover clustering. [Build 6] The actual distance limitation depends on how long you want each transaction to wait for the round-trip network traffic between the mirroring partners. If higher latency is acceptable, then a longer distance is allowed. Of course, network latency is not solely determined by distance but by other factors as well, such as bandwidth. </SLIDESCRIPT> <SLIDETRANSITION>Let’s see how the Database Mirroring Automatic Failover works.</SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION>
- <SLIDETITLE>Database Mirroring with Automatic Failover</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>Describe the process of automatic failover when using database mirroring.</KEYMESSAGE> <SLIDEBUILDS>4</SLIDEBUILDS> <SLIDESCRIPT> When using database mirroring, [Build 1 ] clients connect to the principal database server. In the event that the principal server becomes unavailable, [Build 2 ] either by server or network failure, [Build 3 ] the mirror server’s connection and the witness server’s connection with the principal server will fail. The mirror server and the witness server will agree that the principal server is unavailable, and the mirror will become the principal server. [Build 4 ] The clients will be redirected to the new principal server, which formerly was the mirror server. </SLIDESCRIPT> <SLIDETRANSITION>Let’s take a look at how the three servers communicate during a server failure.</SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION>
- <SLIDETITLE>Database Mirroring with Automatic Failover Details</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>Explain the communication role that the database mirroring servers perform when a server fails.</KEYMESSAGE> <SLIDEBUILDS>0</SLIDEBUILDS> <SLIDESCRIPT> Database mirroring with automatic failover uses quorums. A quorum of three exists when all servers are functioning and configured correctly. If the principal server fails, the witness and mirror form a quorum of two. They both must agree that the principal server is unavailable. If the network connection between the principal and mirror breaks but both can still contact the witness, the mirror server does not become active. If the witness and mirror both agree, then the mirror server becomes active and clients are redirected to it. When the original principal server is repaired, it will contact the witness server and discover that the original mirror server is now acting as a principal. The original principal server then assumes the mirror server role and synchronizes from the new principal server. The mirror and the witness must be able to communicate with each other at the time of failure. If the mirror is unavailable or in a DISCONNECTED state at the time the principal server fails and later is able to communicate with the witness server, automatic failover will not occur. </SLIDESCRIPT> <SLIDETRANSITION>Let’s see how to configure database mirroring with automatic failover and what happens when the principal fails…</SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION>
- <SLIDETITLE> Demonstration: Configuring and Using a Database Mirror Demonstration</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>Describe the database mirroring demonstration.</KEYMESSAGE> <SLIDEBUILDS>0</SLIDEBUILDS> <SLIDESCRIPT> This demonstration will cover how to configure and use a database mirror. You will first see how to create the mirroring database, then how to establish security and communication between the database mirroring partners and a mirroring witness. You will then see the successful failover of a database with a simulated failure of the principal server. </SLIDESCRIPT> <SLIDETRANSITION>Let’s continue and see how peer-to-peer replication can be used for high availability.</SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION>
- <SLIDETITLE>Comparison of High Availability Options 1</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>Comparing other solutions to the three solutions already covered.</KEYMESSAGE> <SLIDEBUILDS>0</SLIDEBUILDS> <SLIDESCRIPT> The three solutions covered already all provide a hot standby solution. They provide for little or no data loss and easy client redirection. Your other availability options only provide for either a warm standby or a cold standby server. Some data loss is a concern for all of these other options. They do not have transparent client redirection and most do not have read-only standby. </SLIDESCRIPT> <SLIDETRANSITION>Continuing our comparison…</SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION>
- <SLIDETITLE>Comparison of High Availability Options 2</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>Comparing other solutions to the three solutions already covered.</KEYMESSAGE> <SLIDEBUILDS>0</SLIDEBUILDS> <SLIDESCRIPT> You can see that only replication allows granularity of data configured for high availability to less than an entire database. You should also notice that only failover clustering does not protect against disk failure and is the only solution that requires specialized hardware. Of the higher availability solutions, database mirroring is the lowest in complexity and system administration. </SLIDESCRIPT> <SLIDETRANSITION>That concludes our discussion of high availability solutions for server failure or disaster.</SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION>
- <SLIDETITLE>Agenda Topic 3</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>Introduce the third agenda item.</KEYMESSAGE> <SLIDEBUILDS>0</SLIDEBUILDS> <SLIDESCRIPT> The next agenda item is user or application error and some solutions to help protect your data and limit downtime of your critical data. </SLIDESCRIPT> <SLIDETRANSITION>We’re going to focus on the new database snapshot technology.</SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION>
- <SLIDETITLE>Database Snapshots</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>List the main features of database snapshots.</KEYMESSAGE> <SLIDEBUILDS>7</SLIDEBUILDS> <SLIDESCRIPT> [Build 1] Database snapshots are read-only copies of the database. [Build 2] They provide a static view of the database. The data available in a snapshot will not change over time. [Build 3] Snapshots return data that was committed at the time the snapshot was created. [Build 4] Snapshots do not store all data pages—only the pages that have changed since the snapshot was created. Therefore, when a snapshot is created, the data files are empty. Snapshots use NTFS Sparse files. Sparse files are a feature of the NTFS file system that allows files to start small and grow as space is needed. [Build 5] When a database snapshot is queried, SQL Server will read the original data. [Build 6] The data will either come from the snapshot if the data pages have been modified in the original, or source database. If the data has not yet been modified, SQL Server reads the data from the source database. [Build 7] Database snapshots will increase the disk I/O of the source database. When rows are modified for the first time after the snapshot was created, their data pages will be copied to the snapshot database files. </SLIDESCRIPT> <SLIDETRANSITION>Let’s see how SQL Server uses database snapshots when a snapshot is queried…</SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION>
- <SLIDETITLE>Database Snapshot Scenarios</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>Snapshots do not store all data pages, and the amount of disk space required depends on the amount of changes in the data pages.</KEYMESSAGE> <SLIDEBUILDS>0</SLIDEBUILDS> <SLIDESCRIPT> In this diagram, the red boxes indicate data pages that have been updated. Notice that the snapshot is only storing original values for those data pages that have been updated. The blue arrows indicate what data pages are read during a read operation on the database snapshot. SQL Server will read the data from the source database when the data pages have not been updated after the creation of the snapshot. The space required by a snapshot depends on how many data modifications occur. The two examples in the diagram could be two different tables in the same database. One of the tables has been updated more than the other since the creation of the snapshot. This will likely be the case in most databases. Some tables are frequently updated, like an orders table, while some are rarely updated, like products sold or countries that a company does business in. </SLIDESCRIPT> <SLIDETRANSITION>Let’s look at some ways to use database snapshots.</SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION>
- <SLIDETITLE>Database Snapshot Scenarios</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>There are several uses of database snapshots, not all of them involving database snapshots.</KEYMESSAGE> <SLIDEBUILDS>4</SLIDEBUILDS> <SLIDESCRIPT> Database snapshots have several possible uses. [Build 1] You can create database snapshots of a mirror database involved in database mirroring. This is a method of extending the functionality of database mirroring to make the standby server also function as a reporting server. The data, however, would be a point-in-time reporting scenario, and not a true, up-to-date reporting scenario. [Build 2] A second use of database snapshots is to enable point-in-time historical reporting. You could enable users to generate reports of data, for example quarterly sales, that would be valid for that period of time. While some users are querying the snapshot for the point-in-time data, other users can still be updating the database with the new quarters information. [Build 3] Database snapshots could also be used to recover from administrative error. An administrator could create a database snapshot immediately preceding the execution of a risky or potentially damaging script. In the event that something goes wrong, the administrator can revert the database to the snapshot. [Build 4] Lastly, you can use database snapshots to help protect against application or user error. This use will generally require the creation of several snapshots to record different values. You could create a snapshot every two hours and delete snapshots older than 24 hours. You could then extract the data from a snapshot when some negative event occurs. Multiple snapshots allow you to recover in case you are not notified of the problem until the next snapshot is created. </SLIDESCRIPT> <SLIDETRANSITION>Let’s see how to create and use database snapshots in the following demonstration.</SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION>
- <SLIDETITLE>Demonstration: Implementing and Using Database Snapshots</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>Describe the database snapshot demonstration.</KEYMESSAGE> <SLIDEBUILDS>0</SLIDEBUILDS> <SLIDESCRIPT> This demonstration will cover how to create database snapshots. It also covers how to access database snapshots and how to recover data following its damage in a database. Two possible recovery methods that repair the damage to a database will be covered. </SLIDESCRIPT> <SLIDETRANSITION>Let’s move on to our fourth and last agenda item.</SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION>
- <SLIDETITLE>Agenda Topic 4</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>Introduce the fourth agenda topic.</KEYMESSAGE> <SLIDEBUILDS>0</SLIDEBUILDS> <SLIDESCRIPT> Our next agenda item covers data access concurrency limitations and some new technology solutions to reduce this problem. </SLIDESCRIPT> <SLIDETRANSITION>Let’s see the important topics involved with these limitations.</SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION>
- <SLIDETITLE>Pessimistic Concurrency Controls</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>Pessimistic locking controls, which is to say creating shared locks for read operations, have been part of SQL Server for a good reason.</KEYMESSAGE> <SLIDEBUILDS>4</SLIDEBUILDS> <SLIDESCRIPT> [Build 1] Pessimistic concurrency controls are the default setting in SQL Server 2005. They were the only controls in SQL Server 2000 and earlier versions. [Build 2] Concurrency controls were designed to help maintain data integrity. Without the controls, several transactions could update the same data and decision code in transactions could select inaccurate rows to update. [Build 3] Pessimistic concurrency controls require shared resource locks for SELECT operations. This means that updates can not occur while reads are occurring and reads can not occur while updates are occurring. The default behavior is to hold shared locks for just the duration of the SELECT operation. This behavior can be controlled by using [Build 4] different isolation levels. The transaction isolation levels control the behavior of shared locks. The isolation levels solve one or more problems that can occur while accessing data. They range from reading uncommitted data from memory, bypassing the exclusive locks on the rows on disk, to holding shared locks for the duration of the entire transaction. The isolation levels have different impacts on concurrency. Locking the rows for an entire transaction will prevent any updates from occurring until the transaction completes thereby reducing concurrency and availability of the database. Sometimes it may be necessary, for data integrity reasons, to lock rows for an entire transaction. </SLIDESCRIPT> <SLIDETRANSITION>Optimistic concurrency controls handle shared locks in a different manner.</SLIDETRANSITION> <ADDITIONALINFORMATION></ADDITIONALINFORMATION> <ITEM></ITEM>
- <SLIDETITLE>Optimistic Concurrency Controls</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>Optimistic concurrency controls can be used to increase concurrent access to data, thereby increasing throughput and availability.</KEYMESSAGE> <SLIDEBUILDS>5</SLIDEBUILDS> <SLIDESCRIPT> [Build 1] The transaction isolation levels that use optimistic concurrency controls are an optional setting. [Build 2] Optimistic concurrency controls are implemented by using row versioning. [Build 3] These controls are still designed for data integrity but will allow reads of committed data while other transactions are holding locks that would prevent SELECT statements from completing. [Build 4] SELECT operations that use these concurrency controls do not use shared locks on the rows in the database, but instead use the row versions maintained by SQL Server when the controls are enabled. [Build 5] The different isolation levels for the optimistic concurrency controls control which row versions are accessed by SELECT operations instead of how shared locks are acquired and released. </SLIDESCRIPT> <SLIDETRANSITION>You need to understand SQL Server 2005 row versioning before we can discuss the details of the controls.</SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM></ADDITIONALINFORMATION>
- <SLIDETITLE>Row Versioning</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>Row versioning is used to implement the optimistic concurrency controls and other operations, but uses space and disk I/O for tempdb.</KEYMESSAGE> <SLIDEBUILDS>7</SLIDEBUILDS> <SLIDESCRIPT> [Build 1] Row versioning has several uses and is not just used to implement the optimistic concurrency controls. [Build 2] Row versioning is used for the inserted and deleted tables that are used by triggers. [Build 3] Multiple Active Result Sets, or MARS, sessions make use of row versions as well. [Build 4] ONLINE Index operations also make use of row versions during their operations. [Build 5] Lastly, row versioning is also used for row snapshots to implement the optimistic concurrency controls. [Build 6] Row versions are created and stored in tempdb. You will want to make sure that tempdb is optimized for performance and has enough disk space before you implement the optimistic concurrency controls. A heavily accessed database can place a significant load on tempdb for both performance and disk usage. [Build 7] SQL Server does delete row versions when they are no longer necessary to support any transaction or operation that requires them. This helps to limit how much space these use, but large transactions or very large numbers of transactions can cause SQL Server to store many versions in tempdb. </SLIDESCRIPT> <SLIDETRANSITION>Let’s take a look at the first isolation level that utilizes row versioning.</SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM></ADDITIONALINFORMATION>
- <SLIDETITLE>Snapshot Isolation Level</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>Explain Snapshot Isolation Level and how to enable it.</KEYMESSAGE> <SLIDEBUILDS>3</SLIDEBUILDS> <SLIDESCRIPT> Snapshot Isolation Level is a new transaction isolation level that uses row versioning and does not require shared locks to read data. Snapshot Isolation Level enables transactions to read committed data that is being modified by other transactions. [Build 1] Snapshot Isolation Level will allow reads of committed data as the data existed at the time the transaction started. The data may be modified while the Snapshot Isolation Level transaction occurred, but any read operations will read the older committed data. You can be sure that all read operations in the transaction will be accessing the exact same data. [Build 2] You must use the ALLOW_SNAPSHOT_ISOLATION database option to enable transactions to use Snapshot Isolation Level. This does not change the default concurrency control or transaction isolation level. The option simply turns on row versioning in the database. Once you enable this option, all INSERTs, UPDATEs, and DELETEs cause SQL Server to create row versions, regardless of whether there are any transactions using Snapshot Isolation Level. SQL Server does not know whether a transaction will start before any updates will complete, so it must maintain row versions just in case a Snapshot Isolation transaction starts. [Build 3] You can enable transactions to use Snapshot Isolation Level by using the TRANSACTION ISOLATION LEVEL SNAPSHOT session command. This command only works if you have previously set the ALLOW_SNAPSHOT_ISOLATION database option to on. </SLIDESCRIPT> <SLIDETRANSITION>Let’s look at the second transaction isolation level that can be used by optimistic concurrency controls. </SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM></ADDITIONALINFORMATION>
- <SLIDETITLE>ONLINE Index Operations</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>Data is accessible during ONLINE index operations.</KEYMESSAGE> <SLIDEBUILDS>3</SLIDEBUILDS> <SLIDESCRIPT> … the ONLINE index operations. [Build 1] During an ONLINE index operation, the underlying data in the table is still accessible. This is different from an OFFLINE index operation, which was the only option with earlier versions of SQL Server. The table is accessible for both read and update operations. [Build 2] If you are creating a clustered index, any non-clustered indexes are still available for the optimizer to use. The new clustered index is not used until its creation operation is complete. SQL Server continues to access the old table heap until that time. [Build 3] A non-clustered index is not available during any operation being applied directly to that non-clustered index. </SLIDESCRIPT> <SLIDETRANSITION> Let’s look at the commands available for online index operations. </SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM></ADDITIONALINFORMATION>
- <SLIDETITLE>ONLINE Index Operation Commands</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>List the commands that online index operations can be use with.</KEYMESSAGE> <SLIDEBUILDS>6</SLIDEBUILDS> <SLIDESCRIPT>A variety of commands can make use of ONLINE index commands: [Build 1] These are CREATE INDEX, [Build 2] ALTER INDEX, [Build 3] and DROP INDEX. [Build 4] An ALTER TABLE command can also be used if you either [Build 5] ADD or DROP a Unique index, or [Build 6] you ADD or DROP a primary key with the clustered index option. </SLIDESCRIPT> <SLIDETRANSITION>Let’s see what happens during the creation of an ONLINE clustered index.</SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM></ADDITIONALINFORMATION>
- <SLIDETITLE>Agenda Topic 4</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>Introduce the fourth agenda topic.</KEYMESSAGE> <SLIDEBUILDS>0</SLIDEBUILDS> <SLIDESCRIPT> Our next agenda item covers data access concurrency limitations and some new technology solutions to reduce this problem. </SLIDESCRIPT> <SLIDETRANSITION>Let’s see the important topics involved with these limitations.</SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION>
- <SLIDETITLE>Demonstration: Implementing and Using Database Snapshots</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>Describe the database snapshot demonstration.</KEYMESSAGE> <SLIDEBUILDS>0</SLIDEBUILDS> <SLIDESCRIPT> This demonstration will cover how to create database snapshots. It also covers how to access database snapshots and how to recover data following its damage in a database. Two possible recovery methods that repair the damage to a database will be covered. </SLIDESCRIPT> <SLIDETRANSITION>Let’s move on to our fourth and last agenda item.</SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION>
- <SLIDETITLE>Session Summary</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>Summarize with the three key session messages.</KEYMESSAGE> <SLIDEBUILDS>3</SLIDEBUILDS> <SLIDESCRIPT> Let’s look at the three most important things to take away from this session. [Build 1] Several new features are available in SQL Server 2005 to help you protect against server failure or disaster. You can use a combination of these features to provide the highest availability possible. You could use failover clustering for all roles involved in database mirroring, for example, to increase availability even further. [Build 2] Database snapshots can be used for several reasons, including to protect against application, user, or administrative error. [Build 3] New features are available to reduce some concurrency problems you may be experiencing in your databases. These features include the new optimistic concurrency controls and ONLINE Index Operations. </SLIDESCRIPT> <SLIDETRANSITION>For more information… </SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM></ADDITIONALINFORMATION>
- <SLIDETITLE>More Information</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE></KEYMESSAGE> <SLIDEBUILDS>0</SLIDEBUILDS> <SLIDESCRIPT> For the most comprehensive technical information on Microsoft products visit the main TechNet website at www.microsoft.com/technet. Additionally visit www.microsoft.com/technet/tnt1-134 for more concise information on books, courses, certifications, and other community resources that related directly to this particular session. </SLIDESCRIPT> <SLIDETRANSITION> What other resources are available from TechNet? </SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM></ADDITIONALINFORMATION>
- <SLIDETITLE>Microsoft Learning</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>Talk about the eLearning course.</KEYMESSAGE> <SLIDEBUILDS>0</SLIDEBUILDS> <SLIDESCRIPT> Microsoft Learning (formerly Microsoft Training and Certification, and Microsoft Press) develops courseware called Microsoft Official Curriculum (MOC), which includes eLearning, Microsoft Press Books, workshops, clinics, and Microsoft Skills Assessment. MOC is offered in instructor-led environments; it offers comprehensive training courses for IT professionals and well as support and implementation solutions using Microsoft products and technologies. The courses that best support this session are MS–2733: Updating Your Database Administration Skills to Microsoft SQL Server 2005; and MS-2734: Updating Your Database Development Skills to Microsoft SQL Server 2005. Both of which are already available. For more information visit www.microsoft.com/learning. </SLIDESCRIPT> <SLIDETRANSITION>An assessment program is also available that can help you test your knowledge. </SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM></ADDITIONALINFORMATION>
- <SLIDETITLE>Community Help</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>Where to get more help</KEYMESSAGE> <SLIDEBUILDS>0</SLIDEBUILDS> <SLIDESCRIPT>A number of free community resources are available on TechNet. You can attend a regular chat with members of the products groups or technology specialists from Microsoft, or you can attend a webcast where you can see sessions like the one you’ve just watched but presented live and with the ability to ask questions as you go. You can also locate or post questions in the public newsgroups; the newsgroup page lists the available groups and provides an interface for you to read and post into. TechNet Plus subscribers can use these groups to post questions that, through their subscription id, will be answered by Microsoft within 24 hours. The main community site provides a comprehensive list of available resources, more than we can cover on this slide, plus the page has some dynamic features with continually updating content. The events page provides dates and details about live TechNet events. These events take place worldwide and provide you the opportunity to talk to Microsoft specialists face-to-face. And finally TechNet columns provide a variety of topics written by industry authors. </SLIDESCRIPT> <SLIDETRANSITION>[Thank the audience for attending and sign off]</SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM></ADDITIONALINFORMATION>
- <SLIDETITLE>Tag line</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE></KEYMESSAGE> <SLIDEBUILDS>0</SLIDEBUILDS> <SLIDESCRIPT></SLIDESCRIPT> <SLIDETRANSITION></SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM></ADDITIONALINFORMATION>
- <SLIDETITLE>Credits</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE></KEYMESSAGE> <SLIDEBUILDS>0</SLIDEBUILDS> <SLIDESCRIPT></SLIDESCRIPT> <SLIDETRANSITION></SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM></ADDITIONALINFORMATION>