<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Commentaires sur : Principes d&#8217;une sauvegarde à chaud</title>
	<atom:link href="http://blog.capdata.fr/index.php/sql-server-principes-dune-sauvegarde-a-chaud/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.capdata.fr/index.php/sql-server-principes-dune-sauvegarde-a-chaud/</link>
	<description>Le blog technique sur les bases de données de CAP DATA Consulting</description>
	<lastBuildDate>Fri, 16 Dec 2011 16:49:12 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Par : David B.</title>
		<link>http://blog.capdata.fr/index.php/sql-server-principes-dune-sauvegarde-a-chaud/comment-page-1/#comment-272</link>
		<dc:creator>David B.</dc:creator>
		<pubDate>Mon, 15 Mar 2010 09:47:32 +0000</pubDate>
		<guid isPermaLink="false">https://www.alldb.fr/blogs/?p=47#comment-272</guid>
		<description>Hello Frédéric,

Merci pour ton commentaire, mais je ne suis pas sûr de bien comprendre. 

Imagines une transaction qui débute avant le début du backup database. Elle va modifier des pages dans le BUFFER POOL, puis le backup database va commencer par exécuter un checkpoint et écrire ces pages dans le fichier de données. Ensuite, ces pages vont être lues et écrites dans le fichier de backup. Alors même si la transaction est annulée peu de temps après, les pages sont quand même déjà dans le fichier de backup, et il faudra bien les invalider quand on va remonter la sauvegarde. 

J&#039;ai peut être mal compris ce que tu voulais dire ?

A+ David B.</description>
		<content:encoded><![CDATA[<p>Hello Frédéric,</p>
<p>Merci pour ton commentaire, mais je ne suis pas sûr de bien comprendre. </p>
<p>Imagines une transaction qui débute avant le début du backup database. Elle va modifier des pages dans le BUFFER POOL, puis le backup database va commencer par exécuter un checkpoint et écrire ces pages dans le fichier de données. Ensuite, ces pages vont être lues et écrites dans le fichier de backup. Alors même si la transaction est annulée peu de temps après, les pages sont quand même déjà dans le fichier de backup, et il faudra bien les invalider quand on va remonter la sauvegarde. </p>
<p>J&#8217;ai peut être mal compris ce que tu voulais dire ?</p>
<p>A+ David B.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Par : sqlpro</title>
		<link>http://blog.capdata.fr/index.php/sql-server-principes-dune-sauvegarde-a-chaud/comment-page-1/#comment-261</link>
		<dc:creator>sqlpro</dc:creator>
		<pubDate>Wed, 10 Mar 2010 16:14:18 +0000</pubDate>
		<guid isPermaLink="false">https://www.alldb.fr/blogs/?p=47#comment-261</guid>
		<description>Juste une petite remarque sur cet excellent article : depuis la version 2005, SQL Server ne rejoue plus les transactions rollbackées lors des restaurations.

A +</description>
		<content:encoded><![CDATA[<p>Juste une petite remarque sur cet excellent article : depuis la version 2005, SQL Server ne rejoue plus les transactions rollbackées lors des restaurations.</p>
<p>A +</p>
]]></content:encoded>
	</item>
</channel>
</rss>

