5个需要采集数据库基线数据的理由

基线是度量变化的一个参考。基线常常用于医药领域。医生在为病人开药时,会测量病人的血压和心率,采集体重或者进行血液检查。在过了一段时间以后,医生会重

新采集同样的数据来观察什么指标发生了变化,以便充分评估药物的影响。

在IT领域,也存在同样的方式。DBA们也能够使用基线来衡量计划或者未计划的变化的影响。在最好的情况下,这些数据可以用来快速识别那些计划外的导致性能问题的行为。同时,采集基线最起码可以让DBA了解当前配置中存在的问题和制定未来的计划。

使用基线是个好方法,似乎每个DBA都明白它的价值。但不幸的是,还有很多公司并没有关于数据库的基线数据。这可能会有两方面的原因,一个启动成本,需要大量的时间和精力。如果打算推出自己采集基线的方法,必须对以下问题进行一个思考,并好好回答。

1,你要采集什么样的数据?(what)

2,你要在何时采集数据?(when)

3,你会使用什么方法来采集数据?(what method ,也就是how)

4,你将会把数据存放在哪里?(where)

5,你从采集的数据里面怎样得到数据库情况报告?(how)

6,你要怎样长期管理这些采集的数据?(how long)

这些问题需要一些思考并采取相关的对策。不过,似乎很多人常常都是喜欢生活在没有数据的世界里,而不是努力去获取数据。(很多决策都是基于历史数据而进行的)。

第二个因素是我们自己的被动性。如果对一个DBA问到,“你会采集基线吗?”,通常的答案是一声叹气,“不会”。造成这样的原因是很多的,有些DBA会说,手头有很多工作没做完;有些DBA会说,整天忙于救火和应对突发事件。归根到底,都是说没有时间或者精力来实施新的东西,例如部署采集数据库基线的方法。当然,也会有的DBA回答说,没想过主动实施采集基线的策略,因为觉得部署采集基线的活动需要花很多时间和精力,有时候还会吃力不讨好。

1,为什么呢?

最大原因应该是采集基线数据是件比较棘手的事情。DBA可能会意识到基线数据的价值,但是,很多公司并不会去买第三方工具来采集基线数据,因此,很多人都需要手工来采集基线数据。当打打算这样做的时候,我们也会遇到各种问题:从哪里开始?自己是否有足够的时间来进行?采集基线对我有多大帮助?在没有基线数据时,我已经能够解决问题了,真的还需要基线数据吗?

呵呵,这就是关键点了:我们真的需要基线数据吗?我不能很好的回答这个问题,但从每一个有基线数据的数据库实例来看,基线数据已经证明了其价值。也许,我们会遇到,在我们拥有基线数据时,遇到了一个问题了,但基线数据对该问题没有参考价值。但,我们也应该换一个角度来考虑,我们是否遇到过没有可参考数据的情况下来解决问题?如果有参考数据时,我们是否能更快速的解决问题呢?如果有参考数据时,我们是否可以为团队,为公司创造更大的价值?

事实上,基线数据可以让DBA的日子过得越来越舒服。因为:

1,你可以发现在某个东西成为一个问题之前发生了什么改变?

2,更容易排除故障

3,可以更容易的主动进行性能调优

4,可以让你了解当前环境和数据的变化趋势

5,可以提供更好的容量规划

。。。

2,该采集什么呢?

千里之行始于足下,要做一件事情时,可以从最简单的入手。因为可以采集的数据是很多的,如果不加以规划和甄别,很容易被海量的数据给淹没,不仅没有带来价值,反而增加了负担。因此,需要把重点放在哪些数据是最重要的,哪些数据可以帮助我们定位性能问题?同时,也要关注数据库在哪个时间段比较容易出问题?一般情况下,可以从以下几方面入手:

1,基本信息

2,系统使用信息

3,文件和数据库大小信息

4,Wait 统计信息

我们从SQL Server的基本信息开始,因为这些信息很容易被DBA改变,特别是在有多个DBA的可以访问SQL Server环境的情况下。经常会遇到某个人修改了某个值(如max memory allocated 或max degree of parallelism),而DBA却不知道这样的改变!而随着虚拟化大潮的来临,在虚拟化环境下,DBA们更容易遇到如从一个虚拟机迁移到另外一台主机时的一些莫名奇妙的问题,而这些通常都是配置问题导致的。

