在使用和创建数据库索引中经常会碰到一些问题，在这里可以采用一些另类的方法解决…
--第一步：查看是否需要维护，查看扫描密度/Scan Density是否为100%
declare @table_id int
set @table_id=object_id('表名')
dbcc showcontig(@table_id)
--第二步:重构表索引
dbcc dbreindex('表名',pk_索引名,100)
--重做第一步，如发现扫描密度/Scan Density还是小于100%则重构表的所有索引
--杨铮：并不一定能达100%。
dbcc dbreindex('表名','',100)
五、数据的转移（新建数据库或转移服务器）
一般情况下，最好使用备份和还原操作来进行转移数据，在特殊情况下，可以用导入导出的方式进行转移，这里介绍的就是导入导出方式，导入导出方式转移数据一个作用就是可以在收缩数据库无效的情况下用来减小（收缩）数据库的大小，本操作默认为您对SQL的操作有一定的了解，如果对其中的部分操作不理解，可以咨询动网相关人员或者查询网上资料
1、将原数据库的所有表、存储过程导出成一个SQL文件，导出的时候注意在选项中选择编写索引脚本和编写主键、外键、默认值和检查约束脚本选项
2、新建数据库，对新建数据库执行第一步中所建立的SQL文件
3、用SQL的导入导出方式，对新数据库导入原数据库中的所有表内容
利用数据库日志恢复数据到时间点的操作
由于不正常的数据丢失，而又不想使用备份数据还原，只要原来有备份且当前日志保存完好，可以采用这个方法试试，说不定可挽回损失……
1，如果误操作之前存在一个全库备份（或已有多个差异备份或增量备份），首先要做的事就是进
进行一次日志备份（如果为了不让日志文件变大而置trunc. log on chkpt.选项为1那你就死翘了）
backup log dbName to disk='fileName'
2，恢复一个全库备份，注意需要使用with norecovery，如果还有其他差异或增量备份，则逐个恢
复
restore database dbName from disk='fileName' with norecovery
3，恢复最后一个日志备份即刚做的日志备份，指定恢复时间点到误操作之前的时刻
restore log dbName from disk='fileName'
with stopat='date_time'
以上这些操作都可以在SQL SERVER企业管理器里完成，难度不大。。。
当然，如果误操作是一些不记日志的操作比如truncate table，select into等操作，那么是无法利
用上述方法来恢复数据的...
SQL Server2000数据库文件损坏时如何恢复
出现这样的问题是比较严重的了，能否修复只能看你的运气……
SQL Server2000中，如果数据库文件（非系统数据库文件）遇到错误的时候，仅适用于非master,msdb的数据库。
说明如下：
1 建一个测试数据库test(数据库类型为完全)
2 建一个表，插入点记录
create table a(c1 varchar(2))
go
insert into a values('aa')
go
insert into a values('bb')
go
3 作完全备份，到文件test_1.bak
4 在作一点修改
insert into a values('cc')
go
create table b(c1 int)
go
insert into b values(1)
go
insert into b values(2)
go
5 shutdown 数据库服务器
6 用ultraedit编辑数据库文件test_data.mdf,随便修改点字节内容,相当于数据库遭到致命的损坏。
7 启动数据库，并且运行企业管理器，点开数据库，看到test变成灰色，而且显示置疑。
8 运行isql -SLocalhost -Usa -P
1> backup log test TO DISK='D:Program FilesMicrosoft SQL ServerMSSQLBACKUP
est_2.bak' WITH NO_TRUNCATE
2>go
已处理 2 页，这些页属于数据库 'test' 的文件 'TEST_Log'（位于文件 1 上）。
BACKUP LOG 操作成功地处理了 2 页，花费了 0.111 秒（0.087 MB/秒）。
9 进行恢复最老的完全备份
1> RESTORE DATABASE test FROM DISK='D:Program FilesMicrosoft SQL ServerMSSQL
BACKUP est_1.bak' WITH NORECOVERY
2> go
已处理 96 页，这些页属于数据库 'test' 的文件 'TEST_Data'（位于文件 1 上）。
已处理 1 页，这些页属于数据库 'test' 的文件 'TEST_Log'（位于文件 1 上）。
RESTORE DATABASE 操作成功地处理了 97 页，花费了 0.107 秒（7.368 MB/秒）。
10 恢复最近的日志
1> RESTORE LOG test FROM DISK='D:Program FilesMicrosoft SQL ServerMSSQLBACKU
P est_2.bak' WITH RECOVERY
2> go
已处理 2 页，这些页属于数据库 'test' 的文件 'TEST_Log'（位于文件 1 上）。
RESTORE LOG 操作成功地处理了 2 页，花费了 0.056 秒（0.173 MB/秒）。
存储过程编写经验和优化措施
经验之谈，看看……
一、适合读者对象：数据库开发程序员，数据库的数据量很多，涉及到对SP（存储过程）的优化的项目开发人员，对数据库有浓厚兴趣的人。
二、介绍：在数据库的开发过程中，经常会遇到复杂的业务逻辑和对数据库的操作，这个时候就会用SP来封装数据库操作。如果项目的SP较多，书写又没有一定的规范，将会影响以后的系统维护困难和大SP逻辑的难以理解，另外如果数据库的数据量大或者项目对SP的性能要求很，就会遇到优化的问题，否则速度有可能很慢，经过亲身经验，一个经过优化过的SP要比一个性能差的SP的效率甚至高几百倍。
三、内容：
1、开发人员如果用到其他库的Table或View，务必在当前库中建立View来实现跨库操作，最好不要直接使用“databse.dbo.table_name”，因为sp_depends不能显示出该SP所使用的跨库table或view，不方便校验。
2、开发人员在提交SP前，必须已经使用set showplan on分析过查询计划，做过自身的查询优化检查。
3、高程序运行效率，优化应用程序，在SP编写过程中应该注意以下几点：
a)SQL的使用规范：
i. 尽量避免大事务操作，慎用holdlock子句，提高系统并发能力。
ii. 尽量避免反复访问同一张或几张表，尤其是数据量较大的表，可以考虑先根据条件提取数据到临时表中，然后再做连接。
iii. 尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该改写；如果使用了游标，就要尽量避免在游标循环中再进行表连接的操作。
iv. 注意where字句写法，必须考虑语句顺序，应该根据索引顺序、范围大小来确定条件子句的前后顺序，尽可能的让字段顺序与索引顺序相一致，范围从大到小。
v. 不要在where子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
vi. 尽量使用exists代替select count(1)来判断是否存在记录，count函数只有在统计表中所有行数时使用，而且count(1)比count(*)更有效率。
vii. 尽量使用“>=”，不要使用“>”。
viii. 注意一些or子句和union子句之间的替换
ix. 注意表之间连接的数据类型，避免不同类型数据之间的连接。
x. 注意存储过程中参数和数据类型的关系。
xi. 注意insert、update操作的数据量，防止与其他应用冲突。如果数据量超过200个数据页面（400k），那么系统将会进行锁升级，页级锁会升级成表级锁。
b)索引的使用规范：
i. 索引的创建要与应用结合考虑，建议大的OLTP表不要超过6个索引。
ii. 尽可能的使用索引字段作为查询条件，尤其是聚簇索引，必要时可以通过index index_name来强制指定索引
iii. 避免对大表查询时进行table scan，必要时考虑新建索引。
iv. 在使用索引字段作为条件时，如果该索引是联合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用。
v. 要注意索引的维护，周期性重建索引，重新编译存储过程。
c)tempdb的使用规范：
i. 尽量避免使用distinct、order by、group by、having、join、cumpute，因为这些语句会加重tempdb的负担。
ii. 避免频繁创建和删除临时表，减少系统表资源的消耗。
iii. 在新建临时表时，如果一次性插入数据量很大，那么可以使用select into代替create table，避免log，提高速度；如果数据量不大，为了缓和系统表的资源，建议先create table，然后insert。
iv. 如果临时表的数据量较大，需要建立索引，那么应该将创建临时表和建立索引的过程捊
最新评论