When a client system sends a request to the primary server, the primary server writes the request in its transaction log before writing the request in the data file because Yukon uses a write-ahead log. Next, the primary server sends the transaction record to the mirrored server. The mirrored server writes the record to its transaction log, then sends an acknowledgement to the primary server that the record has been received, giving both servers the same data in each of their logs. In the case of COMMIT operations, the primary server waits for the acknowledgement before it sends the client a response noting that the operation has finished.
To initialize database mirroring, you back up the database that you want to mirror on your primary server, then restore that backup on your mirrored server. This process puts the underlying database data and schema in place. A state of continuous recovery (i.e., taking the data from the log and updating the data file) keeps the data files up-to-date on the mirrored server.
5. Transparent Client Redirect
The new Transparent Client Redirect feature works closely with database mirroring. A new version of Microsoft Data Access Components (MDAC) implements the Transparent Client Redirect feature, which automatically redirects client systems to the mirrored server when the primary server becomes unavailable. No changes are necessary to the client or data-layer applications.
Here's how this new feature works: MDAC is aware of both the primary and mirrored servers. MDAC acquires the mirrored server's name on its initial connection to the primary server. When the connection to the primary server is lost, MDAC first tries to reconnect to the primary server. If that connection attempt fails, MDAC automatically redirects a second connection attempt to the mirrored server. Just as with clustering, if the connection is lost in the middle of a transaction, the application will roll back that transaction. The application must redo that transaction after the client connects to the mirrored server.
6. MARS
Another important new feature in Yukon is its support for Multiple Active Result Sets (MARS). Earlier releases of SQL Server limited you to one active result set per connection. Although COM-based ADO and OLE DB had a feature that let the application work with multiple results sets, under the covers that feature was actually spawning new connections on your behalf to process the additional commands.
In conjunction with enhancements to ADO.NET, MARS lets you use multiple active commands on one connection. With this feature, you can open a connection to the database, run the first command, and process some results, then run a second command and process results. You can then go back to the first command and process some more results.
MARS and the new version of ADO.NET let you freely switch back and forth between different active commands. No blocking occurs between the commands, and the commands share a single connection to the database. As a result, MARS provides big performance and scalability gains for ADO.NET applications. Because MARS relies on a Yukon database enhancement, this feature doesn't work with earlier versions of SQL Server.
7. SQL Server Workbench
One of Yukon's biggest changes occurs in the administrative tools. Server Manager, SQL Server Enterprise Manager, and SQL Query Analyzer are gone. In their place, Yukon provides the new SQL Server Workbench, which is essentially a customized version of Visual Studio .NET's IDE. You use SQL Server Workbench to manage SQL Server and create queries. Although you can use SQL Server Workbench to manage earlier versions of SQL Server, you can't use Enterprise Manager or Query Analyzer to manage a Yukon server.
Prev. page
1
2
[3]
4
5
next page 
