首页 文章 精选 留言 我的

精选列表

搜索[高性能全文搜索引擎],共10000篇文章
优秀的个人博客,低调大师

《Oracle高性能自动化运维》一一导读

Preface 前 言 为什么要写这本书2008年的某一天,我怀着激动的心情参加了支付宝公司的面试,这次面试让我对国内最前沿的数据库自动化运维技术有了初步的认识,对我的职业生涯影响非常大,时刻激励着我以后不管遇到什么困难或者诱惑,Oracle始终都是我追逐的爱好和目标。在接下来几年的工作中,我较为深入地研究了C语言数据结构、Linux操作系统原理以及Shell(PHP/Java)编程等知识,这些技术能够很好地支撑Oracle运维管理。同时,多年的经验告诉我,对集运维与开发于一体的Oracle运维管理体系来而言,精通一门开发语言是相当有必要的,因为只有这样才可以更为深入地了解数据库与业务程序之间的架构设计,并能够更为精确地把控Oracle管理优化,从而在面对各种疑难问题时找到解决的突破口。 目录 第1章 Linux下的Oracle 1.01.1 Linux简介1.2 Oracle简介1.3 Linux内存体系的优势1.4 Linux内存体系与Oracle内存空间1.5 小结第2章 Oracle内存体系结构 2.02.1 闩(Latch)2.2 队列锁(Enqueue Lock)2.3 Library Cache2.4 Buffer Cache2.5 小结第3章 Oracle重做日志(Redo) 3.03.1 Redo功能用途3.2 Redo组成结构3.3 Redo产生场景3.4 Redo优化3.5 小结

优秀的个人博客,低调大师

MORPHiS —— 点对点高性能分布式文件系统

