---- These lock in the "read lock", "exclusive lock", "shared exclusive lock" and many other types, and each type has "row-level locking" (one lock a record), "page-level lock" (a locked one, that is stored in the database can be recorded in the smallest allocation unit), "table-level lock" (lock the entire table).

---- If it is "row-level exclusive lock", then, subject to being locked in the bank, the other rows in the table may be modified by other users (Update) or remove (delete) operations, if it is " table-level exclusive lock ", then all other users can only query the table (select) operation, which can not be right to modify or delete any record. When the program modifications made to submit (commit), or after the rollback (rollback), the locked resources would be released, allowing other users to operate.

---- But, sometimes, because of the reasons for locking resources, not long after the submission of their work; or because of the user's reasons, such as a need to modify the transfer of data, not timely revised and submitted, but is placed on one side; or because of the way client-server client a "crash" while the server is not detected, resulting in the release of locked resources in a timely manner not affecting the operation of other users.

---- So, how to quickly diagnose and resolve user locking of resources is the database administrator to lock a challenge.

---- As the database application system more complex, once the resources are not due to the timely release of the lock case, it would create the same table to operate on a large number of users can not operate, thus affecting the use of the system. At this point, DBA should try to quickly solve the problem. However, due to the implementation of the Oracle 8.0.x "Get the user is waiting for the lock resource name" query

select a.username, a.sid, a.serial#, b.id1
  from v$session a, v$lock b
  where a.lockwait = b.kaddr

    select a.username, a.sid, a.serial#, b.id1
      from v$session a, v$lock b
     where b.id1 in
           (select distinct e.id1
              from v$session d, v$lock e
             where d.lockwait = e.kaddr)
       and a.sid = b.sid
       and b.request = 0

---- However, this method is actually "throwing the baby out with the dirty water, together." Because some users of the process, although also "inactive", and also has been a long time without activity, but it is because they are in lock wait state.

---- So, I have come up with a solution. The problem occurs through the v $ lock, v $ session view the related record-keeping in their own table set up, and then query the table, then the higher speed, you can quickly find the problem. The actual use, the effect was very good. After receiving the user to reflect a few seconds to lock up resources to identify the impact due to the process of other users, and make the appropriate treatment.

---- First, dba capacity (not necessarily for the system) log into the database, create three basic tables: my_session, my_lock, my_sqltext, and the column will be carried out inquiries to establish the corresponding index. Statement is as follows: rem from v $ session view, out of concern to the field, creating my_session table and fields in the query to use to create indexes to speed up the query speed

drop table my_session;
create table my_session
as
select a.username, a.sid, a.serial#,
a.lockwait, a.machine,a.status,
a.last_call_et,a.sql_hash_value,a.program
  from v$session a
 where 1=2 ;

create unique index my_session_u1 on my_session(sid);
create index my_session_n2 on my_session(lockwait);
create index my_session_n3 on my_session(sql_hash_value);

drop table my_lock;
create table my_lock
as
select id1, kaddr, sid, request,type
  from v$lock
 where 1=2;

create index my_lock_n1 on my_lock(sid);
create index my_lock_n2 on my_lock(kaddr);

drop table my_sqltext;
create table my_sqltext
as
select hash_value , sql_text
  from v$sqltext
 where 1=2;

create index my_sqltext_n1 on my_sqltext ( hash_value);

----At this point, if it found that the process of blocking the process of other users is a normal operation, you can notify the user to submit them to achieve the purpose of releasing the lock of resources; if it is not normal operation, that is, its status is "inactive", and its last_call_et have more time, you can execute the following statement to clear the process, the system will automatically roll back them to release the locked resources.

   alter system kill session 'sid, serial#';  

set echo off
set feedback off
prompt '删除旧记录.....'
truncate table my_session;
truncate table my_lock;
truncate table my_sqltext;

prompt '获取数据.....'
insert into my_session
select a.username, a.sid, a.serial#,
       a.lockwait, a.machine,a.status,
       a.last_call_et,a.sql_hash_value,a.program
  from v$session a
 where nvl(a.username,'NULL')< >'NULL;

insert into my_lock
select id1, kaddr, sid, request,type
  from v$lock;

insert into my_sqltext
select hash_value , sql_text
  from v$sqltext s, my_session m
 where s.hash_value=m.sql_hash_value;

column username format a10
column machine format a15
column last_call_et format 99999 heading "Seconds"
column sid format 9999

prompt "正在等待别人的用户"
select a.sid, a.serial#, 
a.machine,a.last_call_et, a.username, b.id1
  from my_session a, my_lock b
 where a.lockwait = b.kaddr;

prompt "被等待的用户"
select a.sid, a.serial#, 
a.	machine,  a.last_call_et,a.username,
b.	 b.type,a.status,b.id1
  from my_session a, my_lock b
 where b.id1 in
      (select distinct e.id1
         from my_session d, my_lock e
        where d.lockwait = e.kaddr)
   and a.sid = b.sid
   and b.request=0;

prompt "查出其  sql "
select a.username, a.sid, a.serial#,
 b.id1, b.type, c.sql_text
  from my_session a, my_lock b, my_sqltext c
 where b.id1 in
       (select distinct e.id1
          from my_session d, my_lock e
         where d.lockwait = e.kaddr)
   and a.sid = b.sid
   and b.request=0
   and c.hash_value =a.sql_hash_value;
  

rem FSFI Value Compute 
rem fsfi.sql 
column FSFI format 999,99 
select tablespace_name,sqrt(max(blocks)/sum(blocks))* 
(100/sqrt(sqrt(count(blocks)))) FSFI 
from dba_free_space 
group by tablespace_name order by 1; 
spool fsfi.rep; 
/ 
spool off;

TABLESPACE_NAME FSFI 

------------------------------------- 

RBS 74.06 

SYSTEM 100.00 

TEMP 22.82 

TOOLS 75.79 

USERS 100.00 

USER_TOOLS 100.00 

YDCX_DATA 47.34 

YDCX_IDX 57.19 

YDJF_DATA 33.80 

YDJF_IDX 75.55

alter tablespace temp 

default storage(pctincrease 1);

exp user/password file=exp.dmp compress=Y grants=Y indexes=Y 

tables=(table1,table2);

Coalesce Tablespace Automatically 
This technique comes from Sandeep
 Naik, a database administrator 
for GSXXI, Inc. in New York City, New York 
Here is a handy script which can be 
scheduled to automatically run 
and coalesces the tablespaces. 
This script is designed to run in NT 
but can be run in any operating system 
by slight modifications in the path where the file spools 
from the SQLPLUS environment. 
It assumes that the user who runs the script 
has priviledges to view the data dictionary. 
Start of code 
-------------------------------------- 
sqlplus / 
prompt this script will coalesce the 
tablespace automatically 
set verify off; 
set termout off; 
set head off; 
spool c: empcoalesce.log 
select alter tablespace 
||TABLESPACE_NAME|| coalesce ; 
from DBA_FREE_SPACE_COALESCED where 
PERCENT_EXTENTS_COALESCED <100 
or PERCENT_BLOCKS_COALESCED<100 ; 
spool off; 
@ c: empcoalesce.log 
set head on; 
set termout on; 
set verify on; 
prompt Tablespaces are coalesced successfully