<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Move Datafile on Oracle Scripts</title><link>https://www.oraclescripts.com/tags/move-datafile/</link><description>Recent content in Move Datafile on Oracle Scripts</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>OracleScripts.com</copyright><lastBuildDate>Fri, 28 Aug 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://www.oraclescripts.com/tags/move-datafile/index.xml" rel="self" type="application/rss+xml"/><item><title>Move a Datafile Online with ALTER DATABASE MOVE DATAFILE</title><link>https://www.oraclescripts.com/post/move-a-datafile-online-with-alter-database-move-datafile/</link><pubDate>Fri, 28 Aug 2026 00:00:00 +0000</pubDate><guid>https://www.oraclescripts.com/post/move-a-datafile-online-with-alter-database-move-datafile/</guid><description>
&lt;h2 id="move-a-datafile-online-with-alter-database-move-datafile"&gt;Move a Datafile Online with ALTER DATABASE MOVE DATAFILE&lt;/h2&gt;
&lt;h2 id="purpose"&gt;Purpose&lt;/h2&gt;
&lt;p&gt;Oracle 12.1 closed a gap that had existed since the earliest releases: moving or renaming a datafile always meant taking something offline first. A DBA had three choices — switch the tablespace offline, switch the individual datafile offline, or shut the whole instance down to a mounted state — and in every case, an operating-system copy command had to run in the middle of the outage before the database (or the tablespace, or the file) could come back online. &lt;strong&gt;&lt;a href="https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/ALTER-DATABASE.html"&gt;ALTER DATABASE&lt;/a&gt;&lt;/strong&gt;'s &lt;code&gt;MOVE DATAFILE&lt;/code&gt; clause replaced all three procedures with one statement that runs while the database stays open in read/write mode, with no data loss and no maintenance window required.&lt;/p&gt;</description></item></channel></rss>