For a long running report, do I use a read only or serializable transaction?

Question

I have a long running report written in SQL*Plus with a couple of SELECTs. I'd like to change the transaction isolation level to get a consistent view on the data. I found two possible solutions:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

and

SET TRANSACTION READ ONLY;

Which one do I use for a report and why? Any performance implications? Any implications on other sessions (this is a production database).

Please note that the question is specifically about the two options above, not about the various isolation levels.

Does SERIALIZABLE blocks changes to a table that is queried for my report?

I would naively assume that READ ONLY is a little bit less stressful for the database, as there are no data changes to be expected. Is this true, does Oracle take advantage of that?

Answer 1

In Oracle, you can really choose between SERIALIZABLE and READ COMMITTED .

READ ONLY is the same as serializable, in regard to the way it sees other sessions' changes, with the exception it does not allow table modifications.

With SERIALIZABLE or READ ONLY your queries won't see the changes made to the database after your serializable transaction had begun.

With READ COMMITTED , your queries won't see the changes made to the database during the queries' lifetime.

SERIALIZABLE       READ COMMITTED      ANOTHER SESSION
(or READ ONLY)


                                       Change 1
Transaction start  Transaction start
                                       Change 2
Query1 Start       Query1 Start
...                ...                 Change 3
Query1 End         Query1 End

Query2 Start       Query2 Start
...                ...                 Change 4
Query2 End         Query2 End

With serializable, query1 and query2 will only see change1.

With read committed, query1 will see changes 1 and 2, and query2 will see changes 1 through 3.

Answer 2

Interesting question. I believe that SERIALIZABLE and READ ONLY would have the same "tax" on the database, and would be greater than that of READ COMITTED (usually the default). There shouldn't be a significant performance difference to you or other concurrent users. However, if the database can't maintain your read consistency due to too small of UNDO tablespace or too short undo_retention (default is 15 minutes), then your query will fail with the infamous ORA-01555 . Other users shouldn't experience pain, unless there are other users trying to do something similar. Ask your DBA what the undo_retention parameter is set at and how big the UNDO tablespace and whether or not it's autoextensible.

If there's a similarly sized non-prod environment, try benchmarking your queries with different isolation levels. Check the database for user locks after the 1st query runs (or have your DBA check if you don't have enough privileges). Do this test several times, each with different isolation levels. Basically, documentation is great, but an experiment is often quicker and unequivocal.

Finally, to dodge the issue completely, is there any way you could combine your two queries into one, perhaps with a UNION ALL ? This depends largely on the relationship of your two queries. If so, then the question becomes moot. The one combined query would be self-consistent.

Answer 3

.. a lot of questions.

1. Both isolation levels are equivalent for sessions that only use selects. So it does not make a difference which one you choose. (READ ONLY is not a ANSI Standard)

2. Except performance influences, there are no implications from other sessions or to other sessions inside a session with transaction isolation level SERIALIZABLE or READ ONLY, unless you commit anything in this session (SERIALIZABLE only).

3. Performance of your select inside these two isolation levels should not differ because you don't change data there.

4. Performance using one of these two isolation levels compared against Oracle default READ COMMITTED is not optimal. Especially if a lot of data is changing during your SERIALIZABLE transaction, you can expect a performance downside.

5. I would naively assume that READ ONLY is a little bit less stressful for the database, as there are no data changes to be expected. Is this true, does Oracle take advantage of that?

   => No.

hope this helps.

Answer 4

This article from the Oracle documentation gives a lot of detailed info about the different transaction isolation levels. http://docs.oracle.com/cd/B10501_01/server.920/a96524/c21cnsis.htm

In your example, it sounds like you are wanting Serializable . Oracle does not block when reading data, so using serializable in your read-only query should not block queries or crud operations in other transactions.

As mentioned in other answers, using the read only isolation level is similar to using serializable , except that read only does not allow inserts, updates, or deletes. However, since read only is not an SQL standard and serializable is, then I would use serializable in this situation since it should accomplish the same thing, will be clear for other developers in the future, and because Oracle provides more detailed documentation about what is going with "behind the scenes" with the serializable isolation level.

Here is some info about serializable, from the article referenced above (I added some comments in square brackets for clarification):

Serializable isolation mode provides somewhat more consistency by protecting against phantoms [reading inserts from other transactions] and nonrepeatable reads [reading updates/deletes from other transactions] and can be important where a read/write transaction executes a query more than once.

Unlike other implementations of serializable isolation, which lock blocks for read as well as write, Oracle provides nonblocking queries [non-blocking reads] and the fine granularity of row-level locking, both of which reduce write/write contention.