Is it possible to somehow emulate shared row locks (as they exist in other DBMS, like PostgreSQL) in Oracle DB?
That is row locks, that allow other session to obtain the same (shared) locks on the same row, but prevent them from obtaining exclusive locks. Also, an existing exclusive lock on a row prevent others obtaining any kind of row lock.
For reference: Oracle supports only exclusive row locks.
Note: The question is about Oracle DB 11.2g
Related
What is the difference between row lock and table lock in Oracle database.
will for loop with update statement trigger table lock ??
Any DML statement on a table is going to acquire a table lock. But it is terribly unlikely that this table lock is going to affect another session in a way that limits concurrency. When your session updates rows, there will be a row exclusive table lock which will stop another session from doing DDL on the table (say, adding or removing a column) while there are active, uncommitted transactions involving the table. But presumably, you're not generally trying to modify the structure of the table at the same time that you're updating rows in the table (or understand that when you deploy these DDL changes that you'll block other sessions for a short period of time and you're picking your deployment times accordingly).
The specific rows that you are updating will be locked in order to prevent another session from modifying those rows until your transaction either commits or rolls back. Those row level locks are generally the locks that cause performance and scalability issues. Ideally, your code would be structured to hold the locks for as little time as possible (updating data in sets is much faster than doing row-by-row updates) and to minimize the probability that two sessions will try to update the same row simultaneously.
Does sqoop export issue any locks while exporting the data from hive to db2?
What type of lock does it issue? If there is a lock how are these locks released?
I get a validation error as there are parallel sqoop export process running on the same db2 table. Hence, wondering if there are any locks issued and what type of locks.
Yes Aavik, DB2 supports locks. There are three types of locks.
1. S lock (share)
2. U lock (update)
3. X lock (exclusive)
When you scan the table to read the data, for E.g when you do select * from table where <condition>, it does a read operation on the table, when it reads the data from the table it applies S lock on the table, meaning other requests can read the data, but cannot update or write.
When you do transactions on the table it applies U lock.
When you insert new data it acquires X lock, meaning it doesn't allow any read operation or update operation.
So, when you do sqoop export from Hive to DB2 it acquires X lock on
the table as it is inserting new records.
When you do sqoop import, it acquires S lock on the table.
This is a very common problem everywhere, you have many options to overcome this issue.
1. maintain separate views/Tables for regular transactions.
2. Increase number of max retries or write a shell script which checks if DB2 is free from locks, basically you've to create a dependency, I know this will become bit complicated, there may be better ways to do though.
Hope this gives you a better understanding.
It says on the documentation that oracle 12c, aquires a table lock when a row lock is aquired.That is not so in sql server, it is very baffling.
A row lock, also called a TX lock, is a lock on a single row of a table. A transaction acquires a row lock for each row modified by one of the following statements: INSERT, UPDATE, DELETE, MERGE, and SELECT ... FOR UPDATE. The row lock exists until the transaction commits or rolls back.
***When a transaction obtains a row lock for a row, the transaction also acquires a table lock for the table in which the row resides***. The table lock prevents conflicting DDL operations that would override data changes in a current transaction.
Can somebody elucidate this?
The table lock that occurs is a shared lock. There can be any number of shared locks allowed on the same table at the same time: they do not interfere with one another.
What they do do is prevent anything from acquiring an exclusive lock on that table: say, to change the structure of the table.
Please anyone explain locking mode in Oracle i.e. Share, Exclusive and Update lock. I found many theories on this and according to that
Share lock : Nobody can change data,Read only purpose
Exclusive lock : Only one user/connection are allow to change the data.
Update lock : Rows are locked till user made commit/rollback.
Then, I tried shared to check how it works
SQL> lock table emp in share mode;
Table(s) Locked.
SQL> update emp set sal=sal+10;
14 rows updated.
Then, I found that, user can change data after share lock. Then, what makes it different from exclusive lock and update lock.
Another question, how Update lock and exclusive lock are different with each other, even they seems almost equivalent.
Posting explanation for future visitors, and it also gives the answer.
Shared lock
Before I begin let me first say that there are 5 types of table locks - row shared, row exclusive, shared, shared row exclusive and exclusive. And shared lock is one among these. Also, please note that there are row locks, which are different than table locks. Follow the link I have provided in end to read about all this.
A shared lock is acquired on the table specified in following statement – LOCK TABLE table IN SHARE MODE;
This lock prevents other transactions from getting “row exclusive” (this lock is used by INSERT, UPDATE and DELETE statement), “shared row exclusive” and “exclusive” table locks, otherwise everything is permitted.
So, this means that a shared lock will block other transactions from executing INSERT, UPDATE and DELETE statements on that table but will allow other transactions to update the rows using “SELECT … FOR UPDATE” statement because for this statement a “row shared” lock is required, and it is permitted when a “shared” lock is required.
Below table is a good summary of locks and what's permitted.
Since many users will follow this question so I decided to go one more step further and put my learning notes, I hope folks will be benefited from it:
Source of this information and also excellent reading about Oracle locks.
It's very well explained in the documentation: http://docs.oracle.com/cd/E11882_01/server.112/e41084/ap_locks001.htm#SQLRF55502
In your example you locked the table in shared mode. This does not prevent other sessions locking the same object in shared mode, but it does prevent them from locking it in exclusive mode so you could not drop the table (which requires an exclusive lock) while it is being updated (which has a shared lock).
I have a global temp table which is set as delete on commit. How does it behave on concurrency issue? I mean what happens if another session wants to use that global temporary table? The answer will probably not be "they share the same data".
Now, if my guess is correct :), is the table locked until the first connection commits, or does the dbms create a global temp table for each connection? ( something like an instance of the table? )
From the documentation:
The data in a temporary table is visible only to the session that inserts the data into the table.
Each session will have its logical independent copy of the temporary table.
Since you can not see other sessions' data and since Oracle deals with locks at the row level, you can not be blocked by other sessions' DML. Concurrent DML (Insert, Delete, Update) won't affect other sessions.
Only DDL will need a lock on the table (ie: ALTER TABLE...)