对话Block.One CEO:DPOS是扩展区块链的唯一方法

2月4日,EOS发布了测试版网络“EOS STAT”。它模拟了计划在明年发布的EOS.IO软件,具有21个区块生产节点,一秒出块时间,一个稳定的开发者API,设置用的钱包,以及使用该API的账号系统,合约安全与验证。EOS在开发上的快速进展再次吸引了社区注目。

就在刚刚结束的新加坡BlockShow大会上,巴比特有幸对Block.One的CEO Brendan Blumer和合伙人Brock Pierce进行了访问。在此之前,社区内关于Block.One的CTO,社区人称BM(bytemaster)的Dan Larimer的轶事小传已经够多了,不过说起其他团队成员的故事,他们的传奇性一点都不亚于Dan Larimer。

今年31岁的Brendan可谓是名副其实的青年才俊,他在15岁时就开始了第一次创业。当时的Brendan专门出售角色扮演游戏MMORPG中的虚拟资产,随后,他所创建的GaMeCLiFF被网络游戏娱乐有限公司,Internet Gaming Entertainment(现为IMI Exchange)收购。

微信截图_20171206104440Brendan Blumer

没错,就是被Block.One的一位合伙人,Brock Pierce的公司所收购,那时的Brendan只有18岁。中学毕业后,IGE在2005年派他到香港发展,期间,Brendan极大的推动了IGE业务增长,其营业部使公司年利润五百万美元。两年后,Brendan创立了Accounts.net,是全球最大的游戏账户买卖平台。后来的几年,Brendan成立了香港房地产企业软件公司Okay.com和科技发展平台ii5。

Brendan在2016年成为区块链的早期投资者,结识了Daniel Larimer并开始转型为全职投资。Brendan告诉巴比特,

“我成为了区块链的信仰者,并且相信区块链的影响力比互联网更大。但应该有更具有拓展性的解决方案,我们才能落地去中心化的商业,在这个领域中,我认为一个人最有可能做成这件事情,就是Daniel Larimer。”

相较于Brendan,Brock Pierce可能更被区块链和加密数字货币社区用户所熟知。2014年,Brock当选为比特币基金会董事会主席。Brock创立的Blockchain Capital已经投资了30多家区块链公司,他所创立或者担任顾问、董事会成员的项目包括GoCoin,Tether,ZenBox,Blade Financial,Expresscoin,Noble Markets,BitGo,ChangeTip,BlockStreet,Coin Congress

微信截图_20171206104556Brock Pierce

Brock向巴比特回忆起他的创业经历,最早要追溯到1999年。与Brendan一样,Brock也是从游戏行业起家,从起初进行游戏币的交易,到创建游戏媒体公司ZAM,并在2012年1月被腾讯收购。

Pierce涉猎的领域还包括媒体和挖矿。哦对了,传奇人物们总是多才多艺,Brock还曾是个演员……

除了创业领域都集中在游戏和加密数字货币,Brendan和Brock 还有一个共同点——与中国社区颇有渊源。Brendan从18岁起来到香港,到现在已经待了13年,其创建公司的服务对象大多为亚洲客户,Pierce也在2002年开始就活跃在香港和上海,并资助了游戏玩家Sky成为首位获得WCG大赛冠军的华人。

在这次访问中,Brendan Blumer和Brock Pierce跟巴比特聊了聊他们是如何成立Block.One,为什么发起EOS,对中国社区的看法,以及未来的发展计划。以下为部分访谈内容,巴比特做了不改变愿意的编辑呈现。

 

区块链3.0 : EOS是最棒的DPOS项目

 

当谈到为什么发起EOS,Brendan特别强调了去中心化社区中交易性能的重要性:

“我发现了Dan在构建可延展性网络方面的能力。除比特币之外只有两个项目是真正的去中心化自治社区,那就是比特股和steemit。如果你想在以太坊上运行steemit是不可能的。steemit每秒能处理的交易比所有以太坊项目加起来都要多,它是世界上规模最大的区块链。整个以太坊网络都无法支撑steemit,其在以太坊系统中的运作需要耗费每年1.5亿美元的资金。这项技术十分先进,能让我们创建区块链版的facebook、优步、airbnb、阿里巴巴等。这是我们通过这项技术能够实现的,目前没有任何能够替代steemit的技术存在。因此我开始和Dan讨论采用这项技术,让所有开发者都能用这项技术进行开发,这就是EOS存在的意义。与所有以太坊项目相比,Steemit在交易处理能力上排名第一,这就是真实数据(blocktivity.info),这是大多数人都没有意识到的。”

微信图片_20171205191139

Brendan给我们展示了在blocktivity.info网站上,交易笔数最多的是steemit。

