{"id":5351,"date":"2026-02-20T14:30:38","date_gmt":"2026-02-20T22:30:38","guid":{"rendered":"https:\/\/www.sqlskills.com\/blogs\/paul\/?p=5351"},"modified":"2026-02-20T14:30:38","modified_gmt":"2026-02-20T22:30:38","slug":"sql101-introduction-to-sql-server-transactions","status":"publish","type":"post","link":"https:\/\/www.sqlskills.com\/blogs\/paul\/sql101-introduction-to-sql-server-transactions\/","title":{"rendered":"SQL101: Introduction to SQL Server Transactions"},"content":{"rendered":"<p><em>(The original version of this post first appeared on the now-deleted SentryOne blog at the start of 2022.)<\/em><\/p>\n<p style=\"text-align: justify;\">One of the most fundamental concepts in any relational database management system (RDBMS), such as SQL Server, is the transaction. During my consulting career, I&#8217;ve seen many instances of performance problems caused by developers not understanding how transactions work in SQL Server, so in this tutorial, I\u2019ll explain what transactions are and why they\u2019re necessary, plus some details of how they work in SQL Server. There are nuances to some of this when Accelerated Database Recovery (ADR) is in use &#8211; topics for future articles.<\/p>\n<h2>What is a Transaction?<\/h2>\n<p style=\"text-align: justify;\">A transaction is a\u00a0<em>unit of work<\/em>\u00a0in the database. Every transaction has a defined\u00a0starting\u00a0point\u00a0and a defined ending point. The ending point may be the transaction\u00a0<em>committed<\/em>\u00a0(i.e. completed successfully) or transaction finished\u00a0<em>rolling back<\/em>\u00a0(i.e. did not complete successfully), and I\u2019ll discuss the meaning of those terms a little later.<\/p>\n<p>The basic\u00a0syntax\u00a0for transactions is as follows:<\/p>\n<ul>\n<li style=\"text-align: justify;\">BEGIN TRANSACTION (or\u00a0BEGIN TRAN)\u00a0starts the transaction.<\/li>\n<li style=\"text-align: justify;\">COMMIT TRANSACTION (or COMMIT TRAN) ends the transaction successfully.<\/li>\n<li style=\"text-align: justify;\">ROLLBACK TRANSACTION (or ROLLBACK TRAN) causes the transaction to end unsuccessfully so all operations performed in the transaction are reversed.<\/li>\n<\/ul>\n<p>You can also specify a\u00a0transaction name\u00a0but this is not required and I don&#8217;t see them used very often.<\/p>\n<p style=\"text-align: justify;\">It is important to think about what a\u00a0<em>unit of work<\/em>\u00a0is. It means all changes to the database within the confines of the transaction, typically\u00a0DML\u00a0data modification\u00a0operations like\u00a0insert statements,\u00a0update statements, and\u00a0delete statements. This might be a single\u00a0T-SQL\u00a0statement\u00a0or multiple statements, depending on the kind of transaction being used. If it\u2019s a single statement, it doesn\u2019t necessarily mean a single change. Consider a table with 1,000 rows and someone runs an\u00a0UPDATE statement\u00a0with a WHERE clause. This is a single statement but will cause a change to all the rows in the table, at least 1,000 changes to the database within the transaction.<\/p>\n<p style=\"text-align: justify;\">Even if the UPDATE statement only operates on a single row in the table, there are still at least two changes to the database; the update of the row itself on a data file page and the update of the differential bitmap page to mark that portion of the database as changed so the next differential backup will back up the extent that the page is part of. There are plenty more examples I&#8217;ve seen over the years of where a single statement can cause many changes to the database depending on\u00a0data types\u00a0like\u00a0varchar, table\u00a0formats, whether nonclustered indexes exist, and so on.<\/p>\n<h2>Why Are Transactions Necessary?<\/h2>\n<p style=\"text-align: justify;\">Transactions are part of how\u00a0SQL Server\u00a0implements the ACID properties of a database (Atomicity, Consistency, Isolation, and\u00a0Durability), along with mechanisms like locking and logging.<\/p>\n<p style=\"text-align: justify;\">A transaction guarantees that its unit of work is either wholly present in the database or wholly not present. This is the\u00a0atomicity\u00a0in the ACID properties, and I\u2019ll explain how this is done later. This means transactions are very useful for\u00a0SQL Server\u00a0developers to control whether a set of operations (e.g. implementing some business logic) completely succeeds or does not succeed at all, so there are no partially-executed sets of operations that would leave the database inconsistent from a business perspective.<\/p>\n<p style=\"text-align: justify;\">A classic example is moving money from a checking account to a deposit account. This involves a debit from the checking account and a credit to the deposit account. This must be implemented as a single transaction so that if the debit succeeds and the credit fails, the transaction as a whole fails and the debit is reversed when the transaction rolls back.<\/p>\n<p style=\"text-align: justify;\">In all cases, changes to the database are performed under locks held by the transaction and these locks are not released until the transaction ends. Using the default\u00a0<em>isolation level<\/em>, which is called\u00a0<em>read committed<\/em>, other transactions will not be able to see these changes until the transaction has committed (ended), hence the name of the\u00a0isolation level. This is the isolation in the ACID properties.<\/p>\n<p style=\"text-align: justify;\">For instance, a change to a row will involve the row being exclusively locked by the transaction. Another transaction that wants to read the row will usually require a share lock on the row, and so will also be blocked. This behavior can be changed if the reading transaction changes to the\u00a0<em>read uncommitted<\/em>\u00a0isolation level\u00a0(or uses the NOLOCK option on the\u00a0SELECT statement), that doesn\u2019t require share locks for reading rows, but introduces the possibility of anomalies occurring.<\/p>\n<h2>Types of Transactions in\u00a0SQL Server<\/h2>\n<p style=\"text-align: justify;\">There are three basic types of transactions in\u00a0SQL Server:<\/p>\n<ol style=\"text-align: justify;\">\n<li><em>Explicit<\/em>\u00a0transactions, as the name suggests, must be explicitly started with a\u00a0BEGIN TRANSACTION\u00a0statement\u00a0and explicitly ended with either a\u00a0COMMIT TRANSACTION\u00a0statement or a\u00a0ROLLBACK TRANSACTION\u00a0statement. In other words, the\u00a0SQL Server\u00a0developer controls when the unit of work is committed or not.<\/li>\n<li><em>Autocommit<\/em>\u00a0transactions are where the developer does not control the starting and ending points of the transaction. Each\u00a0T-SQL\u00a0statement\u00a0is its own transaction that\u00a0SQL Server\u00a0begins and commits automatically under the covers. There is no concept of being able to make a change to a\u00a0SQL Server\u00a0database\u00a0without a transaction being started, as\u00a0SQL Server\u00a0must have the ability to roll back the change if something goes wrong.<\/li>\n<li><em>Implicit<\/em>\u00a0transactions are when a transaction is automatically started by\u00a0SQL Server\u00a0as soon as a change is made to the database, but remains active until it is explicitly ended. At that point a new transaction is automatically started. This behavior is not the default and must be specifically enabled using a\u00a0SET IMPLICIT_TRANSACTIONS\u00a0statement, which is not normally done except to allow behavior compatibility with another RDBMS where this is the default behavior. I&#8217;ve seen this be a problem when developers don&#8217;t realize implicit transactions are enabled and don&#8217;t think they need to explicitly commit the transaction. More on that in the &#8216;common mistakes&#8217; section below.<\/li>\n<\/ol>\n<p style=\"text-align: justify;\">With all three of these transaction types, if\u00a0SQL Server\u00a0encounters a problem the\u00a0entire transaction\u00a0will automatically roll back.<\/p>\n<p style=\"text-align: justify;\">There are also two more advanced kinds of transactions in\u00a0SQL Server, which are beyond the scope of this article:<\/p>\n<ol>\n<li style=\"text-align: justify;\"><em>Batch-scoped<\/em>\u00a0transactions, which are only used during Multiple Active Result Sets sessions.<\/li>\n<li style=\"text-align: justify;\"><em>Distributed<\/em>\u00a0transactions, which are used when a\u00a0local transaction\u00a0needs to coordinate with multiple\u00a0SQL Server\u00a0instances, for instance to run\u00a0stored procedures\u00a0with business logic on different servers. This is done using a Distributed Transaction Coordinator, or by the service itself on\u00a0Azure\u00a0Managed Instance.<\/li>\n<\/ol>\n<h2>How Does Commit Work in\u00a0SQL Server?<\/h2>\n<p>Consider a very simple example of an\u00a0explicit transaction\u00a0that inserts a record into a table, using the code:<\/p>\n<pre>BEGIN TRANSACTION;\r\nINSERT INTO\r\n  \u00a0 \u00a0MyDatabase.dbo.MyTable\r\nVALUES (1, \u2018Paul\u2019, \u2018Randal\u2019);\r\nCOMMIT TRANSACTION;<\/pre>\n<p style=\"text-align: justify;\">The\u00a0insert statement\u00a0causes some locks to be acquired, which provides the isolation portion of the ACID properties of a database. These will only be released once the transaction has committed. When the\u00a0COMMIT TRANSACTION\u00a0statement is executed, I know that the insert is now\u00a0durable. How does this actually happen?<\/p>\n<p style=\"text-align: justify;\">All changes to a database are\u00a0<em>logged<\/em>. Simply put, this means that when a change is made to a data file page, a description of the change is generated, called a\u00a0<em>log record<\/em>\u00a0and entered into the\u00a0database\u00a0transaction\u00a0log. Also when a transaction begins, there is a log record generated and another when a transaction commits. This means our simple\u00a0explicit transaction\u00a0will have three log records in the\u00a0transaction log, all with the same transaction ID, one for each of the three statements executed. In fact, if I\u2019d used an autocommit transaction instead of an\u00a0explicit transaction\u00a0(executing just the\u00a0insert statement),\u00a0SQL Server\u00a0would have automatically started and committed the transaction and there would still be three log records in the\u00a0transaction log\u00a0for the transaction. One interesting fact you might not know is that\u00a0SQL Server\u00a0usually names transactions that it starts; in this case it would have been named simply &#8216;INSERT&#8217;.<\/p>\n<p style=\"text-align: justify;\">When a transaction commits,\u00a0SQL Server\u00a0has to make sure that all the log records for the transaction are in the\u00a0transaction log\u00a0on disk and not just in memory, so in the event of a crash, the transaction can be replayed, guaranteeing its\u00a0durability. It does this by making sure that all the\u00a0transaction log\u00a0in memory up to the log record for the\u00a0COMMIT TRANSACTION\u00a0is flushed to disk before the commit is acknowledged back to the user or application. The sequence of operations when a commit occurs is:<\/p>\n<ul style=\"text-align: justify;\">\n<li>Make sure the log is flushed to disk<\/li>\n<li>If there is a synchronous database mirror or synchronous availability group replica, make sure the log is also written to disk for their\u00a0log files\u00a0on the remote servers<\/li>\n<li>Release the locks the transaction is holding<\/li>\n<li>Acknowledge the commit has happened<\/li>\n<\/ul>\n<p style=\"text-align: justify;\">There is no need to also flush the changed data file pages to disk at this point, as the transaction has already been made\u00a0durable\u00a0by making sure the description of all the changes are on disk. The data file pages will be written out later by a checkpoint operation \u2013 a topic for a future article.<\/p>\n<h2>How Does Rollback Work in\u00a0SQL Server?<\/h2>\n<p style=\"text-align: justify;\">When a transaction must be rolled back, all operations that were part of the transaction must be essentially reversed so none of the\u00a0data modifications\u00a0from the transaction are present in the database. This is done using the\u00a0transaction log, as the log records for a transaction are linked together in reverse order and this allows the transaction\u2019s changes to be undone in reverse order.<\/p>\n<p>Consider another simple example:<\/p>\n<pre>BEGIN TRANSACTION;\r\nINSERT INTO\r\n  \u00a0 \u00a0MyDatabase.dbo.MyTable\r\nVALUES (1, \u2018Paul\u2019, \u2018Randal\u2019);\r\nINSERT INTO\r\n  \u00a0 \u00a0MyDatabase.dbo.MyTable\r\nVALUES (2, \u2018Kimberly\u2019, \u2018Tripp\u2019);<\/pre>\n<p style=\"text-align: justify;\">At this point there are three log records for the transaction. If I then decide to execute a rollback command, SQL Server does the following:<\/p>\n<ol style=\"text-align: justify;\">\n<li>Find the most recent log record for the \u2018forward\u2019 part of the transaction, work out what operation will undo the change described by the log record, perform the operation, and generate a log record.<\/li>\n<li>Find the previous log record, pointed to by the \u2018previous log record\u2019 LSN.<\/li>\n<li>Repeat until the begin log record is reached. At this point the rollback has been completed, so another log record is generated that indicates that the transaction has successfully aborted.<\/li>\n<\/ol>\n<p style=\"text-align: justify;\">This will generate three more log records for my example. As you can see, rolling back a transaction takes a lot of work under the covers.<\/p>\n<p style=\"text-align: justify;\">It is also possible to define a\u00a0<em>savepoint<\/em>\u00a0using the\u00a0SAVE TRANSACTION\u00a0statement and roll back to that named point in the transaction rather than rolling the\u00a0entire transaction\u00a0back.<\/p>\n<h2>Common Mistakes That Can Cause\u00a0Transaction Log\u00a0Problems<\/h2>\n<p>The first mistake is to forget to commit a transaction. This means everything that subsequently happens on that connection is part of the same transaction. As more changes are made, more log records are generated and more\u00a0transaction log\u00a0space is required. The space used to store log records from earlier in the transaction cannot be reused (i.e. allowing the log to\u00a0<em>truncate<\/em>), as those log records must remain in case the transaction rolls back (and they\u2019re needed for the mechanism I described above). The\u00a0transaction log\u00a0will likely grow\u2026 and grow\u2026 and grow, until someone finally commits the long-running transaction and allows the log to be brought back under control.<\/p>\n<p>The second mistake is to inadvertently execute some code that does a lot more work than you thought, for instance performing an update on a very large table (e.g. a billion rows) and forgetting a WHERE clause. For every row that\u2019s updated, there\u2019s at least one log record generated so there will be at least a billion log records generated for the transaction and that will likely cause explosive\u00a0transaction log\u00a0growth. A DBA that doesn\u2019t know how rollback works might be tempted to immediately cancel the update. But a knowledgeable DBA will know that rolling back a very long-running transaction will generate at least the same number of log records as have already been generated, taking a lot more time, and may decide that the prudent course of action is to let the update complete.<\/p>\n<p>If you have a\u00a0transaction log\u00a0that is seemingly growing out of control, you can see why by running this code:<\/p>\n<pre>SELECT\r\n  \u00a0 \u00a0[log_reuse_wait_desc]\r\nFROM [master].[sys].[databases]\r\nWHERE\r\n  \u00a0 [name] = N'MyDatabase';<\/pre>\n<p>If one of these two mistake scenario is the culprit, the output will look like this:<\/p>\n<pre>log_reuse_wait_desc\r\n-------------------\r\nACTIVE_TRANSACTION<\/pre>\n<p>If not, you can read about the other possible values and what they mean in the\u00a0Microsoft\u00a0documentation\u00a0<a href=\"https:\/\/docs.microsoft.com\/en-us\/sql\/relational-databases\/logs\/the-transaction-log-sql-server?view=sql-server-ver15\">here<\/a>, in the section\u00a0<em>Factors that can delay log truncation<\/em>.<\/p>\n<h2>Importance of Understanding Transactions in\u00a0SQL Server<\/h2>\n<p>Not only is it important to understand what transactions are and design your code to make sure that it is appropriately implementing your business logic, it is also important to understand some of the internals that I\u2019ve described as making mistakes can cause problems for\u00a0database administrators. In my experience,\u00a0database administrators\u00a0often need to know how transactions work and what the potential mistakes that can be made are so they can troubleshoot issues around the\u00a0transaction log.<\/p>\n<p>There are many more facets to using transactions, such as specifying\u00a0isolation levels\u00a0and designing efficient code, but I hope this initial primer has given you a good grounding in why transactions are needed and how they work. I know it&#8217;s a bit of a cliche, but with\u00a0SQL Server, it&#8217;s definitely a case of the more you know, the further you&#8217;ll go!<\/p>\n","protected":false},"excerpt":{"rendered":"<p>(The original version of this post first appeared on the now-deleted SentryOne blog at the start of 2022.) One of the most fundamental concepts in any relational database management system (RDBMS), such as SQL Server, is the transaction. During my consulting career, I&#8217;ve seen many instances of performance problems caused by developers not understanding how [&hellip;]<\/p>\n","protected":false},"author":5,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[108,98],"tags":[],"class_list":["post-5351","post","type-post","status-publish","format-standard","hentry","category-sql101","category-transaction-log"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v26.5 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>SQL101: Introduction to SQL Server Transactions - Paul S. Randal<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.sqlskills.com\/blogs\/paul\/sql101-introduction-to-sql-server-transactions\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"SQL101: Introduction to SQL Server Transactions - Paul S. Randal\" \/>\n<meta property=\"og:description\" content=\"(The original version of this post first appeared on the now-deleted SentryOne blog at the start of 2022.) One of the most fundamental concepts in any relational database management system (RDBMS), such as SQL Server, is the transaction. During my consulting career, I&#8217;ve seen many instances of performance problems caused by developers not understanding how [&hellip;]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.sqlskills.com\/blogs\/paul\/sql101-introduction-to-sql-server-transactions\/\" \/>\n<meta property=\"og:site_name\" content=\"Paul S. Randal\" \/>\n<meta property=\"article:published_time\" content=\"2026-02-20T22:30:38+00:00\" \/>\n<meta name=\"author\" content=\"Paul Randal\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Paul Randal\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"10 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.sqlskills.com\/blogs\/paul\/sql101-introduction-to-sql-server-transactions\/\",\"url\":\"https:\/\/www.sqlskills.com\/blogs\/paul\/sql101-introduction-to-sql-server-transactions\/\",\"name\":\"SQL101: Introduction to SQL Server Transactions - Paul S. Randal\",\"isPartOf\":{\"@id\":\"https:\/\/www.sqlskills.com\/blogs\/paul\/#website\"},\"datePublished\":\"2026-02-20T22:30:38+00:00\",\"author\":{\"@id\":\"https:\/\/www.sqlskills.com\/blogs\/paul\/#\/schema\/person\/ffcec826c18782e1e0adf173826a7fce\"},\"breadcrumb\":{\"@id\":\"https:\/\/www.sqlskills.com\/blogs\/paul\/sql101-introduction-to-sql-server-transactions\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.sqlskills.com\/blogs\/paul\/sql101-introduction-to-sql-server-transactions\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.sqlskills.com\/blogs\/paul\/sql101-introduction-to-sql-server-transactions\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.sqlskills.com\/blogs\/paul\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"SQL101: Introduction to SQL Server Transactions\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.sqlskills.com\/blogs\/paul\/#website\",\"url\":\"https:\/\/www.sqlskills.com\/blogs\/paul\/\",\"name\":\"Paul S. Randal\",\"description\":\"In Recovery...\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.sqlskills.com\/blogs\/paul\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.sqlskills.com\/blogs\/paul\/#\/schema\/person\/ffcec826c18782e1e0adf173826a7fce\",\"name\":\"Paul Randal\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.sqlskills.com\/blogs\/paul\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/0b6a266bba2f088f2551ef529293001bd73bf026bc1908b9866728c062beeeb6?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/0b6a266bba2f088f2551ef529293001bd73bf026bc1908b9866728c062beeeb6?s=96&d=mm&r=g\",\"caption\":\"Paul Randal\"},\"sameAs\":[\"http:\/\/3.209.169.194\/blogs\/paul\"],\"url\":\"https:\/\/www.sqlskills.com\/blogs\/paul\/author\/paul\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"SQL101: Introduction to SQL Server Transactions - Paul S. Randal","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.sqlskills.com\/blogs\/paul\/sql101-introduction-to-sql-server-transactions\/","og_locale":"en_US","og_type":"article","og_title":"SQL101: Introduction to SQL Server Transactions - Paul S. Randal","og_description":"(The original version of this post first appeared on the now-deleted SentryOne blog at the start of 2022.) One of the most fundamental concepts in any relational database management system (RDBMS), such as SQL Server, is the transaction. During my consulting career, I&#8217;ve seen many instances of performance problems caused by developers not understanding how [&hellip;]","og_url":"https:\/\/www.sqlskills.com\/blogs\/paul\/sql101-introduction-to-sql-server-transactions\/","og_site_name":"Paul S. Randal","article_published_time":"2026-02-20T22:30:38+00:00","author":"Paul Randal","twitter_misc":{"Written by":"Paul Randal","Est. reading time":"10 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/www.sqlskills.com\/blogs\/paul\/sql101-introduction-to-sql-server-transactions\/","url":"https:\/\/www.sqlskills.com\/blogs\/paul\/sql101-introduction-to-sql-server-transactions\/","name":"SQL101: Introduction to SQL Server Transactions - Paul S. Randal","isPartOf":{"@id":"https:\/\/www.sqlskills.com\/blogs\/paul\/#website"},"datePublished":"2026-02-20T22:30:38+00:00","author":{"@id":"https:\/\/www.sqlskills.com\/blogs\/paul\/#\/schema\/person\/ffcec826c18782e1e0adf173826a7fce"},"breadcrumb":{"@id":"https:\/\/www.sqlskills.com\/blogs\/paul\/sql101-introduction-to-sql-server-transactions\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.sqlskills.com\/blogs\/paul\/sql101-introduction-to-sql-server-transactions\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.sqlskills.com\/blogs\/paul\/sql101-introduction-to-sql-server-transactions\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.sqlskills.com\/blogs\/paul\/"},{"@type":"ListItem","position":2,"name":"SQL101: Introduction to SQL Server Transactions"}]},{"@type":"WebSite","@id":"https:\/\/www.sqlskills.com\/blogs\/paul\/#website","url":"https:\/\/www.sqlskills.com\/blogs\/paul\/","name":"Paul S. Randal","description":"In Recovery...","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.sqlskills.com\/blogs\/paul\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.sqlskills.com\/blogs\/paul\/#\/schema\/person\/ffcec826c18782e1e0adf173826a7fce","name":"Paul Randal","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.sqlskills.com\/blogs\/paul\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/0b6a266bba2f088f2551ef529293001bd73bf026bc1908b9866728c062beeeb6?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/0b6a266bba2f088f2551ef529293001bd73bf026bc1908b9866728c062beeeb6?s=96&d=mm&r=g","caption":"Paul Randal"},"sameAs":["http:\/\/3.209.169.194\/blogs\/paul"],"url":"https:\/\/www.sqlskills.com\/blogs\/paul\/author\/paul\/"}]}},"_links":{"self":[{"href":"https:\/\/www.sqlskills.com\/blogs\/paul\/wp-json\/wp\/v2\/posts\/5351","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.sqlskills.com\/blogs\/paul\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.sqlskills.com\/blogs\/paul\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.sqlskills.com\/blogs\/paul\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/www.sqlskills.com\/blogs\/paul\/wp-json\/wp\/v2\/comments?post=5351"}],"version-history":[{"count":0,"href":"https:\/\/www.sqlskills.com\/blogs\/paul\/wp-json\/wp\/v2\/posts\/5351\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.sqlskills.com\/blogs\/paul\/wp-json\/wp\/v2\/media?parent=5351"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.sqlskills.com\/blogs\/paul\/wp-json\/wp\/v2\/categories?post=5351"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.sqlskills.com\/blogs\/paul\/wp-json\/wp\/v2\/tags?post=5351"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}