backup of offline dropped datafile 2005-12-25 - By zhu chao
If it is locally managed tablespace, then oracle will not try to allocate
new extents to the offline dropped datafile.
If it is dictionary managed tablespace, then oracle will do that wrong
thing. And it found no file to write, then there will be no segment data ,
but some empty extent in the datafile.
Seems the original poster's DB is in noarchivelog mode. So the best solution
would be export the damanged tablespace and then drop and recreate it,
import it back. Or create a new tablespace and then move the tables one by
one during outage time.
On 12/24/05, Tanel Põder <tanel.poder.003@(protected)> wrote:
>
> Hi,
>
> > From the scenario that Koen described, it doesn't look that storage been
> > allocated for any objects in the dropped data file, so queries against
> > objects
> > shoudn't fail.
>
> If there is any table/index segment which had it's segment header block in
> the offline datafile, most queries against it will definitely fail
> (exceptions would be accessing table using ROWID access path or a cluster
> access, which doesn't have to read segment header).
>
> Index root blocks are always immediately next to segment header block, so
> indexe scans would fail.
>
> I don't have access to an Oracle DB right now, but you could try to
> allocate
> extents to a table in your USERS tablespace to see whether it will hit a
> "file inaccessible" error or not. It used to, but could be changed in
> later
> versions (although I don't really why Oracle would do that, because an
> offline drop renders tablespace physically invalid and it's only mean is
> getting rid of a corrupt/lost datafile, followed by drop tablespace).
>
> > Even if you recreate controlfiles/resetlogs (from backup or from trace),
> > offline datafile will still apear in v$datafile - there is nothing you
> can
> > do
> > about it - but from my understanding it should not cause any issue.
>
> See above, offline drop renders tablespace invalid, everything done in the
> tablespace after it is hacking.
>
> Tanel.
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
--
Regards
Zhu Chao
www.cnoug.org
<div>If it is locally managed tablespace, then oracle will not try to allocate
new extents to the offline dropped datafile.</div>
<div> </div>
<div>If it is dictionary managed tablespace, then oracle will do that wrong
thing. And it found no file to write, then there will be no segment data , but
some empty extent in the datafile. <br><br>Seems the original poster
's DB is in noarchivelog mode. So the best solution would be export the damanged
tablespace and then drop and recreate it, import it back. Or create a new
tablespace and then move the tables one by one during outage time.
</div>
<div> </div>
<div><span class="gmail_quote">On 12/24/05, <b class="gmail_sendername">Tanel
Põder</b> <<a href="mailto:tanel.poder.003@(protected)">tanel.poder.003@(protected)<
/a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0
.8ex; BORDER-LEFT: #ccc 1px solid">Hi,<br><br>> From the scenario that Koen
described, it doesn't look that storage been<br>> allocated for any objects
in the dropped data file, so queries against
<br>> objects<br>> shoudn't fail.<br><br>If there is any table/index
segment which had it's segment header block in<br>the offline datafile, most
queries against it will definitely fail<br>(exceptions would be accessing table
using ROWID access path or a cluster
<br>access, which doesn't have to read segment header).<br><br>Index root
blocks are always immediately next to segment header block, so<br>indexe scans
would fail.<br><br>I don't have access to an Oracle DB right now, but you could
try to allocate
<br>extents to a table in your USERS tablespace to see whether it will hit a<br
>"file inaccessible" error or not. It used to, but could be changed in
later<br>versions (although I don't really why Oracle would do that, because an
<br>offline drop renders tablespace physically invalid and it's only mean is<br
>getting rid of a corrupt/lost datafile, followed by drop tablespace).<br><br>
> Even if you recreate controlfiles/resetlogs (from backup or from trace),
<br>> offline datafile will still apear in v$datafile - there is nothing you
can<br>> do<br>> about it - but from my understanding it should not cause
any issue.<br><br>See above, offline drop renders tablespace invalid,
everything done in the
<br>tablespace after it is hacking.<br><br>Tanel.<br><br>--<br><a href="http:/
/www.freelists.org/webpage/oracle-l">http://www.freelists.org/webpage/oracle-l<
/a><br><br><br></blockquote></div><br><br clear="all"><br>-- <br>
Regards<br>Zhu Chao<br><a href="http://www.cnoug.org">www.cnoug.org</a><br>
|
|
