Professional Documents
Culture Documents
Enq JI
Enq JI
Enq JI
This enqueue used to prevent two sessions refreshing a materialized view at the same time. It is
unavoidable if the situation allows multiple sessions to refresh at the same time.
Even when multiple sessions are trying to refresh the same materialized view, the refresh process
come to a conclusion, unless one of the session that is holding the enqueue dies or killed without
the immediate option.
Following test case shows two sessions trying to refresh the same materialized view resulting in
high JI contention but both session ultimately finishing the refresh task.
begin
for i in 1 .. 10
loop
insert into x values (i, i + 10);
end loop;
end;
/
begin
for i in 1 .. 5
loop
insert into y values (i, i + 5);
end loop;
end;
/
3. On session 1 run the following pl/sql code block to create and explicitly lock an id
declare
i pls_integer;
begin
i := dbms_lock.request(10);
end;
/
4. On session 2 and 3 run the following code. Both session will hang unable to get the lock id 10 in
shared mode (which is held in exclusive mode by session 1). However once they obtain the lock
both will try to refresh (fast) the materialized view 1000 times
declare
i pls_integer;
begin
i := dbms_lock.request(10,DBMS_LOCK.S_MODE);
for i in 1 .. 1000
loop
dbms_snapshot.refresh('mvtest','F');
end loop;
end;
/
5. Release the lock on id 10 by running the following code which will start the refresh process
declare
j pls_integer;
begin
j := dbms_lock.release(10);
end;
/
6. Observer the JI contention on em console or APConsole
If the dba_waiters view was queried repeatedly while the refresh process is going on, it could be
observed that sid of session 2 and session 3 alternating between holding session and waiting
session.
Both session eventually will complete and return to sql prompt.
However as said earlier if the refresh sessions are serialized this will not result in contention and
refresh could complete much quicker. (The last bit of CPU spike at the end of the graph above).