公司这几天已经被本汪拆的没剩什么了
————额哈哈，本汪果然是拆家小能手
本汪想着今天闲着也是闲着
就把Oracle数据库一些隔壁加菲猫正用的数据表里的数据给删一删
捣捣乱
没想到删的时候才发现
好多表都被锁了
第一反应：难道是加菲提前做了防备？
结果本汪一抬头，就看见加菲急匆匆地向我跑来。。。。。。
原来是这只蠢猫不小心和其他人同时操作数据库表，结果把好多表给锁了
既然她自己已经把自己坑惨了，那本汪今天就”放过”她吧
于是本汪果断帮她把表给解锁了(还顺便删了她几条关键数据，嘿嘿),SQL如下：
select l.session_id sid,
s.serial#,
l.locked_mode,
l.oracle_username,
s.user#,
l.os_user_name,
s.machine,
s.terminal,
a.sql_text,
a.action
from v$sqlarea a, v$session s, v$locked_object l
where l.session_id = s.sid
and s.prev_sql_addr = a.address
order by sid, s.serial#;
这个会查到是什么原因引起的锁表，和锁表的类型，查询结果中，有三个字段是主要的，
本汪说一下:管他汪的什么原因导致的锁表，想解开就看查询结果中的三个字段“SID”,"SERIAL#","ORACLE_USERNAME"
“ORACLE_USERNAME”，用来判断是谁操作导致的锁表，本汪当时是直接找到了"ORACLE_USERNAME"下为“jiafei”的数据行·（“jiafei"为隔壁加菲的oracle数据库用户名），也就是说这条数据是加菲锁表的记录
然后执行解锁SQL:
alter system kill session '343,54767';
其中”343“为对应的”SID“数据
"54767"为对应的”SERIAL#“数据
本汪强调下：上面这条SQL如果写成”alter system kill session'343,54767';会报错”can not find session keyword“,原因是session和‘343，54767’之间少了空格哦
由于加菲这只蠢猫锁了多个表，所以查询结果中会有多条"ORACLE_USERNAME"为“jiafei”的数据，需要一一解锁，才能解决
本汪也想静静地装高冷，酷酷地装B,奈何本汪不是那个性格//
数据库乱码解决
select userenv('language') from dual;
把值设置成“AMERICAN_AMERICA.ZHS16GBK”