如果你知道一些基本性能监控计数器(如CPU,内存,磁盘延迟)、数据库连接和活动等的基线信息,在发生性能问题时,可以优先检查这些数据,看能否发现一些问题。特别是如果使用了脚本,就可以快速的获取当前的性能数据,并和正常的性能数据比较。最后,如果DBA管理多个数据库实例,这些对系统使用,安装异常,预算等的趋势信息,在与领导沟通汇报时,会更有用。

一旦知道了基本的设置和系统的使用情况,就可以采集文件和数据库的增长的基线数据了。一个DBA的主要和最重要的工作之一是,保持系统的可用性。因此,避免数据库运行的空间不足,采集基线数据是最快捷的方式,也是很重要的方式。最好的做法是通过采集当前的文件和磁盘的大小,计算出数据增长的趋势:通过这样做,会使计划磁盘空间或数据迁移时变得更加容易。如果系统数据库中的表的大小异常增长了,DBA可以深入了解这个相关的业务,了解应用程序是如何使用的,从而排除是否存在问题。

最后,除了了解CPU,I /O和内存的正常值外,还有一个很重要的,是看一个数据库服务器里的等待统计信息。每个SQL Server实例都有等待统计信息,而这些信息可以用于性能调优,通过它,可以了解基本的正常的等待统计信息,在需要的时候,也可以用来进行比较。

3,何时采集

一旦已经决定想要什么样的数据,必须决定采集的频率。数据太多,会占用额外的空间,太少,你不能很好的了解数据库到底发生了什么。采集的频率取决于数据本身,例如性能计数器可以每隔15秒。但捕捉事务日志文件的大小时,就没必要以15s作为采集间隔了。

另外,你需要确定是否需要查看最繁忙的时间段或正常营业时间或任何时间的数据。你还必须确定,会保持多久的数据。是否有必要将数据保存6个月,或一年?也许三个月的数据就足够了。只有你自己知道自己数据库的情况并进行管理。同样,也可以从简单的开始,这是比较直接的,例如仅在工作时间和捕获数据,只保留最后3个月的指标进行比较,到时候再根据实际情况,建立其他采集模式或扩大。

4,存放何处

根据经验,最好是创建一个单独的数据库来存储所有的生产库实例的基本信息。最好需要一个共享服务器来存放基线数据库,这样所有生产服务器上的数据可以被复制然后存储在基线数据库。同时应该定期备份该数据库,和采集,迁移,存储的脚本。并把查看基线数据信息当成的日常工作必不可少的一部分。

5,下一步

本文一系列的四个有关采集基线数据的文章。接下来的三篇文章,将逐步获得上述的数据采集的过程,并提供脚本。你的第一个任务是找到一个书库实例,在这里你可以建立一个基线数据库。你的第二个任务是致力于采集这些数据。开始行动吧,骚年?

原文地址:https://www.cnblogs.com/wuchangsoft/p/9926396.html

时间: 2024-11-07 22:07:09

5个需要采集数据库基线数据的理由的相关文章

数据库端数据转移

