xml地图|网站地图|网站标签 [设为首页] [加入收藏]
数据库的日常管理经验浅谈,到底是什么意思
分类:数据库

       BEGIN TRAN
       INSERT INTO test_main VALUES(5, 'five')

一.概述    

  前面章节介绍了很多数据库的优化措施,但在实际生产环境中,由于数据库服务器本身的性能局限,就必须要对前台的应用来进行优化,使得前台访问数据库的压力能够减到最小。
  1. 使用连接池   对于访问数据库来说,建立连接的代价比较昂贵,因为连接到数据库服务器需要经历多个步骤如:建立物理通道,服务器进行初次握手,分析连接字符串信息,由服务器对连接进行身份验证等。因此,有必要建立"连接池"以提高访问的性能。连接池中的连接已经预先创建好了,可以直接分配给应用层使用,减少了创建新连接所消耗的资源,连接返回后,本次访问将连接交还给"连接池",以供新的访问使用。

(1)如果池中有空闲连接可用,返回该连接。
(2)如果池中连接都已用完,创建一个新连接添加到池中。
(3)如果池中连接已达到最大连接数,请求进入等待队列直到有空闲连接可用。

//下面以ado.net 连接数据库为例:
             //引用 System.Data.SqlClient
            //可以使用字符串connectionString来实例化SqlConnection对象
            string connectionString ="Integrated Security=False;server={0};database={1};User ID={2};Password={3};Max Pool Size=512;Connect Timeout=30";

            //也可以使用SqlConnectionStringBuilder类来实例化SqlConnection对象
            SqlConnectionStringBuilder sqlconnStringBuilder = new SqlConnectionStringBuilder();
            //连接池是否默认打开 默认为true
            sqlconnStringBuilder.Pooling = true;
            //连接池中最大连接数
            sqlconnStringBuilder.MaxPoolSize = 512;
            //连接请求等待超时时间。默认为15秒,单位为秒。
            sqlconnStringBuilder.ConnectTimeout = 30;
            sqlconnStringBuilder.DataSource = "";
            sqlconnStringBuilder.UserID = "";
            sqlconnStringBuilder.Password = "";
            //使用用户名和密码连接
            sqlconnStringBuilder.IntegratedSecurity = false;

            SqlConnection sql = new SqlConnection(connectionString);
            //or
            sql = new SqlConnection(sqlconnStringBuilder.ConnectionString);

            //用完后记得关闭当前连接
            sql.Close();

            //使用mysql一样 引用MySql.Data.dll
            MySql.Data.MySqlClient.MySqlConnection mysqlconn = new MySql.Data.MySqlClient.MySqlConnection();
            MySql.Data.MySqlClient.MySqlConnectionStringBuilder mysqlconnStringBuilder = new MySql.Data.MySqlClient.MySqlConnectionStringBuilder();

  2.使用查询缓存   mysql的查询缓存在4.1版本以后新增的功能,它的作用是存储select 查询的文本以及相应结果。如果随后收到一个相同的查询,服务器会从查询缓存中重新得到查询结果,而不再需要解析和执行查询。查询缓存的适用对象是更新不频繁的表,当表更改(表结构和表数据)后,查询缓存值的相关条目被清空。

--  查询缓存相关的参数
SHOW VARIABLES LIKE '%query_cache%';

图片 1

        参数解释:

have_query_cache

表示这个mysql版本是否支持查询缓存。

query_cache_limit

表示单个结果集所被允许缓存的最大值。

1048576.0/1024.0/1024.0=1.0M 默认1M,超过空间大小不被缓存。

query_cache_min_res_unit

每个被缓存的结果集要占用的最小内存。

query_cache_size

用于查询缓存的内存总大小。

1048576.0/1024.0/1024.0=1.0M 默认1M,超过空间大小不被缓存。

query_cache_type

默认关闭缓存

query_cache_wlock_invalidate

控制当有写锁加在表上的时候,是否先让该表相关的 Query Cache失效。

OFF: 是指在锁定时刻仍然允许读取该表相关的 Query Cache。

ON: 写锁定的同时将使该表相关的所有 Query Cache 失效。

-- 监视查询缓存的使用状况
SHOW STATUS LIKE 'Qcache%' 

图片 2

      参数解释:

Qcache_free_memory  

查询缓存目前剩余空间大小。