“这就是我们开始使用这项技术的原因。以太坊承诺实现的应用有很多,但他们的技术无法实现这些目标。EOS就能实现区块链的目标,那就是构建大型可扩展的去中心化社区。”

Brock则从区块链的进化角度进行了分析,在他看来,比特币和以太坊分别是第一代、第二代区块链的代表,而EOS则是第三代区块链中最有意思的一个:

“我是比特币基金会的主席。如今的比特币是一种保值品,就像数字黄金一样,它不适合被用于当前的很多应用场景。很显然,对于扩容,社区做过的努力有很多,试图通过Bitcoin Cash、Bitcoin Gold为比特币做出改变,其中发生了很多有意思的事情。但这不是POW系统能够做到的。

以太坊的功能更加丰富,但它仍然是POW系统,它能做的仍然有限。以太坊目前的最佳应用就是作为ICO的基础平台,一个用于取代风投的平台。我是Blockchain Capital的创始人,我今年做了第一个证券类ICO。这是以太坊目前所擅长的。很显然,和比特币一样,以太坊也有计划、有愿景、有野心、也有抱负,希望未来能做更多。以太坊计划通过sharding从PoW切换到PoS。

EOS是第三代区块链中的其中之一,采用的是DPOS。Dan就是DPOS的发明者。因此,他是最有经验的开发者,同时也是这种扩容方式的发明者。

作为这类区块链的创造者,我可以说EOS是最棒的DPOS项目。未来能够成功的区块链项目不止一个,会出现各种不同的区块链,因为它们存在的初衷就是实现不同的目标。质量好、速度快、成本低是一个经典的不可能三角——即三者之间只能实现两个。区块链有去中心化、速度、安全,最终也只能实现其中的两种功能。EOS每秒(将)能够处理100万笔交易,并且不需要手续费。用steemit不需要代币。如果你想要制造消费品,就必须有一个系统,一个不需要代币就能运行的系统。如果需要用代币(coins),说明你创造了摩擦(friction)。新用户在使用系统时通常会产生大量摩擦。EOS不需要这一点。要实现所有消费者应用的扩展性,让它们变得更有趣,就必须是按照这种模式设计的(无需代币)。

我认为EOS是第三代区块链中最有意思的一个。我支持这一领域中100多家公司推出的区块链。在我看来,只要有一个系统能够改变世界并使其变得更加美好,那么这对每个人来说都是最好的结果。就我个人来说,我不介意赢家是谁,我喜欢所有区块链项目,我喜欢业内所有人,只要他们是出于善意在开发区块链项目。EOS的logo是一个神秘的几何学心形符号,这就代表了我们的目的,代表了这个区块链项目的目标。这个logo的符号说明了很多事。”

 

中国社区对EOS至关重要

 

Brendan Blumer主动谈起了对中国社区的看法,他认为中国社区对EOS的发展至关重要:

“EOS的主动权由代币持有者掌握,并不是矿工掌握。而中国是最大的社区,在一定程度上甚至可以说EOS也是中国人的。因此在中国社区有持续曝光是很重要的,并且让我们能够持续听到中国社区的声音,我们可以据此做决定,建立我们的软件,从而实现社区利益最大化。”

对于当前中国较为严峻的监管环境,Brendan显得相对乐观,“监管有很大的不确定性。但政府之后可能会出台很清晰的监管,大的环境会好转。”

 

代币销售:资金筹集和社区创建

 

近期,社区有不少关于Block.one设立了十亿美元基金扶持EOS的声音,针对诸如此类的消息,Brendan首先进行了澄清:

“我们还什么都没有建立,有很多谣言,但我们准备发出公告,会是以另外一种形式,不是以基金的形式。我们与全球顶级的VC合作,确保资金可以分配给开发者。”

EOS开创了一种筹集资金的新模式,维持一年的代币销售也引来了巨大争议,对此,Brendan发表了他的看法,

“如果你可以从Daily ICO的视角去看,我看待ICO的方式是使用未来的资源创造了新的代币,这说明了比特币,以太坊都有Daily ICO。比特币是每天1800万美元,ETH是每天800万美元。

这些都会消耗电量,每秒交易数量少于10笔,每笔比特币交易我们需要支付的费用超过400人民币。因为这是保证网络正常运行所要付出的成本。到了2020年,如果比特币的发展继续下去,它将耗尽全球电力。只需要两年,比特币的发展就能耗尽全球所有电力,我们正处于危急时刻,这些系统已经无法维持自身发展。随着价格的上涨,同样的性能所要花费的成本更高。这从经济上来说是灾难,我们无法维持这一状态。

