Why DDL during SELECT is possible. Or why SELECT does not put a table lock?

Question

This is a question to people who really knows Oracle internals or/and RDB theory.
(The question is relocated from another thread for not hijacking on that's original question.)
Why DDL during SELECT is possible? Or why SELECT does not put TM 2 Row Shared lock on table(s)?
This not locking causes a possibility while one session is running a long select, another can truncate and even drop table(s) that are being read by the first session.
I think, humbly assume, that Oracle does not put TM 2 lock on tables, that are being simply SELECTed, by some significant technical reason. But I do not know this reason. If somebody knows please shed a light.
Also, if you know that this behavior is totally correct from perspective of RDB theory, please explain me.
I'll try to explain my point.
It is a matter of data consistency and integrity that is supported in Oracle everywhere except this place.
a) If one session is reading data from moment T and other session changes data on its way at moment T1, the first session wont read that changed data, it will read the data that was there on moment T.
This is declared as Read Consistency principle.
b) If one session is changing data, and another session tries to truncate or drop table - the second session will fail with error ORA-00054: resource busy and acquire with NOWAIT specified.
This is declared as Data Integrity principle.
c) But why not to follow the above principles in case when one session reads data and another session tries to truncate or drop table (or do other DDL operations)?
It is counter-intuitive. Why not to put TM 2 (SS) lock during SELECT execution that would prevent DDLs on this table?
What I only can assume is that this is only because some technical difficulty or limitation.
What is this limitation or other reason in favor of which Oracle sacrificed consistency in this case?

Answer 1

user11181920 wrote:
Aman,
There was no need to clarify how DML lock works, I know that.
Also I know that in Oracle a Select does not lock neither table rows nor table itself.
The reason I mentioned it because you brought up the word change which is far better suited for DML's than DDL's as the former has a requirement to have its Undo preserved.
Again, my question was why Select does not protect itself by locking table(s), partitions and indexes?Protect from what? There is nothing wrong with doing a select. What would happen with a select doing a lock on the table before being executed in its entirety (forget DDL and DML altogether for a moment) ? State one good reason that there should be a lock for the select. If it has to, it would be always isn't it?
The keyword here is concurrency and that's what is the best when the number of locks obtained are lesser at non-required operations. A select doesn't change anything that's why in Oracle, there is no read-level lock.I am not saying about row locks while reading. They are not needed because Undo resolves concurrency.Only in the case of DML where the change is still active and the buffers are dirty. With a DDL, its an implicit commit.
I am asking why Select does not enqueue one, only one lock per object that participates in the Select?Again, my question back to you is, what good you would get from it? What purpose it would solve?
It is not very expensive, I suppose. But it would protect from DDLs that can destroy the Select's result set. You have seen in your system and in my demo(and that's what the the question was on the other thread also) that the result remains intact and its not a behavior from now. Its the same since the time I have started learning Oracle. Can you explain that why you think that the result of select statement would be wrong for a drop table? I believe, its been stated repeatedly that if the select has no requirement to look back the table, it would get completed. Only if the select needs to access the table again, it would fail. So even if we consider your explanation, there is no wrong result shown at all. Once the session encounters that the table is dropped for the statement, the execution stops right away. So where is the destroyed result?
Yes, it is less dangerous when Select does not lock table comparing with what would happen with DMLs in such case (that is why DMLs protect themselves by TM 3), it affects only the Select and its consumer, but still ... I don't understand this Oracle's decision. What is a reasoning behind it?.As I said, to improve concurrency.
Aman....