Qcache_hits          

查询缓存的命中次数。

Qcache_inserts      

查询缓存插入的次数

Qcache_free_blocks

目前还有多少剩余的blocks。FLUSH QUERY CACHE 会对缓存中的碎片进行整理,从而得到一个空闲块。这个值比较大,意味着内存碎片比较多

Qcache_lowmem_prunes 多少条Query 因为内存不足而被清除出Query Cache。缓存出现内存不足并且必须要进行清理,以便为更多查询提供空间的次数。这个数字最好长时间来看;如果这个数字在不断增长,就表示可能碎片非常严重,或者内存很少。

Qcache_not_cached

不能被cache 的Query 的数量。不适合进行缓存查询的数量,通常是由于这些查询不是 SELECT 语句

Qcache_queries_in_cache

当前Query Cache 中cache 的Query 数量.

Qcache_total_blocks

当前Query Cache 中的block 数量。

  (查询缓存章节未完...)

写在前面

  上一篇我主要分享了架构的一些选型之法,架构之路不是简单的技术,而是多方的协调,业务的理解、技术的沉淀、经验。

  架构文章链接:如何规划、建设你的数据库架构

  架构涉及系统的安全、连续、高效状态,一般来说仍然需要很专业的架构规划人介入,另外除了架构层面数据库的管理也是非常重要的一部分,那么我们今天来聊聊数据库的管理。

  本文也是精炼多次在各行业演讲的内容,分享给博友!

  图片 3

  图片 4

 

 

  以前遇到过,但仅限于听同事说加上NOLOCK好一些,今天仔细研究测试了下,终于理解了,那么加与不加到底区别在哪呢?

  工具篇

  首先普遍缺乏DBA的企业中是否可以找到一个称手的工具,正所谓 "武林至尊,宝刀屠龙,号令天下,莫敢不从,倚天不出,谁与争锋" 

  称手的工具产品对于管理数据库更为重要,对于武林高手(资深DBA)工具能起到的作用——方便,对于非专业数据库人员起到的左右——一个DBA小秘书

  那么现在的数据库称手兵器应该做到什么?? (个人觉得至少要下述内容)

  1. 统一管理,统一呈现
  2. 实时知道复杂的数据库运行状态,运行了哪些语句,运行的怎么样?
  3. 告警,问题及时自动报告
  4. 知道过去发生了什么,就像“摄像头” 记录分分秒秒,记录案发现场
  5. 指标全面,支撑解决问题,可以应对数据库的复杂场景,生僻问题
  6. 智能化,自动化巡检,一键发现潜在隐患
  7. 智能化,解决问题(性能、日常运维)

  这样的工具也许就是知道数据库的“昨天、今天、明天”,也就是“过去、现在和将来”

  图片 5

 

   当然,现在的运维管理工具产品越来越强大,强大到甚至让我这10年的老司机都感觉到要被取代,往往非专业的DBA缺少的是:

  1. 解决问题所需要的数据支撑
  2. 分析问题的逻辑
  3. 解决问题的手段

  那相应的工具产品中也要做到数据指标全面,而且对分析问题的流程和逻辑做到只需 “按步骤点击” ,比如突然一个时间点系统慢了,要帮助管理人员清晰的展示出分析问题的逻辑!

  图片 6

 

  也许这就是所谓的 “工欲善其事,必先利其器”

 

    查询分析器二:执行

  管理篇

  除了称手的工具外,标准化管理流程也是必要的,再牛逼得工具不用也是白扯,博主之前做DBA的时候的管理流程分享给大家,很多人也问DBA都要做些什么,统一回答:

  •   日常巡检,保证系统稳定(DBA最重要的工作),经常会有客户的数据库,备份策略错误,作业失败,磁盘空间爆满等等一系列的基本问题,这些都应该通过日常巡检处理

      注:不是流于表面CPU、IO、内存,而要深入数据库各项指标,并生成报告,汇报

      周期:每周/每月

  •   新上线系统/功能的评估,现在的企业系统中经常会有新接口的上线,这些功能是否会对原有系统造成性能影响?

      注:企业对新功能的上线过程要严格把控,严格控制风险,往往问题都是日积月累不重视而产生的

      周期:每次

  •   日常性能优化,数据库是动态的过程,需要不断的优化,而不是一次优化以后就没问题了,买车还需要定期保养吧!
  •      应急问题处理,突发问题是避免不了的,但是要做到少突发,提前消灭(这也是巡检的左右),突发问题一旦产品,数据记录、问题日志就是必要的,快速处理问题、减少损失是必须的
  •        协作(开发部门、软件厂商、集成商)处理各种花式问题

      

        id    value
        1     one
        2     two
        3     three
        4     four

