Oracle用户被锁原因及办法

在登陆时被告知test用户被锁

1、用dba角色的用户登陆,进行解锁,先设置具体时间格式,以便查看具体时间

[sql] alter session set nls_date_format=’yyyy-mm-dd hh24:mi:ss’;[/sql]

Session altered.


2、查看具体的被锁时间

[sql] select username,lock_date from dba_users where username=’TEST’;[/sql]

USERNAME LOCK_DATE

TEST 2009-03-10 08:51:03


3、解锁

[sql] alter user test account unlock;[/sql]

User altered.


4、查看是那个ip造成的test用户被锁

查看$ORACLE_HOME/network/admin/log/listener.log日志

10-MAR-2009 08:51:03 * (CONNECT_DATA=(SID=lhoms)(SERVER=DEDICATED)(CID=(PROGRAM=oracle)

(HOST=omstestdb)(USER=oraoms))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.69.1.11)(PORT=49434)) *

establish * lhoms * 0

10-MAR-2009 08:51:03 * (CONNECT_DATA=(SID=lhoms)(SERVER=DEDICATED)(CID=(PROGRAM=oracle)

(HOST=omstestdb)(USER=oraoms))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.69.1.11)(PORT=49435)) *

establish * lhoms * 0

这样可知是上面10.69.1.11的ip尝试多次失败登陆造成的被锁


注:

一般数据库默认是10次尝试失败后锁住用户

1、查看FAILED_LOGIN_ATTEMPTS的值

[sql]select * from dba_profiles[/sql]

2、修改为30次

[sql]alter profile default limit FAILED_LOGIN_ATTEMPTS 30;[/sql]

3、修改为无限次(为安全起见,不建议使用)