EOS通过block.one获得资金,而block.one将进行投资。是的,我们计划为EOS上的项目带来数十亿美元的资金,但这是通过基金会实现的,因为基金会是中心化的。我们真正关注的是投资,通过该领域最优秀的VC和市场领导者,给予他们部分资金,这样他们才能为项目做贡献,他们位于全世界。因此我们正在和全球各地的伙伴合作。我们正在准备宣布资金的具体用途,但目前并未发表正式的声明。目前有很多谣言和报道,但都不是准确的。我们会在12月正式公开这个消息。”

除了资金筹集,Brock从社区的角度对ICO进行了解读,

“全球第一个ICO项目是mastercoin,我是董事会成员之一,所以我们创建了第一个ICO,并在2013年6月进行了第一个ICO。相较于把ICO看作是首次代币发行,我更愿意把它变成最初社区创建(initial community offering)。这一切都是关于社区的创建。”

DPoS是扩展区块链的唯一方法

 

在访谈过程中,Brendan多次强调,代币持有者有权决定矿工身份,完全符合去中心化和平等的精神。对DPOS和EOS如此有信心,在他看来,EOS就是未来区块链的形态吗?Brendan激动的回答,“在我看来,100%是!”

“我认为DPOS是扩展区块链的唯一方法。像量子计算等一些其他事物都还需要进行研究。目前我们尚未发现任何(成功的)POS共识机制。PoW无法实现扩容,就像我说过的那样。到了2020年,全球所有的电力都会因比特币被消耗殆尽,ETH和其它币种甚至还没算进来。你不能在一个需要耗费数百美元的POW区块链上加时间戳或添加内容,因为从经济角度来看,这是毫无意义的。我们认为唯一的解决方式就是DPOS,我们在这方面的研究已经持续了很多年,它是很有意义的。代币持有者有权决定矿工身份,这完全符合去中心化和平等的精神。因为只要新的矿工出现,而且他真的在生产区块,那他们(代币持有者)就可以迅速进行切换。与此同时,你还能控制成本,因为矿工数量有限,并不会不合比例地增长。还存在一种高效能节点,他们通过电缆连接大型集群计算网络,这就意味着高效能。如果只是小规模的电脑和手机挖矿POW算法根本行不通。我的答案是肯定的,除非我们发明了一些现如今并不存在的东西,否则DPOS是实现扩容的唯一方法,我们会继续证明这一点。我们认为EOS将持续在主流层面证明自己,将允许开发者搭建任何他们想要的应用。DPOS唯一的缺陷就在于,其与普通意义上的区块链不同,无法允许所有人搭建自己想要搭建的技术。但这一点在EOS上已经有所改变。”

当被问及EOS进程中是否遇到什么问题,Brendan显得十分有信心,

“事实就是,目前我们并未遇到什么大问题。我们发行“并行性”(parallelism)是很难实现的,但我们正在研究解决方案,这不会成为项目面世的问题。虽然这很难,但我们很有信心,BM是唯一一个能够解决这个问题的人。要想解决这一问题,你需要有多年区块链开发经验。事实上,BM曾提到,能达到这个程度的人之前必须开发过至少3个区块链系统。很少有人能像我们的CTO一样在区块链开发方面经验丰富。因此,任何尝试构建区块链的新人,需要不断在开发、学习和再开发之间过渡。因此,我认为没有什么问题能够阻止我们实现我们的目标。但我的确认为,EOS尝试实现的目标是目前世界上最难实现的事情,这一过程非常耗费时间,所以优秀人才的加入是很重要的,我们目前也正在招募专业人才。”

