ITPUB论坛-中国最专业的IT技术社区

 找回密码
 注册
查看: 252|回复: 8

revoke和grant会锁表吗,有这方面的资料吗

[复制链接]
认证徽章
论坛徽章:
37
秀才
日期:2016-01-12 11:23:27秀才
日期:2016-01-13 12:14:26白羊座
日期:2016-02-01 14:49:24秀才
日期:2016-01-21 13:37:04秀才
日期:2016-01-25 15:02:04狮子座
日期:2016-03-22 09:45:47摩羯座
日期:2016-05-16 10:09:40弗兰奇
日期:2017-01-11 14:37:00奥运会纪念徽章:网球
日期:2016-09-26 15:05:12ITPUB15周年纪念
日期:2016-10-13 13:15:34
发表于 2018-2-13 10:13 | 显示全部楼层 |阅读模式
如题
revoke和grant有锁表操作吗,哪位大神可以提供下官方资料链接吗
认证徽章
论坛徽章:
8
2009新春纪念徽章
日期:2009-01-04 14:52:28祖国60周年纪念徽章
日期:2009-10-09 08:28:002010新春纪念徽章
日期:2010-03-01 11:07:24ITPUB9周年纪念徽章
日期:2010-10-08 09:32:25ITPUB十周年纪念徽章
日期:2011-11-01 16:23:262013年新春福章
日期:2013-02-25 14:51:24沸羊羊
日期:2015-03-04 14:51:522015年新春福章
日期:2015-03-06 11:57:31
发表于 2018-2-13 11:59 来自手机 | 显示全部楼层
这种操作过程中,肯定存在闩锁类的,只是比较快而已。

使用道具 举报

回复
论坛徽章:
119
现任管理团队成员
日期:2011-05-07 01:45:08弗兰奇
日期:2018-01-31 17:04:24ITPUB15周年纪念
日期:2018-02-08 11:01:54
发表于 2018-2-13 14:21 | 显示全部楼层
sqysl 发表于 2018-2-13 11:59
这种操作过程中,肯定存在闩锁类的,只是比较快而已。

不好说算不算latch。

简单的说revoke,grant操作的对象有两个一个是object一个是user
object的定义在library cache中,user的定义在dc 也就是row cache中
所以revoke,grant一般应该涉及到 library cache lock/pin,row cache lock,老版本中这些似乎不是latch,新版本中应该已经用mutex取代。~


lz如果你想看具体内容去查 官方文档 library cache和row cache相关内容

使用道具 举报

回复
认证徽章
论坛徽章:
8
2009新春纪念徽章
日期:2009-01-04 14:52:28祖国60周年纪念徽章
日期:2009-10-09 08:28:002010新春纪念徽章
日期:2010-03-01 11:07:24ITPUB9周年纪念徽章
日期:2010-10-08 09:32:25ITPUB十周年纪念徽章
日期:2011-11-01 16:23:262013年新春福章
日期:2013-02-25 14:51:24沸羊羊
日期:2015-03-04 14:51:522015年新春福章
日期:2015-03-06 11:57:31
发表于 2018-2-13 21:47 | 显示全部楼层
本帖最后由 sqysl 于 2018-2-13 21:49 编辑
zergduan 发表于 2018-2-13 14:21
不好说算不算latch。

简单的说revoke,grant操作的对象有两个一个是object一个是user
也说下个人的理解:
1、grant和revoke应该仅涉及到授权相关的元数据,当然,也会涉及相关objects、users及roles等权限相关信息的刷新,因此,修改权限相关元数据时,应该会对其相关结构和数据进行加latch乃至加lock(因为是对元数据的操作,这点我不太确定)的操作,而这些元数据应该是在字典缓冲(dictionary cache)中;
2、pin,理解为一种lock机制更合适些,除了具备lock功能外,还可以防止数据被从内存中移除,这也是pin的主要含义;
3、latc机制在任何关系库中,都是无处不在的,而mutex,只是更轻量级的类似latch的机制,同时,其模式兼容性更好些,效率也更高而已;
4、涉及lock的操作过程前后,应该都会涉及latch机制的存在,因为,关系库并行化背后最根本、最本质的东西还是串行化;
5、Oracle最新版本中的latch是否完全被mutex替代,这点我不清楚,也不确定,我的理解是部分被替代吧。
仅供各位参考和讨论。

使用道具 举报

回复
论坛徽章:
119
现任管理团队成员
日期:2011-05-07 01:45:08弗兰奇
日期:2018-01-31 17:04:24ITPUB15周年纪念
日期:2018-02-08 11:01:54
发表于 2018-2-14 01:09 | 显示全部楼层
本帖最后由 zergduan 于 2018-2-14 01:41 编辑
sqysl 发表于 2018-2-13 21:47
也说下个人的理解:
1、grant和revoke应该仅涉及到授权相关的元数据,当然,也会涉及相关objects、users及 ...

。。。。。。
不是很准确,我详细解释一下我3#的说法

1. revoke,grant 的语法 : revoke / grant  <privilege> on <object> to <user>.
所以这里涉及到 object 和user,其实privilege也应该视为一种object;所谓的object,就是具有某种定义的结构,这个定义保存在library cache中;所谓的user其实就是dc_users这个数据字典内容,保存在row cache中。
2. 我们知道library cache和row cache都是shared pool中的一部分。shared pool是内存,内存中的结构由latch,lock ,mutex保护;注意,这里说的lock不是传统的TX / TM lock,这里说的lock是kernel general Library的 kgl lock(你可以从dba_kgllock查看); latch ,kgl lock , mutex都可以是用来保护内存结构的,但是粒度不一样,调用的CPU指令集不一样,按照顺序粒度越来越小,越小的粒度代表越轻量,越不容易导致冲突。但是粒度越小以为着数量越多,越占用资源,所以CPU‘指令集决定了是否可以小粒度,有兴趣大家可以查查对应的指令集,我记得好像mutex是test and set要比latch消耗资源更少,同时mutex和kgllock粒度差不多,到那时mutex占用的内存空间要小很多,所以mutex比latch和kglock要根据有优势。

