A lot of that might be good luck :-)

For example, moving a file *on the same file system* often just updates directory metadata without actually moving the file at all, so database writes could continue without error.

But lets say it was more dramatic than that - that the actual got physically moved. We *still* might have "not noticed" at the database level.

Because the database is very "lazy" but in a good way :-) The thing that *really* matters to us is the redo logs - the true record of every change done in the database. So as long as that is committed to disk, then we know the true history of the database.

Theoretically, if you only had every redo log since the database was created, you could resurrect the database at any point in time in the past, as well as its current state.

The *problem* with that would be performance:

"select * from test01"

would need to:

- start at time zero (database creation)
- walk through every change to the database (including the "create table test01" command) and apply every single change to any block that was related to test01 and eventually, when every piece of redo had been examined, you would have the state of test01 at the current point in time.

That is obviously not practical. So the datafiles are there almost as as a "performance benefit". They in effect contain a snapshot of the blocks so that for most queries, we could *start* with the data in the datafiles, which might reflect (say) the state of the database about 1 minute ago, and then combine that with what we have in memory, what we have in our undo segments, to define what we mean by "current state"

What does this mean ? It means that we do not *have* to write changes that you make *immediately* down to the datafiles. As long as we write the redo logs, we're covered. So blocks that we have in memory contain the changed data (ie, the most current data), but the datafiles could be "stale". After all, why bother going to the extra effort of writing the datafiles if we dont have to...that just makes things slower.

Eventually, as our memory fills with modified blocks, we'll have to make some space for new blocks to come in, so at that point in time, we'll take the opportunity to write those modified blocks back down to the datafiles.

Obviously, the real algorithms for deciding when and what to write to the datafiles is fairly complicated, and there are many scenarios in which datafiles must be up to date etc. But hopefully you get the idea.

One of those scenarios was trying to bring the tablespace online - we did a proper check of the datafile...and failed.

For example (I'm assuming this is a testing database you're just playing with), you could repeat your experiment, but continue to make other changes - eventually you'll start to see things go bad as the database eventually decides it needs to use/access that datafile and its gone missing.