If an operation is being written by more than one user on a specific field at the same time, it is not allowed by the database, and this is enforced through the application of a locking policy.

However, some programmers and designers cause an increase in lock operations through some faulty applications, which negatively affects the database tool. This requires a redesign of the operations to work with high efficiency, but this does not negate the locking operation, which is part of the database policy. However, it does reduce the locking operations that result from mistakes in the development or design process, and from those problems:

1. Operations that take a long time naturally create lock problems, as some users perform multiple operations and then leave to proceed with some tasks without committing those operations or rolling back from them. This certainly causes many problems that should be avoided in the design of programs. Such errors in programming cause many issues for the database administrator.
2. Using high locking levels; some operations may require locking a specific field, and thus lock all tables, which prevents other operations that could be executed during the execution of the operation that locked all tables.
3. Writing some programs that perform specific tasks poorly affects performance clearly.

But if a session locks a specific field or table, and then another session requests to write to the same field, this session will remain blocked. It may take a long time due to poor planning. Generally, in emergency situations, a database administrator can intervene to resolve this issue by terminating that session.

When that session that is holding the table or field is terminated, the lock is released and the problem is resolved.

The database administrator can resolve that blockage through the command ALTER SYSTEM KILL SESSION, which requires specifying (SERIAL# & SID) for the session, and this can be done through querying V$SESSION.