发文时比特币价格 ¥80324.98
文:萌大大
稿源:巴比特资讯( http://www.8btc.com/block-one-dpos)

EOS.IO发布黎明破晓Dawn2.0版本 & 开发更新

原文:https://steemit.com/eos/@eosio/eos-io-dawn-2-0-released-and-development-update

随着公共测试网络的发布,EOS.IO黎明2.0也已经发布。此次发布的版本提供了我们在2017年秋天的路线图中描述的多数功能的alpha实现,当初路线图的目标是在2017年12月21日完成的。在我们的路线图中,“阶段2–最小可行测试网络”会在2017年秋天前完成如下功能:

  • p2p网络代码
  • Wasm Sanitation与cpu沙盒
  • 资源使用追踪/比率限制
  • 源输入测试
  • 区块链间通信

此时,我们已完成了多数这些功能的初始实现;然而,由于我们是并行开发,区块链间通信的实现是在独立的分支中进行,所以,此次的初始测试网络不包含此功能。

对EOS.IO黎明2.0的性能测试感兴趣的人,可以在我们的github代码仓库里找到所有必须的代码,来运行一个私有的网络。我们内部测试显示,在平均硬件条件下,使用我们的单线程实现,可以维持每秒数千笔交易以及1秒出块时间。他们说,对一些已知的攻击我们还没有解决方案。比如,首次编译新的合约可能需要34毫秒,如果被滥用的话可能会导致网络破裂,使得性能只有30tps。

对于这个问题,我们的方案是限制合约代码可以更新的频率,也就是在代码更新和合约使用新代码之间设置一个时间延迟。大约会有60秒的时间延迟,让所有的区块生产者安排时间从web assembly对x86指令进行编译/缓存。

由于存在这些攻击行为,性能测试将只能在私有测试网络中进行,而功能测试现在可以在公共测试网络中进行了,我们会把性能限制在30tps,以保证运行时间和访问。

接下来的六个月,我们会持续地进行测试和debug,以提高稳定性和性能。

黎明1.0中的新功能

源输入测试

我们实现了一个快照工具,它能输入初始的基于在以太坊网络上分发的EOS ERC-20代币的状态。我们的测试网络将只包括那些注册了有效EOS公钥的账号。目前大约有20%的ERC-20代币已经注册了EOS公钥。我们的快照工具还实现了一个回退工具,对于那些没有注册的ERC-20代币,我们可以从以太坊交易中恢复公钥。这功能覆盖了99%的EOS ERC-20代币,不过将需要输入你的以太坊私钥到你的EOS.IO钱包里去。

处于安全考虑,我们的测试网络将不会要求用户输入他们通过回退过程恢复的以太坊私钥。如果在测试的过程中,你的EOS私钥不安全,你可以在以太坊网络上注册一个新私钥。

代币水龙头

我们还实现了一个“水龙头”功能,能让那些没有代币的人或还没有注册有效EOS公钥的人也能对网络进行测试。

资源使用与比率限制

我们实现了基本的比率限制和资源使用追踪功能。这能追踪带宽,数据库存储,和计算的使用情况。目前,我们的比率限制算法海有些bug,但是,这不影响测试和应用的开发。

我们知道,很多人一直在问关于比率限制是怎么运作的问题,由谁来付费,他们怎么样出租他们的代币来获得收入等等。

带宽

所有的交易都会消耗网络带宽。交易需要的所有账号将会根据交易的大小,平均多拥有3天的带宽。只有拥有代币或由应用提供者代理代币的授权账户(不是合约)才能拥有带宽。

计算带宽

所有的交易都会消耗计算资源。计算可以并行执行,所以它能被视为多道高速公路,每条车道的路况都不相同。每个scope(车道)都拥有独立的比率限制,一个用户将会根据并发scope(车道)请求的数量的O(S^2)来计费,并且基于最拥堵的scope进行比率限制。

数据库存储

EOS.IO合约能访问内存数据库,该数据库可以保存应用状态。该合约根据他们存储的总数据进行计费,再加上对每个独立数据库入口的一个固定的管理费用。这个内存数据库是独立的,与EOS.IO Storage协议–用于去中心化托管与存储—分离的。

p2p网络代码

对于网状网络代码我们有了一个基本的实现,这 在我们的公共测试网络中有所展示。Block.one运行了21台独立的服务器,每台服务器都由初始生产者中的一个进行配置。

EOS黎明3.0

EOS黎明3.0将会通过安全的区块链间通信重新定义单链的水平拓展和无限拓展。有了这两个特性,在区块链上进行开发将不再有限制,如何把区块链网络去中心化也不会再有限制。

无限拓展与无限去中心化

区块链技术的最高目标就是能确保两个独立区块链之间的通信是安全的,而不需要两条区块链都去验证另一条区块链上的所有信息。这个要求就需要把一条区块链变成另一条区块链的轻客户端。

轻客户端只使用区块头和默克尔证明来验证交易。EOS.IO将是第一个支持轻客户端验证的pos协议。更重要的是,它将是唯一一个生成完整性证明(proof-of-completeness)的协议。这意味着,它将可能证明你收到了从其他链发来的所有相关信息,而不需要等待。

传统的轻客户端需要处理所有的区块头,而EOS.IO将让轻客户端只需要在生产者改变,或者当一个更新的区块需要一条新消息的时候,才去处理区块头。这将能让链之间能实现高效的频繁通信。在最坏的情况下,两条区块链间每500毫秒的通信成本将只比所有发送信息的数量多2tps。

在这种模式下,只要至少1/3的区块生产者是诚实的,通信就是安全的。而且,即使有一个生产者不诚实,如果他们签署了任何可能腐化轻客户端(外部区块链)的信息的话,他们就会自动地受到惩罚。

最后,与另外的区块链进行通信的往返时间,取决于延迟,直到每条链都是不可逆的。一条基于EOS.IO的链将能把消息发送给一条外部EOS.IO链,然后能在3秒内获得经过加密验证的回复。

这个级别的区块链间通信和安全性,能创建低延迟的链之间的双向锚定。除了双向锚定这个最显而易见的例子之外,任何b2b的通信都能使用这种方法来执行。

公共/私密通信

通过链间通信,就有可能让私有区块链能与共有区块链进行安全的双向通信。这适用于所有那些不适合公有的传统区块链的区块链应用。比如,人们可能创建区块链的瑞士银行,它对每个人都是顶级机密,除了该银行的拥有者。

开发过程

为了发布我们的公共测试网络,我们把我们的开发分成了两个并行的分支,这样我们就能对重要的部分进行 重构,让它更易读,性能更高,同时实现区块链间通信。这个重构的工作在eos-noon分支中进行。

在过去的更新中,我们提到我们专注于共享存储架构,这样开发者就能轻松地与其他合约执行同步读访问与原子事务。这么做就让单台后端机器丧失了水平拓展性。

在EOS 黎明3.0中,我们通过使用高达65000个不同的region,来恢复多机水平拓展能力。所有的region拥有相同的账户和合约代码,但是在内存数据库中是独立的。一个region中的合约必须使用一步事务与他们在其他region中的对应方进行通信。使用这种架构,单个区块生产者就能作为簇来实现。

集成苹果的安全硬件

在我们的上次更新中我们宣布了我们将支持苹果,安卓和很多智能卡都使用的椭圆曲线。我们的eos-noon分支现在包含了一个完整功能的概念证明,在这个证明中,消息都经过最新版的MacBook Pro的Touch ID(以及Face ID)的签署和验证。相似的代码也会用在iphone原声应用上。这意味着,基于EOS.IO的移动应用将跻身于已知的最安全的区块链钱包之列。

而且,eos-noon分支现在已经集成了对多签名类型的支持,也就意味着,可以使用安全硬件来对将会在eos-noon上进行 验证的交易进行签名。

500毫秒区块验证

在我们的eos-noon分支,我们已经实现了对底层dpos框架的多个改进,以支持500毫秒区块验证(每秒2个区块)。这个改进将提高去中心化应用的反应能力。为了做到这一点,我们对区块如何调度进行了修改。

相同的生产者现在能接连生产12个区块,然后交给下个生产者。这解决了区块生产的最大瓶颈,也就是生产者到生产者切换的问题。在这个新的结构中,每次切换的时候,不可预期的延迟可能会导致少数丢块,但是,在切换之间,就能快速确认。我们将会进行不同的切换期实验。切换期越长,正常操作的丢块就越少,但是如果单个节点宕机的话,宕机的时间就越长。有了500毫秒确认以及每12区块切换的性能,“宕机时间”不会比steem和比特股上的单个生产者丢失一个块的情况更差。在这种情况下,需要6秒的时间来做首次确认。

移除备选生产者

区块链间通信要求轻客户端对所有活跃生产者集合发生变化的区块进行追踪。“备选生产者列表”导致一个新的生产者每分钟都会被加上或删除,这就强制轻客户端每秒至少处理一个区块头,如果不是更多的话。为了减少生产者集合变化的频率,我们改变了区块的调度,改为只包含前21位生产者。我们考虑给予备选生产者某些补偿,但是他们将不会再生产区块。

一秒不可逆性

每个区块生产者会签署每个区块,一旦2/3的生产者签署了它,它就是不可逆的了。每个区块高度,生产者只能签署一个区块头。这意味着如果产生了分叉,生产者不能在两个分叉中的相同高度上签署区块。这种签名会被认为是不当行为,做出这种行为的生产者会受到惩罚,比如自动丢失生产者地位,潜在的奖励损失,以及在仲裁中承担损失责任。

与其他协议不同,他们要求在生产下个区块前能得到超过2/3的签名,EOS DPOS允许区块链在征集签名的时候同时推进“挂起状态“。这些附加的签名在区块链之外进行,并且能在一个区块是不可逆的之后删除。

在这种模式下,就可能实现拜占庭容错,因为没有拜占庭节点的加密学证据,任何区块都不可能达到超过2/3的签名。

移除生产者调度洗牌(shuffling)

为了把生产者切换之间的丢块数量减到最小,就需要把连续生产者时间的延迟最小化。如果一个在纽约的生产者被安排在一个在中国的生产者之后,正常情况下它就需要250毫秒去接受区块(50%的区块间隔),如果网络拥堵的话时间可能更长。另一方面,纽约和德州的生产者只有50毫秒的延迟(10%的区块间隔)。这意味着在从纽约到德州之间的切换比从纽约到中国的切换的丢块可能性要低得多。

如果我们如此安排区块生产,从纽约开始,到德州,到加州,到夏威夷,到日本,中国,印度,以色列,意大利,英国,冰岛,再回到纽约,那么生产者切换之间的延迟就不会超过50到100毫秒。然而,如果顺序是随机的话,平均的切换时间会显著提高。

生产者洗牌(shuffling)是为了把一个生产者挑选继任生产者的可能性最小化才引入的。这个风险存在于假定生产者可能是恶意的情况下,而在一个高度审查,公开,生产者具有高质量数据中心的情况下,这种风险便不复存在。如果生产者故意的伤害了其他人,我们会有宪法和其他的措施来解决争端。

在EOS下,生产者会对生产循环顺序进行投票,以最大限度地减少平均延迟,并减少由于因特网网络拥塞造成的总错失块。

已知问题

EOS黎明2.0存在一些已知的问题,而对于早期版本的不稳定性也在预料之中。这次发布的目的在于演示基本功能,我们的团队将会在接下来的6个月中,修复bug提高稳定性和性能。

为了保证测试网络的稳定性,我们禁掉了生产者投票的功能。

结论

感想我们的开发团队,加班加点,通力合作,发布了EOS 黎明2.0,一个将来会是最健壮,性能最高,最去中心化的应用平台的alpha版本。我们会执行我们的路线图,发布更多的功能。我们希望在2018年,在EOS代币销售结束之前,能完成所有功能,修复所有bug,我们对此很有信心。

dbDao.com数据岛学习平台整体迁移到小密圈的公告

数据岛Oracle/MySQL学习平台将整体迁移到微信小密圈ORACLE,可以通过微信扫码加入小密圈来获得所有数据岛学习资料,加入小密圈的费用为300元/人。

扫码加入微信Oracle小密圈,了解Oracle最新技术下载分享资源

 

 

 

 

Solix优化Oracle E-Business Suite性能

Solix优化Oracle E-Business Suite性能

12c vs 11g x$messages

ACMS initialization ACMS
ADR PDB Auto Purge Task MMON
ADR Space Management Statistics Flush MMON
ARCH initialization ARC*
ASH Progressive Flusher (KEWA) MMON
ASM Audittrail cleanup MMON
AWR PDB Auto Flush Task MMON
AWR PDB Auto Purge Task MMON
AWR Raw Metrics Capture GEN1
Action-Based process Test GEN0
Archiver disconnect ARCH
Auxilary ipc finish gen0 action GEN0
Auxilary ipc init gen0 action GEN0
Auxilary ipc intr gen0 action GEN0
Auxilary ipc message gen0 action GEN0
Auxilary ipc timedout gen0 action GEN0
BA container GEN0 action GEN0
CLI AutoPartition MMON
CLI Create All Slave Tasks GEN0
CLI Create One Slave Task GEN0
Check for async in-memory job messages CJQ0
Cleanup of unpinned KGL handles MMON
Column-Level Statistics flush MMON
DBRM ADG in-memory state refresh DBRM
DBWO timeout kcbifc DBW0
DBWR write buffers DBW*|BW*
DDE Periodic Dump Scheduler MMON
DMON do critical instance eval and registration DMON
DSKM fini DSKM
DSKM init DSKM
DSKM procures HCA loadavg and computes offloaded write thresh DSKM
DTrace based Kernel IO  Outlier  Processing GEN0
Direct NFSv4 RENEW lease operation GEN0
Execute on-demand tuning task (KESTS) MMON
Free java patching locks LCK0
GEN0 Master Check GEN0
Get java patching locks LCK0
Hang Manager parameters GEN0
ILM check MMON
ILM cleanup MMON
ILM row access flush MMON
ILM segment access flush MMON
IMCO ADO action IMCO
IMCO FastStart Defer Write Scheduler IMCO
IMCO Trickle Repopulate IMCO
IMCO action IMCO
IMCO cycle action IMCO
IMCO global dictionary action IMCO
IMCO worker action IMCO
Inactive Account Time Job GEN0
Index usage tracking statistics flush MMON
Initiate KSBCITST TEST
KEWR SlavePool Test MMON Main MMON
KJBFP PBR logfile scan LMFC
KJBFP PBR recovery LMFC
KJBFP PBR writer main LMFC
KJBFP increment PRI LMFC
KJBFP pbr logFile CLose *
KJFM update process heartbeat LCK*|DIA*|LGWR|CKPT|DBRM|IPC0
KQLM interrupt action LCK1
KQLM invalidation instance lock operation LCK1
KSB GEN1 init GEN1
KSGL initialize service IPC0
KSGL mount in IPC0 IPC0
KSGL node exit IPC0
KSGL node join IPC0
KSGL notify IPC0 IPC0
KSGL timeout IPC0
KSIPC Grp Refresh action IPC0
KSIPC MGA Segment Check IPC0
KSIPC finish action IPC0
KSIPC initialize server IPC0
KSIPC interrupt action IPC0
KSIPC msg action IPC0
KSIPC reconfig action IPC0
KSIPC shutdown action IPC0
KSIPC timeout action IPC0
KSM SGA slaves spawn GEN0
KSRMA RMA OP IPC0
KSRMA Recovery Log Allocation IPC0
KSRMA mount IPC0
KSU GUID MAC Address update GEN0
LGWR flush workers LGWR
LGWR initialization LGWR
MMON request to purge LTXID history table MMON
Monitor initialization TMON
Monitor wakeup TMON
Multi procs per DTP UTMU
Network Server forced NSS*
Network Server shutdown NSS*
PDB SGA init GEN0
PDB close abort GEN0
PMON notify IPC0 of process failure IPC0
PQ: Adjust Slave Pool MMON
Payload action to BG RMON
Process new DBs that join ASM locally DIA*
RMON BG Driver RMON
RMON Init Action RMON
RTTD initialization RTTD
Real-Time ADDM Trigger MMON
Redo writer quiesce IMC on standby LGWR
Refresh active service cache MMON
Report Capture Daemon MMON
Report Capture Test (KERPI) MMON
SGA deferred allocated granules Initialization MMAN
SGA deferred allocated granules move MMAN
SMON_SCN_TIME Copy to PDBs MMON
SQL Memory Management Calculation DBRM
Spawn processes on behalf of someone else GEN0
Standby media recovery info cleanup LGWR
Suspended session cleanup GEN0
Sweep PL/SQL incidents MMON
Switchover/PDB relocate message channel subscribe LGWR
TPZ initialization TPZ*
Test Driver wakeup RTTD
Test Process wakeup TPZ*
Timeout interrupt action RBAL
Triton Session Cleanup MMON
UMF Auto Task Pool Queue Server MMON
UMF Auto Task Pool Scheduler MMON
UTS Async Dump GEN0
Volume Resource Action GEN0
Wait event outlier detection GEN0
XStream timeout action GEN0
acquire enq during pdbopen by HARIM DBW0
action for buddy instance RMS0
action to cleanup buddy instance context RMS0
check for KJCI cross-instance requests *
cleaning up workload information for optimizer MMON
clear the dependent scn DBRM
dblink logon table cleanup MMON
enter / exit graph test specified wait *
event nfy timeout action GEN0
event outlier dump info. GEN0
extend quarantine area GEN0
flushing workload information for optimizer MMON
free PX memory chunks in background PXMN
get/release open thread enqueue DBW*|BW*
init function for LCK1 *
initiate block repair GEN0
kcb DW object cooling GEN0
kcbz background redodump GEN0
kcbz update TSE bh CKPT
kill client GEN0
ksim cache line update LCK0
ksim instance group membership notifier *
kxfp remote slave spawn recv function PXMN
light-weight checks for optimizer statistics advisor MMON
mira CKPT channel CKPT
mount/dismount all db files DBW*|BW*
pdb event stats action GEN0
periodic PDB tasks GEN0
pmon dtp init PMON|CLMN
prespawn clean check GEN0
prespawn init check GEN0
prespawn timeout check GEN0
register to node local process group RBAL
shutdown RMON process RMON
sync PDB DBW0
threshold reloading MMON
unit test DBW0

oracle如何判定统计信息陈旧

本文原始地址:http://www.askmaclean.com/?p=18742

注意自动收集统计信息是从10g开始的,10g以前版本默认不自动收集统计信息。

对于自动收集统计信息而言需要知道统计信息是否陈旧stale ,判定陈旧的标准是对应的表上的数据修改超过10%(删除或插入或更新10%或以上数据行)。 这里oracle是如何知道修改超过10%的?

 

SGA的shared pool存有SQL的statistics情况,对应的有SQL处理的行数,SMON进程定期将这些信息刷到表SYS.MON_MODS$基表中(参考拙作: http://www.askmaclean.com/archives/smon-flush-dml-statistics-mon-mods.html):SMON后台进程会每15分钟将SGA中的DML统计信息刷新到SYS.MON_MODS$基表中(SMON flush every 15 minutes to SYS.MON_MODS$),
同时会将SYS.MON_MODS$中符合要求的数据MERGE合并到MON_MODS_ALL$中,并清空原MON_MODS$中的数据。
MON_MODS_ALL$作为dba_tab_modifications视图的数据来源,起到辅助统计信息收集的作用,详见拙作<Does GATHER_STATS_JOB gather all objects’ stats every time?>

这样基于之前的统计信息中的表的行数(dba_tables.num_rows),对比 MON_MODS_ALL$(dba_tab_modifications)中的update、delete、insert、truncate信息就可以知道该表从上一次收集统计信息到现在做了多少百分比的修改,若该百分比超过10%则判定为stale陈旧,否则为不陈旧。陈旧的统计信息会在自动收集统计信息时再次被收集。

 

 

DOP degree of parallelism的设计算法 ​​​​

直击oracle内核代码算法,对于11g以后的自动Parallelism算法一般只能用10053 trace来研究其算法。这里通过直接查看oracle源码设计文档,我们可以得到DOP degree of parallelism的设计算法

 

8358fa4fgy1fcr7ivo81lj20zq0kijwk

12CR2 vs 11gR2 新增optimizer 参数列表

_optimizer_adaptive_plan_control 0
_optimizer_adaptive_plans_continuous FALSE
_optimizer_adaptive_plans_iterative FALSE
_optimizer_adaptive_random_seed 0
_optimizer_ads_for_pq FALSE
_optimizer_ads_result_cache_life 3600
_optimizer_ads_spd_cache_owner_limit 64
_optimizer_ads_use_partial_results TRUE
_optimizer_ads_use_spd_cache TRUE
_optimizer_aggr_groupby_elim TRUE
_optimizer_ansi_join_lateral_enhance TRUE
_optimizer_ansi_rearchitecture TRUE
_optimizer_band_join_aware TRUE
_optimizer_batch_table_access_by_rowid TRUE
_optimizer_bushy_cost_factor 100
_optimizer_bushy_fact_dim_ratio 20
_optimizer_bushy_fact_min_size 100000
_optimizer_bushy_join off
_optimizer_cbqt_or_expansion ON
_optimizer_cluster_by_rowid TRUE
_optimizer_cluster_by_rowid_batch_size 100
_optimizer_cluster_by_rowid_batched TRUE
_optimizer_cluster_by_rowid_control 129
_optimizer_control_shard_qry_processing 65534
_optimizer_cube_join_enabled TRUE
_optimizer_db_blocks_buffers 0
_optimizer_dsdir_usage_control 0
_optimizer_eliminate_subquery TRUE
_optimizer_enable_plsql_stats TRUE
_optimizer_enhanced_join_elimination TRUE
_optimizer_gather_feedback TRUE
_optimizer_gather_stats_on_load TRUE
_optimizer_generate_ptf_implied_preds TRUE
_optimizer_generate_transitive_pred TRUE
_optimizer_hll_entry 4096
_optimizer_hybrid_fpwj_enabled TRUE
_optimizer_inmemory_access_path TRUE
_optimizer_inmemory_autodop TRUE
_optimizer_inmemory_bloom_filter TRUE
_optimizer_inmemory_capture_stored_stats TRUE
_optimizer_inmemory_cluster_aware_dop TRUE
_optimizer_inmemory_gen_pushable_preds TRUE
_optimizer_inmemory_minmax_pruning TRUE
_optimizer_inmemory_pruning_ratio_rows 100
_optimizer_inmemory_quotient 0
_optimizer_inmemory_table_expansion TRUE
_optimizer_inmemory_use_stored_stats AUTO
_optimizer_interleave_or_expansion TRUE
_optimizer_key_vector_aggr_factor 75
_optimizer_key_vector_pruning_enabled TRUE
_optimizer_multi_table_outerjoin TRUE
_optimizer_multicol_join_elimination TRUE
_optimizer_nlj_hj_adaptive_join TRUE
_optimizer_null_accepting_semijoin TRUE
_optimizer_partial_join_eval TRUE
_optimizer_performance_feedback OFF
_optimizer_proc_rate_level BASIC
_optimizer_proc_rate_source DEFAULT
_optimizer_reduce_groupby_key TRUE
_optimizer_strans_adaptive_pruning TRUE
_optimizer_synopsis_min_size 2
_optimizer_undo_cost_change 12.2.0.1
_optimizer_union_all_gsets TRUE
_optimizer_unnest_scalar_sq TRUE
_optimizer_use_feedback_for_join FALSE
_optimizer_use_gtt_session_stats TRUE
_optimizer_use_histograms TRUE
_optimizer_use_table_scanrate HADOOP_ONLY
_optimizer_use_xt_rowid TRUE
_optimizer_vector_base_dim_fact_factor 200
_optimizer_vector_cost_adj 100
_optimizer_vector_fact_dim_ratio 10
_optimizer_vector_min_fact_rows 10000000
_optimizer_vector_transformation TRUE
optimizer_adaptive_plans TRUE
optimizer_adaptive_reporting_only FALSE
optimizer_adaptive_statistics FALSE
optimizer_features_enable 12.2.0.1
optimizer_inmemory_aware TRUE

沪公网安备 31010802001379号

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569