MORPHiS 现在是早期阶段,主要目标是成为一个全局加密分布式存储,为了替代云存储。MORPHiS 现在包含一个 DMAIL(分布式邮件),内置垃圾邮件拦截,内置加密,免费发送信息。 MORPHiS 的使用非常简单:下载,双击,在 Web 浏览器打开一个窗口查看原始 MORPHiS UI 页面,就可以使用浏览和上传功能。 文章转载自 开源中国社区 [http://www.oschina.net]

优秀的个人博客,低调大师

优化SQL查询:如何写出高性能SQL语句

【大咖・来了 第7期】10月24日晚8点观看《智能导购对话机器人实践》 1、 首先要搞明白什么叫执行计划? 执行计划是数据库根据SQL语句和相关表的统计信息作出的一个查询方案,这个方案是由查询优化器自动分析产生的,比如一条SQL语句如果用来从一个 10万条记录的表中查1条记录,那查询优化器会选择“索引查找”方式,如果该表进行了归档,当前只剩下5000条记录了,那查询优化器就会改变方案,采用 “全表扫描”方式。 可见,执行计划并不是固定的,它是“个性化的”。产生一个正确的“执行计划”有两点很重要: (1) SQL语句是否清晰地告诉查询优化器它想干什么? (2) 查询优化器得到的数据库统计信息是否是***的、正确的? 2、 统一SQL语句的写法 对于以下两句SQL语句,程序员认为是相同的,数据库查询优化器认为是不同的。 select*from dual select*From dual 其实就是大小写不同,查询分析器就认为是两句不同的SQL语句,必须进行两次解析。生成2个执行计划。所以作为程序员,应该保证相同的查询语句在任何地方都一致,多一个空格都不行! 3、 不要把SQL语句写得太复杂 我经常看到,从数据库中捕捉到的一条SQL语句打印出来有2张A4纸这么长。一般来说这么复杂的语句通常都是有问题的。我拿着这2页长的SQL语句去请教原作者,结果他说时间太长,他一时也看不懂了。可想而知,连原作者都有可能看糊涂的SQL语句,数据库也一样会看糊涂。 一般,将一个Select语句的结果作为子集,然后从该子集中再进行查询,这种一层嵌套语句还是比较常见的,但是根据经验,超过3层嵌套,查询优化器就很容易给出错误的执行计划。因为它被绕晕了。像这种类似人工智能的东西,终究比人的分辨力要差些,如果人都看晕了,我可以保证数据库也会晕的。 另外,执行计划是可以被重用的,越简单的SQL语句被重用的可能性越高。而复杂的SQL语句只要有一个字符发生变化就必须重新解析,然后再把这一大堆垃圾塞在内存里。可想而知,数据库的效率会何等低下。 4、 使用“临时表”暂存中间结果 简化SQL语句的重要方法就是采用临时表暂存中间结果,但是,临时表的好处远远不止这些,将临时结果暂存在临时表,后面的查询就在tempdb中了,这可以避免程序中多次扫描主表,也大大减少了程序执行中“共享锁”阻塞“更新锁”,减少了阻塞,提高了并发性能。 5、 OLTP系统SQL语句必须采用绑定变量 select*from orderheader where changetime >'2010-10-20 00:00:01' select*from orderheader where changetime >'2010-09-22 00:00:01' 以上两句语句,查询优化器认为是不同的SQL语句,需要解析两次。如果采用绑定变量 select*from orderheader where changetime >@chgtime @chgtime变量可以传入任何值,这样大量的类似查询可以重用该执行计划了,这可以大大降低数据库解析SQL语句的负担。一次解析,多次重用,是提高数据库效率的原则。 6、 绑定变量窥测 事物都存在两面性,绑定变量对大多数OLTP处理是适用的,但是也有例外。比如在where条件中的字段是“倾斜字段”的时候。 “倾斜字段”指该列中的绝大多数的值都是相同的,比如一张人口调查表,其中“民族”这列,90%以上都是汉族。那么如果一个SQL语句要查询30岁的汉族人口有多少,那“民族”这列必然要被放在where条件中。这个时候如果采用绑定变量@nation会存在很大问题。 试想如果@nation传入的***个值是“汉族”,那整个执行计划必然会选择表扫描。然后,第二个值传入的是“布依族”,按理说“布依族”占的比例可能只有万分之一,应该采用索引查找。但是,由于重用了***次解析的“汉族”的那个执行计划,那么第二次也将采用表扫描方式。这个问题就是著名的“绑定变量窥测”,建议对于“倾斜字段”不要采用绑定变量。 7、 只在必要的情况下才使用begin tran SQL Server中一句SQL语句默认就是一个事务,在该语句执行完成后也是默认commit的。其实,这就是begin tran的一个最小化的形式,好比在每句语句开头隐含了一个begin tran,结束时隐含了一个commit。 有些情况下,我们需要显式声明begin tran,比如做“插、删、改”操作需要同时修改几个表,要求要么几个表都修改成功,要么都不成功。begin tran 可以起到这样的作用,它可以把若干SQL语句套在一起执行,***再一起commit。好处是保证了数据的一致性,但任何事情都不是***无缺的。Begin tran付出的代价是在提交之前,所有SQL语句锁住的资源都不能释放,直到commit掉。 可见,如果Begin tran套住的SQL语句太多,那数据库的性能就糟糕了。在该大事务提交之前,必然会阻塞别的语句,造成block很多。 Begin tran使用的原则是,在保证数据一致性的前提下,begin tran 套住的SQL语句越少越好!有些情况下可以采用触发器同步数据,不一定要用begin tran。 8、 一些SQL查询语句应加上nolock 在SQL语句中加nolock是提高SQL Server并发性能的重要手段,在oracle中并不需要这样做,因为oracle的结构更为合理,有undo表空间保存“数据前影”,该数据如果在修改中还未commit,那么你读到的是它修改之前的副本,该副本放在undo表空间中。这样,oracle的读、写可以做到互不影响,这也是oracle 广受称赞的地方。SQL Server 的读、写是会相互阻塞的,为了提高并发性能,对于一些查询,可以加上nolock,这样读的时候可以允许写,但缺点是可能读到未提交的脏数据。使用 nolock有3条原则。 (1) 查询的结果用于“插、删、改”的不能加nolock ! (2) 查询的表属于频繁发生页分裂的,慎用nolock ! (3) 使用临时表一样可以保存“数据前影”,起到类似oracle的undo表空间的功能, 能采用临时表提高并发性能的,不要用nolock 。 9、 聚集索引没有建在表的顺序字段上,该表容易发生页分裂 比如订单表,有订单编号orderid,也有客户编号contactid,那么聚集索引应该加在哪个字段上呢?对于该表,订单编号是顺序添加的,如果在orderid上加聚集索引,新增的行都是添加在末尾,这样不容易经常产生页分裂。然而,由于大多数查询都是根据客户编号来查的,因此,将聚集索引加在contactid上才有意义。而contactid对于订单表而言,并非顺序字段。 比如“张三”的“contactid”是001,那么“张三”的订单信息必须都放在这张表的***个数据页上,如果今天“张三”新下了一个订单,那该订单信息不能放在表的***一页,而是***页!如果***页放满了呢?很抱歉,该表所有数据都要往后移动为这条记录腾地方。 SQL Server的索引和Oracle的索引是不同的,SQL Server的聚集索引实际上是对表按照聚集索引字段的顺序进行了排序,相当于oracle的索引组织表。SQL Server的聚集索引就是表本身的一种组织形式,所以它的效率是非常高的。也正因为此,插入一条记录,它的位置不是随便放的,而是要按照顺序放在该放的数据页,如果那个数据页没有空间了,就引起了页分裂。所以很显然,聚集索引没有建在表的顺序字段上,该表容易发生页分裂。 曾经碰到过一个情况,一位哥们的某张表重建索引后,插入的效率大幅下降了。估计情况大概是这样的。该表的聚集索引可能没有建在表的顺序字段上,该表经常被归档,所以该表的数据是以一种稀疏状态存在的。比如张三下过20张订单,而最近3个月的订单只有5张,归档策略是保留3个月数据,那么张三过去的 15张订单已经被归档,留下15个空位,可以在insert发生时重新被利用。在这种情况下由于有空位可以利用,就不会发生页分裂。但是查询性能会比较低,因为查询时必须扫描那些没有数据的空位。 重建聚集索引后情况改变了,因为重建聚集索引就是把表中的数据重新排列一遍,原来的空位没有了,而页的填充率又很高,插入数据经常要发生页分裂,所以性能大幅下降。 对于聚集索引没有建在顺序字段上的表,是否要给与比较低的页填充率?是否要避免重建聚集索引?是一个值得考虑的问题! 10、加nolock后查询经常发生页分裂的表,容易产生跳读或重复读 加nolock后可以在“插、删、改”的同时进行查询,但是由于同时发生“插、删、改”,在某些情况下,一旦该数据页满了,那么页分裂不可避免,而此时nolock的查询正在发生,比如在第100页已经读过的记录,可能会因为页分裂而分到第101页,这有可能使得nolock查询在读101页时重复读到该条数据,产生“重复读”。同理,如果在100页上的数据还没被读到就分到99页去了,那nolock查询有可能会漏过该记录,产生“跳读”。 上面提到的哥们,在加了nolock后一些操作出现报错,估计有可能因为nolock查询产生了重复读,2条相同的记录去插入别的表,当然会发生主键冲突。 11、使用like进行模糊查询时应注意 有的时候会需要进行一些模糊查询比如 select*from contact where username like ‘%yue%’ 关键词%yue%,由于yue前面用到了“%”,因此该查询必然走全表扫描,除非必要,否则不要在关键词前加%, 12、数据类型的隐式转换对查询效率的影响 sql server2000的数据库,我们的程序在提交sql语句的时候,没有使用强类型提交这个字段的值,由sql server 2000自动转换数据类型,会导致传入的参数与主键字段类型不一致,这个时候sql server 2000可能就会使用全表扫描。Sql2005上没有发现这种问题,但是还是应该注意一下。 13、SQL Server 表连接的三种方式 (1) Merge Join (2) Nested Loop Join (3) Hash Join SQL Server 2000只有一种join方式——Nested Loop Join,如果A结果集较小,那就默认作为外表,A中每条记录都要去B中扫描一遍,实际扫过的行数相当于A结果集行数x B结果集行数。所以如果两个结果集都很大,那Join的结果很糟糕。 SQL Server 2005新增了Merge Join,如果A表和B表的连接字段正好是聚集索引所在字段,那么表的顺序已经排好,只要两边拼上去就行了,这种join的开销相当于A表的结果集行数加上B表的结果集行数,一个是加,一个是乘,可见merge join 的效果要比Nested Loop Join好多了。 如果连接的字段上没有索引,那SQL2000的效率是相当低的,而SQL2005提供了Hash join,相当于临时给A,B表的结果集加上索引,因此SQL2005的效率比SQL2000有很大提高,我认为,这是一个重要的原因。 总结一下,在表连接时要注意以下几点: (1) 连接字段尽量选择聚集索引所在的字段 (2) 仔细考虑where条件,尽量减小A、B表的结果集 (3) 如果很多join的连接字段都缺少索引,而你还在用SQL Server 2000,赶紧升级吧。 【责任编辑: seeker TEL:(010)68476606】

优秀的个人博客,低调大师

《数据安全复合治理与实践白皮书》正式发布,构建“复合治理”安全观【附全文下载】

51CTO社区编辑加盟指南,欢迎关注! WOT全球技术创新大会2022,门票6折抢购中!购票立减2320元!--> 2021年12月22日,由中国软件评测中心、国家信息中心《信息安全研究》、蚂蚁集团联合编写的《数据安全复合治理与实践白皮书》正式发布。 白皮书在对现阶段全球数据安全产业发展格局及治理态势进行充分调研与深度剖析的基础上,从引导企业建设与升级数据安全治理体系的视角出发,以“战略要位、实战牵引、全员参与、技术破局”为核心指导思想,强调数据安全的“复合”治理,即:对治理框架搭建中战略、管理和技术进行统筹规划与设计,形成基线设定、心智运营、原生设计、安全度量、可证溯源、红蓝对抗、测评认证等丰富的治理环节,强化治理过程的联动,将安全与业务复合、管理与技术复合,形成有机整体,充分发挥复合协同效能,构建体系化、准确量化、持续优化的数据安全复合治理模式。 此次蚂蚁集团与国家权威单位联合,结合自身丰富的业务应用场景与实践经验,深度参与白皮书的调研与编写工作。面对我国数据安全法制元年的政策背景,针对数据安全产业规模快速激增,应对敏感数据泄露、数据非法贩卖、数据滥用等安全风险,总结性提出“数据安全复合治理模式”,旨在为企业开展数据安全治理工作提供更加有价值的参考与建议,并为数据安全治理体系与科技能力的建设、优化与升级提供实践路径。 【图一 《数据安全复合治理与实践白皮书》复合治理模式】 企业在开展数据安全治理工作时,如何评估安全治理效果是一个比较普遍的痛点、难点问题。白皮书创新性地提出了多视角安全度量体系,由于安全治理是个体系化的风险管理工程,安全度量需要从多个评价视角入手才能全面衡量治理效果。一方面要对员工安全意识教育、防护建设覆盖等治理过程进行准确度量以体现安全工作进展与成果,另一方面从风险主体视角,以安全规范、安全基线等合规要求为输入,来衡量各类风险主体的风险程度与严重性,并围绕风险分数开展场景化应用和通晒排名等运营模式,以提高主体的风险重视度。最终,还需要用攻防视角的红蓝演练等实战手段,对于治理体系的薄弱环节进行验证、对风险盲区进行发现,以真实客观评价安全治理体系的实战有效性。总体上,在多视角安全度量体系的驱动下,企业得以看清当前安全水位,落实安全风险的精细化管理,持续提升安全水位,并保证自身体系的健壮性。 【图二 《数据安全复合治理与实践白皮书》多视角安全度量】 数据安全治理科技从系统能力、算法能力、数据能力和产品能力四大维度阐述了如何建设与完善数据安全治理的技术体系。系统能力包括安全平行切面、密码基础设施、安全可信环境、终端安全等,旨在构建安全可信的系统和环境支持,为数据安全治理提供底层环境支撑。算法能力重点关注数据资产识别、数据血缘图谱、异常访问检测等智能算法建设,应对数据安全治理中的“看见数据”、“看清数据”和“理清风险”三大难题。数据能力主要提供准实时精准检索、压缩索引、异构数据提取等数据加工能力,实现大规模数据的准实时快速定位。产品能力旨在从全息资产画像、深度安全防护、智能安全运营、隐私保护与隐私计算等领域出发,构建从数据资产识别到动态安全管控到智慧安全运营到数据价值利用的全方位、体系化的产品能力,满足不同数据安全治理场景下的技术需求。 【图三 《数据安全复合治理与实践白皮书》数据安全治理科技】 复合治理模式强调全员参与、原生式安全以及智能化安全运营机制。 全员参与。数据与业务紧密交织,正是基于这一特点,蚂蚁集团在数据安全的风险管理上一直秉承一个理念:“数据安全不仅是安全团队的事情,而是每个公司员工都需要高度重视的事情”。因此,如何构建一个全员参与的风险治理体系就显得格外重要。蚂蚁集团通过“啄木鸟”行动等丰富、活泼的心智运营活动设计,充分调动全员主动参与积极性,有效实现不同特点人群的精确触达。 原生式安全。将数据安全的理念和要求融入到研发的过程中,保证产品在发布前已具备充分必要的数据保护措施,而不是出现数据安全问题以后,被动地修复和治理。同时可针对数据处理产品组件开展内部认证,推荐、保障研发团队使用安全、可靠的组件,对使用不符合内部认证标准的组件的产品和系统,督促其及时进行整改,以增强产品和系统的“天然免疫力”。 建设智能化的安全运营机制,以进一步提升数据安全治理的自动化水平和效率。以红蓝演练为例,通过沉淀自动化、模块化、组件化的红蓝演练能力,制定演练科学投放的策略,并建设全链路风险跟踪能力,形成常态化的红蓝演练机制,从攻防视角更加高效、及时地识别和修复安全风险,实现“以攻促防、攻防相长”的目标。 【图四 《数据安全复合治理与实践白皮书》自动化红蓝演练平台】 《数据安全复合治理与实践白皮书》完整版下载链接:https://pan.baidu.com/s/1xEaVzUZcf42gkulP5cCA-Q提取码: epfj 【责任编辑:贺鑫 TEL:(010)68476606】

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

用户登录
用户注册