升级的主要操作在以下几步:
1、将SQL Server 2000 中的你要升迁的数据库做分离操作,复制出每个数据库的两个文件(一般一个MDF、一个LDF,不清楚的话,去查看每个数据库的属性)。
2、安装SQL Server 2008 R2。如果原数据库非常重要,请用新的计算机服务器进行操作,不要在原来的服务器上操作。
3、在SQL Server 2008 R2上进行附加操作,将复制出的数据库文件附加进去,工作即告完成。
如果你正在负责一个基于SQL Server的项目,或者你刚刚接触SQL Server,你都有可能要面临一些数据库性能的问题,这篇文章会为你提供一些有用的指导(其中大多数也可以用于其它的DBMS)。
在这里,我不打算介绍使用SQL Server的窍门,也不能提供一个包治百病的方案,我所做的是总结一些经验----关于如何形成一个好的设计。 这些经验来自我过去几年中经受的教训,一直来,我看到许多同样的设计错误被一次又一次的重复。
你了解你用的工具吗?不要轻视这一点,这是我在这篇文章中讲述的最关键的一条。也许你也看到有很多的SQL Server程序员没有掌握全部的T-SQL命令和SQL Server提供的那些有用的工具。
“什么?我要浪费一个月的时间来学习那些我永远也不会用到的SQL命令???”,你也许会这样说。对的,你不需要这样做。
但是你应该用一个周末浏览所有的T-SQL命令。在这里,你的任务是了解,将来,当你设计一个查询时,你会记起来:“对了,这里有一个命令可以完全实现我需要的功能”,于是,到MSDN查看这个命令的确切语法。
不要使用游标让我再重复一遍:不要使用游标。如果你想破坏整个系统的性能的话,它们倒是你最有效的首选办法。
大多数的初学者都使用游标,而没有意识到它们对性能造成的影响。它们占用内存,还用它们那些不可思议的方式锁定表,另外,它们简直就像蜗牛。
而最糟糕的是,它们可以使你的DBA所能做的一切性能优化等于没做。 不知你是否知道每执行一次FETCH就等于执行一次SELECT命令?这意味着如果你的游标有10000条记录,它将执行10000次SELECT!如果你使用一组SELECT、UPDATE或者DELETE来完成相应的工作,那将有效率的多。
初学者一般认为使用游标是一种比较熟悉和舒适的编程方式,可很不幸,这会导致糟糕的性能。 显然,SQL的总体目的是你要实现什么,而不是怎样实现。
我曾经用T-SQL重写了一个基于游标的存储过程,那个表只有100,000条记录,原来的存储过程用了40分钟才执行完毕,而新的存储过程只用了10秒钟。在这里,我想你应该可以看到一个不称职的程序员究竟在干了什么!!!我们可以写一个小程序来取得和处理数据并且更新数据库,这样做有时会更有效。
记住:对于循环,T-SQL无能为力。
CTP1已经可以下载了。
感觉这次数据库引擎确实有了不少的增强,之前很多人抱怨MS只重视BI不重视数据库引擎。一),Hekaton支持OLTP的in-memory 数据库引擎,据我了解,Hekaton的storage engine处理事务的方式跟传统的引擎有极大的区别,据微软称,客户使用之后,在不改动代码/极小改动的情况下,性能提升了10多倍。
但据国内一些MVP反应,他们使用内部版本的测试情况看来,性能没有提升的那么多。为啥Hekaton那么快?因为跟传统数据库主要有如下特点,1,Hekaton采用optimistic multiversion concurrency control (MVCC)机制,也就是采用Hekaton的事务不再需要LOCK/latch,号称无blocking(根据我观察,blocking还是有的,比如说在conflict检查的时候,但是没有了LOCK/latch,blocking肯定大大减少),无deadlock。
2,Hekaton处理的数据预先全部存储在内存中,所以避免了 physical io.3,Transaction Logging事务跟传统数据库引擎又很大的区别。传统数据库只能顺序写日志,而Hekaton可以并行写多个日志流了!,并且不使用write-ahead logging ,Hekaton何时做logging?答案是只有在验证事务可以成功提交(很拗口吧,何为验证事务可以成功提交?这是MVCC概念,有空详细讲)的情况下才开始做logging,同事Hekaton没有UNDO的概念,为啥没有UNDO,因为它没有写脏页的概念。
4,会将T-SQL编译为native code,据微软测试,有多倍的性能提升。所以个人感觉假如你的系统有上面这些瓶颈,比如LOCK/latch,Transaction Logging的写等问题,那你的提升是很明显的。
二)resource governor已经支持对IO 控制。三)Buffer pool 对SSD的利用大大的增加了性能(这个不是平时说简单的替换硬盘是SSD,不过详细的我也没有研究过:-))四)Query-processing方面的重新设计。
Cardinality Estimator的算法已经重写了,更加准确的cardinality estimates.五)ColumnStore Index已经现在可更新了不过这个更多应该引用在BI方面。
查询速度慢的原因很多,常见如下几种:
1、没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷)
2、I/O吞吐量小,形成了瓶颈效应。
3、没有创建计算列导致查询不优化。
4、内存不足
5、网络速度慢
6、查询出的数据量过大(可以采用多次查询,其他的方法降低数据量)
7、锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷)
8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。
9、返回了不必要的行和列
10、查询语句不好,没有优化
可以通过如下方法来优化查询:
1、把数据、日志、索引放到不同的I/O设备上,数据库增加读取速度,以前可以将Tempdb应放在RAID0上,SQL2000不在支持。数据量(尺寸)越大,提高I/O越重要.
2、纵向、横向分割表,减少表的尺寸(sp_spaceuse)
3、升级硬件
4、根据查询条件,建立索引,优化索引、优化访问方式,限制结果集的数据量。注意填充因子要适当(最好是使用默认值0)。索引应该尽量小,使用字节数小的列建索引好(参照索引的创建),不要对有限的几个值的字段建单一索引如性别字段
声明:本网站尊重并保护知识产权,根据《信息网络传播权保护条例》,如果我们转载的作品侵犯了您的权利,请在一个月内通知我们,我们会及时删除。
蜀ICP备2020033479号-4 Copyright © 2016 学习鸟. 页面生成时间:3.645秒