Which operation typically requires a Share (S) lock?
Which operation typically requires a Share (S) lock?
A Share (S) lock is commonly used during read operations to prevent other transactions from modifying the data being read. The SELECT operation typically requires a Share (S) lock to ensure that the data remains consistent and is not changed by other transactions while it is being read.
B is correct Read-only This processing type includes all SELECT statements that are intrinsically read-only, have an explicit FOR READ ONLY clause, or are ambiguous, but the query compiler assumes that they are read-only because of the BLOCKING option value that the PREP or BIND command specifies. This type requires only share locks (IS, NS, or S). Intent to change This processing type includes all SELECT statements that have a FOR UPDATE clause, a USE AND KEEP UPDATE LOCKS clause, a USE AND KEEP EXCLUSIVE LOCKS clause, or are ambiguous, but the query compiler assumes that change is intended. This type uses share and update locks (S, U, or X for rows; IX, S, U, or X for blocks; and IX, U, or X for tables). Change This processing type includes UPDATE, INSERT, and DELETE statements, but not UPDATE WHERE CURRENT OF or DELETE WHERE CURRENT OF. This type requires exclusive locks (IX or X). https://www.ibm.com/support/knowledgecenter/SSEPGG_11.1.0/com.ibm.db2.luw.admin.perf.doc/doc/c0009697.html
By default, the isolation level is CS (Cursor Stability). If you read a table with SELECT, you hold a shared lock on the read row. THe good answer will be "B. SELECT"
UPDATE, DELETE and INSERT operations will hold a X lock (eXclusive lock).