<?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>Comments on: On restoring a single table from mysqldump</title>
	<atom:link href="http://code.openark.org/blog/mysql/on-restoring-a-single-table-from-mysqldump/feed" rel="self" type="application/rss+xml" />
	<link>http://code.openark.org/blog/mysql/on-restoring-a-single-table-from-mysqldump</link>
	<description>Blog by Shlomi Noach</description>
	<lastBuildDate>Wed, 01 Feb 2012 20:47:51 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: 切割mysqldump文件工具</title>
		<link>http://code.openark.org/blog/mysql/on-restoring-a-single-table-from-mysqldump/comment-page-1#comment-63668</link>
		<dc:creator>切割mysqldump文件工具</dc:creator>
		<pubDate>Tue, 20 Dec 2011 11:08:20 +0000</pubDate>
		<guid isPermaLink="false">http://code.openark.org/blog/?p=1630#comment-63668</guid>
		<description>[...] On restoring a single table from mysqldump：这篇文章则对比了使用grep sed 和“权限控制”三种方法的速度。 [...]</description>
		<content:encoded><![CDATA[<p>[...] On restoring a single table from mysqldump：这篇文章则对比了使用grep sed 和“权限控制”三种方法的速度。 [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: 使用tbdba-restore-mysqldump.pl切割mysqldump文件 &#124; 岭南六少 - 一朵在LAMP架构下挣扎的云</title>
		<link>http://code.openark.org/blog/mysql/on-restoring-a-single-table-from-mysqldump/comment-page-1#comment-63543</link>
		<dc:creator>使用tbdba-restore-mysqldump.pl切割mysqldump文件 &#124; 岭南六少 - 一朵在LAMP架构下挣扎的云</dc:creator>
		<pubDate>Mon, 19 Dec 2011 11:48:32 +0000</pubDate>
		<guid isPermaLink="false">http://code.openark.org/blog/?p=1630#comment-63543</guid>
		<description>[...] On restoring a single table from mysqldump：这篇文章则对比了使用grep sed 和“权限控制”三种方法的速度。 [...]</description>
		<content:encoded><![CDATA[<p>[...] On restoring a single table from mysqldump：这篇文章则对比了使用grep sed 和“权限控制”三种方法的速度。 [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: 使用tbdba-restore-mysqldump.pl切割mysqldump文件 - 一个故事@MySQL DBA</title>
		<link>http://code.openark.org/blog/mysql/on-restoring-a-single-table-from-mysqldump/comment-page-1#comment-62941</link>
		<dc:creator>使用tbdba-restore-mysqldump.pl切割mysqldump文件 - 一个故事@MySQL DBA</dc:creator>
		<pubDate>Wed, 14 Dec 2011 14:41:06 +0000</pubDate>
		<guid isPermaLink="false">http://code.openark.org/blog/?p=1630#comment-62941</guid>
		<description>[...] On restoring a single table from mysqldump：这篇文章则对比了使用grep sed 和“权限控制”三种方法的速度。 [...]</description>
		<content:encoded><![CDATA[<p>[...] On restoring a single table from mysqldump：这篇文章则对比了使用grep sed 和“权限控制”三种方法的速度。 [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Useful sed / awk liners for MySQL &#124; code.openark.org</title>
		<link>http://code.openark.org/blog/mysql/on-restoring-a-single-table-from-mysqldump/comment-page-1#comment-45513</link>
		<dc:creator>Useful sed / awk liners for MySQL &#124; code.openark.org</dc:creator>
		<pubDate>Wed, 06 Jul 2011 06:41:04 +0000</pubDate>
		<guid isPermaLink="false">http://code.openark.org/blog/?p=1630#comment-45513</guid>
		<description>[...] On restoring a single table from mysqldump [...]</description>
		<content:encoded><![CDATA[<p>[...] On restoring a single table from mysqldump [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Extract satu tabel dari file backup mysqldump &#171; Setsuga&#039;s Weblog</title>
		<link>http://code.openark.org/blog/mysql/on-restoring-a-single-table-from-mysqldump/comment-page-1#comment-41590</link>
		<dc:creator>Extract satu tabel dari file backup mysqldump &#171; Setsuga&#039;s Weblog</dc:creator>
		<pubDate>Mon, 30 May 2011 10:29:15 +0000</pubDate>
		<guid isPermaLink="false">http://code.openark.org/blog/?p=1630#comment-41590</guid>
		<description>[...] tidak lupa saya cantumkan link asli     GA_googleAddAttr(&quot;AdOpt&quot;, &quot;1&quot;); GA_googleAddAttr(&quot;Origin&quot;, &quot;other&quot;); [...]</description>
		<content:encoded><![CDATA[<p>[...] tidak lupa saya cantumkan link asli     GA_googleAddAttr(&quot;AdOpt&quot;, &quot;1&quot;); GA_googleAddAttr(&quot;Origin&quot;, &quot;other&quot;); [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Vitaly</title>
		<link>http://code.openark.org/blog/mysql/on-restoring-a-single-table-from-mysqldump/comment-page-1#comment-17217</link>
		<dc:creator>Vitaly</dc:creator>
		<pubDate>Thu, 02 Sep 2010 11:00:21 +0000</pubDate>
		<guid isPermaLink="false">http://code.openark.org/blog/?p=1630#comment-17217</guid>
		<description>Even it&#039;s not directly related to this topic, I noticed that if we cutting specific table dump from the whole DB dump there is a problem with  restoring of TIMESTAMP fields - they become UTC instead of local time.

adding 

/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE=&#039;+00:00&#039; */;


(as we have in a dump produced by mysqldump) before table data fixes this problem.

Regards,
Vitaly Karasik</description>
		<content:encoded><![CDATA[<p>Even it's not directly related to this topic, I noticed that if we cutting specific table dump from the whole DB dump there is a problem with  restoring of TIMESTAMP fields - they become UTC instead of local time.</p>
<p>adding </p>
<p>/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;<br />
/*!40103 SET TIME_ZONE='+00:00' */;</p>
<p>(as we have in a dump produced by mysqldump) before table data fixes this problem.</p>
<p>Regards,<br />
Vitaly Karasik</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: shlomi</title>
		<link>http://code.openark.org/blog/mysql/on-restoring-a-single-table-from-mysqldump/comment-page-1#comment-8111</link>
		<dc:creator>shlomi</dc:creator>
		<pubDate>Tue, 15 Dec 2009 13:31:30 +0000</pubDate>
		<guid isPermaLink="false">http://code.openark.org/blog/?p=1630#comment-8111</guid>
		<description>@TVNshack

sed can come in handy here, too.</description>
		<content:encoded><![CDATA[<p>@TVNshack</p>
<p>sed can come in handy here, too.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: TVNshack</title>
		<link>http://code.openark.org/blog/mysql/on-restoring-a-single-table-from-mysqldump/comment-page-1#comment-8106</link>
		<dc:creator>TVNshack</dc:creator>
		<pubDate>Tue, 15 Dec 2009 11:15:39 +0000</pubDate>
		<guid isPermaLink="false">http://code.openark.org/blog/?p=1630#comment-8106</guid>
		<description>Watchout the problem of the automatically generated AUTO_INCREMENT table option that mysqldump generates and that MATCH only with the INSERT statements that may come right after in the dump.

Even if you specify a --no-data, that AUTO_INCREMENT=nnn table option will still appear. If you intend to create a table from that extracted definition and for which you may not want to insert the exact same data, LAST_INSERT_ID will not be adapted for the need of your empty table. Your table first row inserted relying on AUTO_INCREMENT column definition option will start with an offset AUTO_INCREMENT value.

I would recommend to edit the mysqldump output to reset each AUTO_INCREMENT table option to AUTO_INCREMENT=1 and let the eventual INSERTs manage LAST_INSERT_ID

(see bug #44425)</description>
		<content:encoded><![CDATA[<p>Watchout the problem of the automatically generated AUTO_INCREMENT table option that mysqldump generates and that MATCH only with the INSERT statements that may come right after in the dump.</p>
<p>Even if you specify a --no-data, that AUTO_INCREMENT=nnn table option will still appear. If you intend to create a table from that extracted definition and for which you may not want to insert the exact same data, LAST_INSERT_ID will not be adapted for the need of your empty table. Your table first row inserted relying on AUTO_INCREMENT column definition option will start with an offset AUTO_INCREMENT value.</p>
<p>I would recommend to edit the mysqldump output to reset each AUTO_INCREMENT table option to AUTO_INCREMENT=1 and let the eventual INSERTs manage LAST_INSERT_ID</p>
<p>(see bug #44425)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Log Buffer #171: a Carnival of the Vanities for DBAs &#124; The Pythian Blog</title>
		<link>http://code.openark.org/blog/mysql/on-restoring-a-single-table-from-mysqldump/comment-page-1#comment-7693</link>
		<dc:creator>Log Buffer #171: a Carnival of the Vanities for DBAs &#124; The Pythian Blog</dc:creator>
		<pubDate>Fri, 04 Dec 2009 18:05:02 +0000</pubDate>
		<guid isPermaLink="false">http://code.openark.org/blog/?p=1630#comment-7693</guid>
		<description>[...] Noach shares his thoughts on restoring a single table from mysqldump. &#8220;Given a dump file (generated by mysqldump), how do you restore a single table, without [...]</description>
		<content:encoded><![CDATA[<p>[...] Noach shares his thoughts on restoring a single table from mysqldump. &#8220;Given a dump file (generated by mysqldump), how do you restore a single table, without [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Gavin Towey</title>
		<link>http://code.openark.org/blog/mysql/on-restoring-a-single-table-from-mysqldump/comment-page-1#comment-7584</link>
		<dc:creator>Gavin Towey</dc:creator>
		<pubDate>Thu, 03 Dec 2009 00:32:08 +0000</pubDate>
		<guid isPermaLink="false">http://code.openark.org/blog/?p=1630#comment-7584</guid>
		<description>Nice! The sed only method is a good improvement.</description>
		<content:encoded><![CDATA[<p>Nice! The sed only method is a good improvement.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

