Sql architecture


Published on

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Sql architecture

  1. 1. The Relational and Storage Engines •The relational engine comprises all the components necessary to parse and optimize any query •It also manages the execution of queries as it requests data from the storage engine in terms of OLE DB row sets and then processes the row sets returned. (Row set is the OLE DB term for a result set.) •The storage engine comprises the components needed to actually access and modify data on disk.
  2. 2. SQL Manager The SQL manager is responsible for everything having to do with managing stored procedures and their plans. It determines when a stored procedure needs recompilation based on changes in the underlying objects' schemas, and it manages the caching of procedure plans so that other processes can reuse them.
  3. 3. Checkpoints •Checkpoints are run on a database-by-database basis. •They flush dirty pages from the current database out to disk so that those changes don't have to be redone during database recovery. •A dirty page is one that has been modified since it was brought from disk into the buffer pool. •When a checkpoint occurs, SQL Server writes a checkpoint record to the transaction log, which lists all the transactions that are active •This allows the recovery process to build a table containing a list of all the potentially dirty pages.
  4. 4. Roll back / Forward
  5. 5. Transaction Logging and Recovery •Recovery performs both redo (rollforward) and undo (rollback) operations •If the change doesn't appear in the database, it is again performed from the information in the log •Undo requires the removal of partial changes made by a transaction if the transaction did not entirely complete
  6. 6. Three phases to the recovery algorithm •Phase 1: Analysis, Phase 2: Redo, Phase 3: Undo
  7. 7. Phase 1: Analysis •The first phase is a forward pass starting at the last checkpoint record in the transaction log. •This pass determines and constructs a dirty page table (DPT) consisting of pages that might have been dirty at the time of the crash (or when SQL Server stopped) •An active transaction table is built that consists of uncommitted transactions at the time of the crash
  8. 8. Phase 2: Redo •This phase repeats history by returning the database to the state it was in at the time of the crash •The starting point for this forward pass is the minimum of all the LSNs (Log sequence number) in the DPT (dirty page table) •. The DPT is used to avoid reading pages that don't need recovering and to avoid overwriting nonlogged changes
  9. 9. Phase 3: Undo •This phase moves backward from the end of the log •Any transaction that was not committed at the time of the crash is undone so that none of its changes are actually reflected in the database.
  10. 10. Locking and Transaction •A transaction can be rolled back only if all affected data was locked exclusively so that no other process could have made changes to resources used by the transaction that would prevent its being rolled back. •Only one active transaction can modify a row at a time •This is why exclusive locks must be held until a transaction is either committed or aborted.
  11. 11. Interaction with the Operating System •The SQL Server kernel is responsible for interacting with the operating system •All requests to operating system services are made via the Win32 API and C run-time libraries.
  12. 12. Threading •SQL Server supports multiprocessing at the thread level rather than at the process level, which allows for preemptive operation and dynamic load balancing across multiple CPUs. Using multiple threads is significantly more efficient than using multiple processes.