普遍的问题

  博主就职于一家专注数据库产品及服务的公司,见过上千家的客户场景,和各行业的人、系统打过交道,那么我们来看看普遍遇到的问题。

  

  图片 7  图片 8

  图片 9  图片 10

 

 

    现在我们进行测试,一定要注意,必须在多个会话下才可以,也就是说,需要建三个查询分析器窗口。

为什么会这样?

  我认为造成现在数据库问题频发的原因有 4 点:

  • 传统的IT建设方式、管理方式导致了今天的问题

 

    传统的建设方式:一大堆厂商的产品简单堆叠、松散拼凑。
    传统的管理方式:用户的运维人员+一大堆厂商。

 

  • 缺乏专业规划的IT架构,缺乏稳定性,增加管理复杂性

    架构缺乏规划和合理化设计,借助一大堆厂商提供的分散的单机、双机、备份一体机、虚拟化、超融合等技术的简单堆叠,参见 :如何规划、建设你的数据库架构

  • 传统的数据库管理方式无法满足今天的业务要求

  图片 11

 

 

  • 高速的业务增长导致数据平台面临巨大挑战  

  今天,业务高度依赖IT,IT的重要程度。。。
  今天,IT系统的使用者、数据量的规模一直在快速增长,且体量空前的大;

    查询分析器三:执行

细化管理

  架构层面不再赘述,如何可视化管理? 如何制定管理制度?如何快速准确消灭问题?如何轻松、简单?

       SELECT * FROM test_main(NOLOCK)

愿景——大逻辑

  说到数据库管理,有合理规划的架构必然是前提,架构是基础,在稳定的基础上配备合理的管理手段,管理制度,在上层要有及时的服务(很多企业没有DBA、没有懂得人也许这是最大的问题)

  图片 12

 

       SELECT * FROM dbo.test_main

总结

 

  大多数企业存在这样的问题:我们没DBA,我们只对业务精通,对程序了解,但数据库我只懂一点

  数据库指标多而杂,出现问题不知道怎么排查

  因为错过问题出现的时间点,问题原因无法得知,问题无法解决

  长期“头疼医头”的“救火”运维留下了病根

  巡检?啥是巡检?根本没做过

  总来说,数据库管理要有明确的规划,如何构建平稳的架构,如何有一套轻松、简单的管理方法,如何借助专业的工具、公司或人来管理。

  也许很简单

  早发现早治疗——预防机制

  当场发现及时治疗——实时机制

  彻底治疗而非缓解——全面、重视

 

--------------博客地址-----------------------------------------------------------------------------

原文地址: 

如有转载请保留原文地址! 

 

 ----------------------------------------------------------------------------------------------------

注:此文章为原创,欢迎转载,请在文章页面明显位置给出此文链接!
若您觉得这篇文章还不错请点击下右下角的推荐,非常感谢!

 

       一行受影响   

  专业服务篇

   数据库是整个IT系统的最底层,而漏斗形的IT结构让数据库成为整个IT的瓶颈,在没有DBA的企业中对数据库的管理更为重要,常见的管理一般只有定期的巡检,软件厂商、集成商等等,而且是简单的巡检,这样对隐患的排查极其弱,无法起到该有的效果,而在数据库的专业服务中,博主认为应该做到下述方面:

  

  1.   定期的深度、有效巡检
  2.   通过专业管理工具产品让多人协作、及时分析、高效解决
  3.   对多系统趋势分析,何时瓶颈
  4.   根据压力、业务如何系统的整合、拆分,对基础架构进行不断升级
  5.        在问题发生前解决而非在发生时救火

 

  服务中也许只有三点:及时、专业、懂得客户

  

  

本文由澳门新葡亰手机版发布于数据库,转载请注明出处:数据库的日常管理经验浅谈,到底是什么意思

上一篇:server安装连接,Mysql占用内存过高的优化过程 下一篇:锁与事务拨云见日,数据的增删改
猜你喜欢
热门排行
精彩图文