[sql]alter profile default limit FAILED_LOGIN_ATTEMPTS unlimited;[/sql]
<think>嗯,用户问的是数据库表的解决办法原因。这个问题我之前学过一些,但可能需要仔细回忆一下相关知识。首先,我需要明确什么是表,为什么会发生,然后才能想到解决办法。 数据库表,应该是指某个事务长时间占用表资源,导致其他操作被阻塞的情况。通常分为行和表,行定某一行,而表定整个表。如果发生表,可能很多操作都无法进行,比如查询、更新等,影响系统性能。 那表的原因可能有哪些呢?比如,事务处理时间过长,比如一个事务中有大量数据操作,没有及时提交或回滚,导致一直存在。或者,有未提交的事务,比如程序在执行业务逻辑时出现异常,没有正确关闭事务,导致未被释放。还有可能是死,不同事务互相等待对方释放,导致都无法继续执行。另外,数据库的隔离级别设置过高,比如使用可重复读(Repeatable Read)或序列化(Serializable),可能会增加的范围和时间,从而更容易出现表的情况。 解决办法的话,首先要找到导致表的原因。可以通过数据库提供的工具查看当前的状态,比如MySQL的SHOW ENGINE INNODB STATUS命令,或者查询information_schema库中的INNODB_TRX、INNIB_LOCKS等表。如果是长时间运行的事务,可以考虑优化事务,减少事务执行时间,或者拆分成小事务。对于未提交的事务,需要检查程序代码,确保事务及时提交或回滚,尤其是在异常处理中。如果是死,数据库通常会自动检测并回滚其中一个事务,但可能需要优化应用逻辑,调整事务的执行顺序,以减少死的可能性。调整隔离级别到较低的级别,比如读已提交(Read Committed),也可以减少的持有时间。另外,合理使用索引,避免全表扫描,因为全表扫描可能会导致升级为表。在必要时,可以手动杀死导致表的会话进程,但需要谨慎操作,避免影响其他正常操作。 可能需要提醒用户,不同的数据库系统(如MySQL、PostgreSQL、Oracle)在机制和解决方法上可能有所不同,具体操作需要参考对应数据库的文档。还有,预防表的发生比事后处理更重要,应该在设计和编码阶段就考虑事务的合理使用和优化。 不过,可能我有没有遗漏的地方?比如,是否还有其他原因,比如数据库设计不合理,比如缺少必要的索引,导致查询需要定整个表?或者某些特定的操作,比如ALTER TABLE会定表?这时候可能需要考虑在业务低峰期执行这类DDL操作。另外,使用行级的数据库(如InnoDB)通常比表级(如MyISAM)更少出现表问题,所以存储引擎的选择也可能影响表的频率。 总结下来,表的原因包括长事务、未提交事务、死、高隔离级别、全表扫描等。解决办法需要根据具体原因进行处理,包括优化事务、及时提交、调整隔离级别、使用索引、手动终止会话等。同时,预防措施也很重要,比如合理设计事务,使用合适的存储引擎,避免在高峰时期执行DDL等。</think>以下是数据库表问题的原因及解决方法,按优先级分步说明: === 原因 === 1. **长事务阻塞** - 未提交的事务长时间占用(如忘记提交/回滚) - 例:`BEGIN; UPDATE table SET ... WHERE ...;` 未执行COMMIT 2. **循环** - 事务A持有1请求2,事务B持有2请求1 - 数据库自动检测后会回滚其中一个事务 3. **升级机制** - 行数量超过阈值时自动升级为表(如SQL Server) 4. **DDL操作冲突** - ALTER TABLE等结构变更操作会获取元数据 - 与长时间运行的查询冲突时形成阻塞 5. **全表扫描加** - 未走索引的查询可能升级为表级(如MyISAM引擎) === 排查方法 === 1. **MySQL示例** ```sql -- 查看当前状态 SHOW ENGINE INNODB STATUS; -- 查询阻塞进程 SELECT * FROM information_schema.INNODB_TRX WHERE trx_state = 'LOCK WAIT'; ``` 2. **SQL Server示例** ```sql -- 查看阻塞链 SELECT session_id AS SPID, blocking_session_id AS BlkBy, command, wait_type, wait_time FROM sys.dm_exec_requests WHERE blocking_session_id > 0; ``` === 解决方案 === 1. **应急处理** ```sql -- 终止阻塞进程(谨慎操作) KILL [session_id]; ``` 2. **事务优化** - 将大事务拆分为小批量操作 ```sql -- 分页更新示例 WHILE EXISTS(SELECT 1 FROM table WHERE condition) BEGIN UPDATE TOP(1000) table SET column = value WHERE condition; COMMIT; END ``` 3. **索引优化** - 为WHERE条件列添加组合索引 - 避免`SELECT *`,减少覆盖范围 4. **隔离级别调整** ```sql -- 使用读已提交隔离级别 SET TRANSACTION ISOLATION LEVEL READ COMMITTED; ``` 5. **DDL操作规范** - 使用ONLINE DDL(MySQL 5.6+) ```sql ALTER TABLE table_name ADD COLUMN new_column INT, ALGORITHM=INPLACE, LOCK=NONE; ``` 6. **超时设置** ```sql -- 设置等待超时(单位:秒) SET innodb_lock_wait_timeout = 30; ``` === 预防措施 === 1. 事务代码模板强制包含异常处理: ```java try { conn.setAutoCommit(false); // 业务操作 conn.commit(); } catch (Exception e) { conn.rollback(); } finally { conn.close(); } ``` 2. 监控预警配置项: - 长事务阈值:执行时间 > 5s - 等待阈值:等待时间 > 3s 3. 架构层面: - 读写分离架构分流压力 - 热点数据采用Redis缓存 不同数据库处理差异对比: | 特性 | MySQL(InnoDB) | PostgreSQL | Oracle | |--------------|---------------------|--------------------|------------------| | 默认粒度 | 行级 | 行级 | 行级 | | 升级机制 | 无 | 无 | 有 | | 死检测 | 自动检测+回滚 | 自动检测+回滚 | 自动检测+回滚 | | 在线DDL | 支持(5.6+) | 部分支持 | 支持 | 建议开发规范: 1. UPDATE/DELETE语句必须带索引条件 2. 事务内操作行数不超过5000行 3. 批量操作使用LIMIT分批次提交 4. 避免业务高峰期执行统计查询
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值