3. 就像我说的,revoke/grant涉及到 row cache lock 和 library cache pin/lock ,这两种都应该是kgl lock。在11g中library cache pin/lock我确认已经被library mutex取代,12c中row cache lock是否被mutex取代我不知道,我没有具体看文档,但是按照发展趋势,latch和kgllock应该会被mutex取代的。

综上,所以我在3#说是lock(kgllock)不是latch。

latch其实已经是很落后的一种机制了。。。

使用道具 举报

回复
论坛徽章:
119
现任管理团队成员
日期:2011-05-07 01:45:08弗兰奇
日期:2018-01-31 17:04:24ITPUB15周年纪念
日期:2018-02-08 11:01:54
发表于 2018-2-14 01:24 | 显示全部楼层
本帖最后由 zergduan 于 2018-2-14 01:46 编辑
sqysl 发表于 2018-2-13 21:47
也说下个人的理解:
1、grant和revoke应该仅涉及到授权相关的元数据,当然,也会涉及相关objects、users及 ...

2、pin,理解为一种lock机制更合适些,除了具备lock功能外,还可以防止数据被从内存中移除,这也是pin的主要含义;
其实pin在很久以前也是通过latch实现的,只不过现在不是通过latch而已

4、涉及lock的操作过程前后,应该都会涉及latch机制的存在,因为,关系库并行化背后最根本、最本质的东西还是串行化;
我明白你想说的library cache lock之前会先持有library cache latch,但是这里我们说的是object,library cache latch是保护bucket的,library cache lock/pin才是保护object handle的,我要更准确的表达的意思是,在很久以前的老版本中操作内存需要一系列的latch 操作,这些latch的主要就作用就是串行和pin住内存结构,但是是因为latch的粒度太粗了,一个latch保护好多bucket,所以很容易就产生了征用,所以才会出现kgllock这种lock,来取代了一部分latch,越少的latch使用,争用冲突越小。简单的说,当你去操作某个object的时候,需要先获得library cache latch,但是这个latch保护的并不仅仅是你要操作的object,会牵扯到一大堆无辜的对象,所以必须马上释放掉latch(否则无辜的object就无法被操作了),取代的方式就是仅仅pin/lock你需要保护的object。所以这时候kgl lock就起作用了,他可以单独保护一个object,一旦获取kgl lock,就会马上释放library cache latch;新版本中,使用跟轻量的mutex实现,本身mutex占用内存更小,意味着消耗资源个更少。

使用道具 举报

回复
认证徽章
论坛徽章:
8
2009新春纪念徽章
日期:2009-01-04 14:52:28祖国60周年纪念徽章
日期:2009-10-09 08:28:002010新春纪念徽章
日期:2010-03-01 11:07:24ITPUB9周年纪念徽章
日期:2010-10-08 09:32:25ITPUB十周年纪念徽章
日期:2011-11-01 16:23:262013年新春福章
日期:2013-02-25 14:51:24沸羊羊
日期:2015-03-04 14:51:522015年新春福章
日期:2015-03-06 11:57:31
发表于 2018-2-14 13:12 | 显示全部楼层
zergduan 发表于 2018-2-14 01:09
。。。。。。
不是很准确,我详细解释一下我3#的说法

嗯,谢谢一直以来及时认真的回复。
也许我们的理解会稍有差异,但最重要的是,通过讨论能得以启发,希望未来能和论坛里的朋友继续更多的探讨。
祝zergduan版主和论坛所有的朋友新年快乐,阖家幸福,万事如意!

使用道具 举报

回复
论坛徽章:
119
现任管理团队成员
日期:2011-05-07 01:45:08弗兰奇
日期:2018-01-31 17:04:24ITPUB15周年纪念
日期:2018-02-08 11:01:54
发表于 2018-2-14 13:18 | 显示全部楼层
sqysl 发表于 2018-2-14 13:12
嗯,谢谢一直以来及时认真的回复。
也许我们的理解会稍有差异,但最重要的是,通过讨论能得以启发,希望 ...

谢谢,与你的到讨论也让我受益匪浅,祝你新年快乐:)

使用道具 举报

回复
论坛徽章:
183
红宝石
日期:2014-05-09 08:24:37萤石
日期:2014-01-03 10:25:39金牛座
日期:2015-10-09 17:32:03马上有钱
日期:2014-10-27 09:26:57马上有房
日期:2014-11-07 08:46:05马上有钱
日期:2014-11-12 09:33:24马上有钱
日期:2014-11-24 15:17:08马上有对象
日期:2015-01-14 17:33:15沸羊羊
日期:2015-02-11 09:07:41懒羊羊
日期:2015-03-04 09:03:43
发表于 2018-2-16 22:52 | 显示全部楼层
应该涉及到 library cache lock/pin,row cache lock,

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则

TOP技术积分榜 社区积分榜 徽章 电子杂志 团队 统计 虎吧 老博客 知识索引树 读书频道 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档 | IT博客
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛 | SAP ERP系统
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 网站律师 隐私政策 知识产权声明
京ICP备16024965号 北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表