工作中遇到需要实现不同版本的数据库间,数据同步.当然了前提数据表接口相同.有了2个多小时时间写了一个支持批量多张数据表进行有条件的数据转移.不受标识列的限制.如有不周之处还请大家积极批评指正. ----------*************************************************************************************** if exists (select * from dbo.sysobjects where id = obje

NoSQL数据库:数据的一致性

NoSQL数据库:数据的一致性 读取一致性 强一致性 在任何时间访问集群中任一结点,得到的数据结果一致: 用户一致性       对同一用户,访问集群期间得到的数据一致:        解决用户一致性:使用粘性会话,将会话绑定到特定结点来处理:        这样会降低负载均衡器的性能: 最终一致性       集群中各结点间由于数据同步不及时造成暂时的数据不一致,但数据同步完成后,最终具有一致性: 更新一致性 悲观方式 使用写锁 大幅降低系统响应能力 可能导致死锁 乐观方式 先让冲突发生,再检

如何导出数据库的数据词典

在项目的开发时,为了深入了解项目的数据情况,通常都会使用到数据字典,方便对某个字段进行详细的了解,加快开发的速度以及防止不必要的错误发生,下面介绍下数据字典的生成. 第一,可以使用第三方的工具如sqlyog 第二,就是自己进行编写一些代码进行导出,下面是一些PHP代码,连接数据库对某个数据库的数据词典导出 <?php header('content-type:text/html;charset=utf-8'); define('DB_HOST','localhost'); define('DB_

JAVA对数据库进行操作,实现数据库中数据的插入,查询,更改,删除操作

(—)通过mysql workbench 创建一个数据库,在这里命名为company,然后建一个tb_employee表 (二)以下是java代码对表tb_employee的操作 1 创建一个Employee类,包括员工的一些信息,如  id  name age sex 2创建DatabaseConnection类,用于数据库的连接 3创建一个EmployeeOperation类,用于操作数据库,它里面包括了 以下方法 (1)getInstance()   //返回EmployeeOperati

数据库设计--数据的垂直拆分

如果表字段太多,如果表中有些字段比较大,即便是你只查有限的几个字段,在做表关联和全表扫的时候,由于扫描的数据块多,性能方面还是会不理想.因为oracle扫描的时候是按照块为单位扫描,读取的时候也是按块为单位读取,所以这种功能无法在SQL层面上优化的时候,可以考虑做数据的垂直切分,下面来做个试验: --制造数据不做垂直切分 create table test( a number, b varchar2(4000), c varchar2(4000), d varchar2(4000), e var

用struts2标签如何从数据库获取数据并在查询页面显示。最近做一个小项目,需要用到struts2标签从数据库查询数据,并且用迭代器iterator标签在查询页面显示,可是一开始,怎么也获取不到数据,想了许久,最后发现,是自己少定义了一个变量,也就是var变量。

最近做一个小项目,需要用到struts2标签从数据库查询数据,并且用迭代器iterator标签在查询页面显示,可是一开始,怎么也获取不到数据,想了许久,最后发现,是自己少定义了一个变量,也就是var变量.<s:iterator>标签有一个value属性,用来存放在Action类的方法中存数据的list集合,还有一个id,好像是说指定集合的索引的意思,就是给list集合遍历出来的每个对象加上一个数字标签,反正我是这么理解的,没用过.还有一个很重要,就是var变量,我在s:iterator按ctr

Oracle如何实现创建数据库、备份数据库及数据导出导入的一条龙操作

Oracle如何实现创建数据库.备份数据库及数据导出导入的一条龙操作 Oracle中对数据对象和数据的管理,无疑都是使用PL/SQL Developer来进行管理,该工具也提供给我们很多方便.快捷的操作,使得我们不再为Oracle本身丑陋.难用的UI而抱怨.由于我们一般都是建建表.查查数据的操作居多,较少会考虑系统的整个Oracle的完整备份操作.但是在我们一些发布操作中,我们必须考虑如何把Oracle的对象.表数据导出到Sql脚本中,并且把创建Oracle表空间.创建Oracle数据库的操作也

jquery.datatable插件从数据库读取数据

一.分页 分页的基本思想是根据datatable的页码及每页显示的行数,将数据从数据库分段提出,然后再填充到表格中,以达到分页的效果. 这里需要用到datatable插件的几个属性: "sEcho":这个属性需要原封不动地传回给datatable,具体的作用我也不清楚,但是根据它值的变化情况来看,好像是一个操作次数的计数(之前我一直把它当做是pageindex来用,结果发现,不论我在datatable中是翻下一页还是翻上一页,它一直在增加.) "iDisplayStart&q

echarts通过ajax向服务器发送post请求,servlet从数据库读取数据并返回前端

1.echarts的官网上的demo,都是直接写死的随机数据,没有和数据库的交互,所以就自己写了一下,ok,我们开始一步一步走一遍整个流程吧. 就以官网最简单的那个小demo来做修改吧.官网上的小demo的效果图如下:(很熟悉,有没有) 2.按照echarts的使用方法新建一个echarts.html文件.为ECharts准备一个具备大小(宽高)的Dom(讲的有点细,熟悉的朋友直接跳过) <!DOCTYPE html> <head> <meta charset="u