仓酷云

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 932|回复: 8
打印 上一主题 下一主题

[学习教程] MYSQL网页编程之ORACLE 锁

[复制链接]
柔情似水 该用户已被删除
跳转到指定楼层
楼主
发表于 2015-1-16 22:41:30 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
使用它开发程序也是非常简单的。”oracle  ORACLE数据库是当今数据库范畴使用最普遍的,同时它也是一个复杂的体系,周全懂得它、玩转它不仅必要必定的实际常识,更必要开辟履历与工程履历。自己是ORACLE一喜好者,以下是自己对ORACLE锁的一些履历,但愿能与人人配合分享。

  ORACLE锁详细分为以下几类:

1.按用户与体系分别,能够分为主动锁与显现锁

  主动锁:当举行一项数据库操纵时,缺省情形下,体系主动为此数据库操纵取得一切有需要的锁。

  显现锁:某些情形下,必要用户显现的锁定命据库操纵要用到的数据,才干使数据库操纵实行得更好,显现锁是用户为数据库工具设定的。

2.按锁级别分别,可分为共享锁与排它锁

  共享锁:共享锁使一个事件对特定命据库资本举行共享会见——另外一事件也可对此资本举行会见或取得不异共享锁。共享锁为事件供应高并发性,但如低劣的事件计划+共享锁简单形成逝世锁或数据更新丧失。

  排它锁:事件设置排它锁后,该事件独自取得此资本,另外一事件不克不及在此事件提交之前取得不异工具的共享锁或排它锁。

3.按操纵分别,可分为DML锁、DDL锁

  +DML锁又能够分为,行锁、表锁、逝世锁

    -行锁:当事件实行数据库拔出、更新、删除操纵时,该事件主动取得操纵表中操纵行的排它锁。

    -表级锁:当事件取得行锁后,此事件也将主动取得该行的表锁(共享锁),以避免别的事件举行DDL语句影响纪录行的更新。事件也能够在举行过程当中取得共享锁或排它锁,只要当事件显现利用LOCKTABLE语句显现的界说一个排它锁时,事件才会取得表上的排它锁,也可以使用LOCKTABLE显现的界说一个表级的共享锁(LOCKTABLE详细用法请参考相干文档)。

    -逝世锁:当两个事件必要一组有抵触的锁,而不克不及将事件持续下往的话,就呈现逝世锁。
        如事件1在表A行纪录#3中有一排它锁,并守候事件2在表A中纪录#4中排它锁的开释,而事件2在表A纪录行#4中有一排它锁,并守候事件;1在表A中纪录#3中排它锁的开释,事件1与事件2相互守候,因而就形成了逝世锁。逝世锁通常为因低劣的事件计划而发生。逝世锁只能利用SQL下:altersystemkillsession"sid,serial#";大概利用相干操纵体系kill历程的命令,如UNIX下kill-9sid,大概利用别的工具杀失落逝世锁历程。

  +DDL锁又能够分为:排它DDL锁、共享DDL锁、剖析锁

    -排它DDL锁:创立、修正、删除一个数据库工具的DDL语句取得操纵工具的排它锁。如利用altertable语句时,为了保护数据的完成性、分歧性、正当性,该事件取得一排它DDL锁。

    -共享DDL锁:需在数据库工具之间创建互相依附干系的DDL语句一般需共享取得DDL锁。

如创立一个包,该包中的历程与函数援用了分歧的数据库表,当编译此包时,该事件就取得了援用表的共享DDL锁。

    -剖析锁:ORACLE利用共享池存储剖析与优化过的SQL语句及PL/SQL程序,使运转不异语句的使用速率更快。一个在共享池中缓存的工具取得它所援用数据库工具的剖析锁。剖析锁是一种共同的DDL锁范例,ORACLE利用它追踪共享池工具及它所援用数据库工具之间的依附干系。当一个事件修正或删除共享池持有剖析锁的数据库工具时,ORACLE使共享池中的工具取消,下次在援用这条SQL/PLSQL语句时,ORACLE从头剖析编译此语句。

4.外部闩锁

  外部闩锁:这是ORACLE中的一种特别锁,用于按次会见外部体系布局。当事件需向缓冲区写进信息时,为了利用此块内存地区,ORACLE起首必需获得这块内存地区的闩锁,才干向此块内存写进信息。

  以上是自己对ORACLE锁的一些总结,不敷的地方还看人人包涵,同时也但愿人人多提出本人对ORACLE锁的一些意见。
DBaaS解决方案既可以解决这些问题,又能为客户节约资金。相反作为解决方案提供商,采用DBaaS模式似乎就并不那么有吸引力了,因为与企业内部署软件的解决方案相比,DBaaS意味着更低的利润。
再见西城 该用户已被删除
沙发
发表于 2015-1-19 21:16:15 | 只看该作者
一个百万级别的基本信息表A,一个百万级别的详细记录表B,A中有个身份证id,B中也有身份id;先要找出A中在B的详细记录。
活着的死人 该用户已被删除
板凳
发表于 2015-1-28 11:03:03 | 只看该作者
所以你总能得到相应的升级版本,来满足你的需求。
只想知道 该用户已被删除
地板
发表于 2015-2-5 21:03:45 | 只看该作者
可能有的朋友会抱怨集成的orderby,其实如果使用ranking函数,Orderby是少不了的。如果担心Orderby会影响效率,可以为orderby的字段建立聚集索引,查询计划会忽略orderby操作(因为本来就是排序的嘛)。
爱飞 该用户已被删除
5#
发表于 2015-2-13 15:11:45 | 只看该作者
总感觉自己还是不会SQL
若天明 该用户已被删除
6#
发表于 2015-3-3 23:15:09 | 只看该作者
这是一个不错的新特性。虽然索引的附加字段没有索引键值效率高,但是相对映射到数据表中效率还是提高了很多。我做过试验,在我的实验环境中会比映射到表中提高30%左右的效率。
第二个灵魂 该用户已被删除
7#
发表于 2015-3-11 14:32:54 | 只看该作者
至于淘汰的问题,只能说在你的项目周期之内,微软应该都不会倒闭。
飘灵儿 该用户已被删除
8#
发表于 2015-3-18 23:43:50 | 只看该作者
另一个是把SQL语句写到服务器端,就是所谓的SP(存储过程);
愤怒的大鸟 该用户已被删除
9#
发表于 2015-3-26 21:06:29 | 只看该作者
对递归类的树遍历很有帮助。个人感觉这个真是太棒了!阅读清晰,非常有时代感。
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|Archiver|手机版|仓酷云 鄂ICP备14007578号-2

GMT+8, 2024-4-29 17:39

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表