MSSQL网站制作之Sql2000数据的附加时堕落处置举措

支持多线程，充分利用CPU资源数据转贴：
成绩：
Sql2000数据的附加时堕落：

毛病3624
location:recovery.c:1996
express:curr->lon_length>0
spdi:51
processid:768
最初提醒附加失利

服务器:动静5105，级别16，形态4，行1
设备激活毛病。物理文件名f:databasefdzz1204_Data.ldf大概有误。

办理：
新建一同名数据库（文件名，文件组都和本来的一样），然后中断数据库服务，用本来文件交换新建的数据库文件，启动数据库，该数据库被设未suspect

然后把数据库改成告急形式：
sp_configureallow,1
reconfigurewithoverride
updatesysdatabasessetstatus=32768wherename=数据库名

把LDF文件更名，再实行
DBCCREBUILD_LOG(数据库名,E:fdzzdatabasefdzz1204_Log.LDF)

恢单数据库告急形式
updatesysdatabasessetstatus=0wherename=数据库名
实行
restoredatabase数据库名WITHRECOVERY
sp_configureallow,0
reconfigurewithoverride

然后用DBCCCHECKDB(数据库名)看看有无毛病

假如下面仍是不可，尝尝把数据库设为告急形式，应当能够看到数据了，在把数据导出到一个新的数据库

1.新建一个同名的数据库(数据文件与本来的要分歧)

2.再停失落sqlserver(注重不要分别数据库)

3.用原数据库的数据文件掩盖失落这个新建的数据库

4.再重启sqlserver

5.此时翻开企业办理器时会呈现置疑，先不论，实行上面的语句（注重修正个中的数据库名)

6.完成后一样平常就能够会见数据库中的数据了,这时候,数据库自己一样平常还要成绩,办理举措是,使用
数据库的剧本创立一个新的数据库,并将数据导出来就好了.

usemaster
go
sp_configureallow,1
reconfigurewithoverride
go
updatesysdatabasessetstatus=32768wherename=置疑数据库名

go
--先删除之前的日记文件
DBCCREBUILD_LOG(置疑数据库名,置疑数据库日记文件寄存地位)

go
updatesysdatabasessetstatus=0wherename=置疑数据库名
--实行
restoredatabaseprojectWITHRECOVERY
go
sp_configureallow,0
reconfigurewithoverride
go
DBCCCHECKDB(置疑数据库名)--看看有无毛病

或
USEMASTER
GO

SP_CONFIGUREALLOWUPDATES,1RECONFIGUREWITHOVERRIDE
GO

UPDATESYSDATABASESSETSTATUS=32768WHERENAME=置疑的数据库名
Go

sp_dboption置疑的数据库名,singleuser,true
Go

DBCCCHECKDB(置疑的数据库名)
Go

updatesysdatabasessetstatus=28wherename=置疑的数据库名
Go

sp_configureallowupdates,0reconfigurewithoverride
Go

sp_dboption置疑的数据库名,singleuser,false


出于效率方面的考虑，InnoDB数据表的数据行级锁定实际发生在它们的索引上，而不是数据表自身上。显然，数据行级锁定机制只有在有关的数据表有一个合适的索引可供锁定的时候才能发挥效力。

然后最好有实践机会，能够把实践到的和实践结合起来，其实理论思考是个非常困扰和痛苦的事情

可能有的朋友会抱怨集成的orderby，其实如果使用ranking函数,Orderby是少不了的。如果担心Orderby会影响效率，可以为orderby的字段建立聚集索引，查询计划会忽略orderby操作（因为本来就是排序的嘛）。

是要和操作系统进行Socket通讯的场景。否则建议慎重！

一个百万级别的基本信息表A，一个百万级别的详细记录表B，A中有个身份证id，B中也有身份id；先要找出A中在B的详细记录。

另一个是把SQL语句写到服务器端,就是所谓的SP(存储过程);

大家注意一点。如下面的例子：

但是随着数据量的增大，这种成本差距会逐渐减小，趋于相等。（500万数量级只相差10%左右）

SQLServer的异构移植功能个人感觉最好了。（如果对比过SQLServer的链接服务器和Oracle的透明网关的朋友会发现SQLServer的sp_addlinkedserver(openquery)异构数据库系列比Oracle真是强太多了。）