注册
 找回密码
 注册
江西广告网
查看: 254|回复: 0
打印 上一主题 下一主题

SQL Server实用经验技巧集(2)

[复制链接]

该用户从未签到

1
跳转到指定楼层
发表于 2009-1-15 08:31:59 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有帐号?注册

x
  删除数据库中重复数据的几个方法   数据库的使用过程中由于程序方面的问题有时候会碰到重复数据,重复数据导致了数据库部分设置不能正确设置……      方法一   declare @max integer,@id integer   declare cur_rows cursor local for select 主字段,count(*) from 表名 group by 主字段 having count(*) > 1   open cur_rows   fetch cur_rows into @id,@max   while @@fetch_status=0   begin   select @max = @max -1   set rowcount @max   delete from 表名 where 主字段 = @id   fetch cur_rows into @id,@max   end   close cur_rows   set rowcount 0      方法二   有两个意义上的重复记录,一是完全重复的记录,也即所有字段均重复的记录,二是部分关键字段重复的记录,比如Name字段重复,而其他字段不一定重复或都重复可以忽略。      1、对于第一种重复,比较容易解决,使用      select distinct * from tableName      就可以得到无重复记录的结果集。      如果该表需要删除重复的记录(重复记录保留1条),可以按以下方法删除      select distinct * into #Tmp from tableName   drop table tableName   select * into tableName from #Tmp   drop table #Tmp      发生这种重复的原因是表设计不周产生的,增加唯一索引列即可解决。      2、这类重复问题通常要求保留重复记录中的第一条记录,操作方法如下   假设有重复的字段为Name,Address,要求得到这两个字段唯一的结果集      select identity(int,1,1) as autoID, * into #Tmp from tableName   select min(autoID) as autoID into #Tmp2 from #Tmp group by Name,autoID   select * from #Tmp where autoID in(select autoID from #tmp2)      最后一个select即得到了Name,Address不重复的结果集(但多了一个autoID字段,实际写时可以写在select子句中省去此列)      更改数据库中表的所属用户的两个方法   大家可能会经常碰到一个数据库备份还原到另外一台机器结果导致所有的表都不能打开了,原因是建表的时候采用了当时的数据库用户……      --更改某个表   exec sp_changeobjectowner 'tablename','dbo'      --存储更改全部表   CREATE PROCEDURE dbo.User_ChangeObjectOwnerBatch   @OldOwner as NVARCHAR(128),   @NewOwner as NVARCHAR(128)   AS      DECLARE @Name  as NVARCHAR(128)   DECLARE @Owner as NVARCHAR(128)   DECLARE @OwnerName as NVARCHAR(128)      DECLARE curObject CURSOR FOR   select 'Name'  = name,   'Owner'  = user_name(uid)   from sysobjects   where user_name(uid)=@OldOwner   order by name      OPEN curObject   FETCH NEXT FROM curObject INTO @Name, @Owner   WHILE(@@FETCH_STATUS=0)   BEGIN   if @Owner=@OldOwner   begin   set @OwnerName = @OldOwner '.' rtrim(@Name)   exec sp_changeobjectowner @OwnerName, @NewOwner   end   -- select @name,@NewOwner,@OldOwner      FETCH NEXT FROM curObject INTO @Name, @Owner   END      close curObject   deallocate curObject      GO      SQL SERVER中直接循环写入数据   没什么好说的了,大家自己看,有时候有点用处      declare @i int   set @i=1   while @i<30   begin   insert into test (userid) values(@i)   set @i=@i 1   end      无数据库日志文件恢复数据库方法两则   数据库日志文件的误删或别的原因引起数据库日志的损坏      方法一   1.新建一个同名的数据库      2.再停掉sql server(注意不要分离数据库)      3.用原数据库的数据文件覆盖掉这个新建的数据库      4.再重启sql server      5.此时打开企业管理器时会出现置疑,先不管,执行下面的语句(注意修改其中的数据库名)      6.完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用   数据库的脚本创建一个新的数据库,并将数据导进去就行了.      USE MASTER   GO      SP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE   GO      UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的数据库名'   Go      sp_dboption '置疑的数据库名', 'single user', 'true'   Go      DBCC CHECKDB('置疑的数据库名')   Go      update sysdatabases set status =28 where name='置疑的数据库名'   Go      sp_configure 'allow updates', 0 reconfigure with override   Go      sp_dboption '置疑的数据库名', 'single user', 'false'      方法二   事情的起因   昨天,系统管理员告诉我,我们一个内部应用数据库所在的磁盘空间不足了。我注意到数据库事件日志文件XXX_Data.ldf文件已经增长到了3GB,于是我决意缩小这个日志文件。经过收缩数据库等操作未果后,我犯了一个自进入行业以来的最大最愚蠢的错误:竟然误删除了这个日志文件!后来我看到所有论及数据库恢复的文章上都说道:“无论如何都要保证数据库日志文件存在,它至关重要”,甚至微软甚至有一篇KB文章讲如何只靠日志文件恢复数据库的。我真是不知道我那时候是怎么想的?!      这下子坏了!这个数据库连不上了,企业管理器在它的旁边写着“(置疑)”。而且最要命的,这个数据库从来没有备份了。我唯一找得到的是迁移半年前的另外一个数据库服务器,应用倒是能用了,但是少了许多记录、表和存储过程。真希望这只是一场噩梦!      没有效果的恢复步骤   附加数据库   _Rambo讲过被删除日志文件中不存在活动日志时,可以这么做来恢复:      1,分离被置疑的数据库,可以使用sp_detach_db   2,附加数据库,可以使用sp_attach_single_file_db      但是,很遗憾,执行之后,SQL Server质疑数据文件和日志文件不符,所以无法附加数据库数据文件。      DTS数据导出   不行,无法读取XXX数据库,DTS Wizard报告说“初始化上下文发生错误”。      紧急模式   怡红公子讲过没有日志用于恢复时,可以这么做:      1,把数据库设置为emergency mode      2,重新建立一个log文件      3,把SQL Server 重新启动一下      4,把应用数据库设置成单用户模式      5,做DBCC CHECKDB      6,如果没有什么大问题就可以把数据库状态改回去了,记得别忘了把系统表的修改选项关掉      我实践了一下,把应用数据库的数据文件移走,重新建立一个同名的数据库XXX,然后停掉SQL服务,把原来的数据文件再覆盖回来。之后,按照怡红公子的步骤走。      但是,也很遗憾,除了第2步之外,其他步骤执行非常成功。可惜,重启SQL Server之后,这个应用数据库仍然是置疑!      不过,让我欣慰的是,这么做之后,倒是能够Select数据了,让我大出一口气。只不过,组件使用数据库时,报告说:“发生错误:-2147467259,未能在数据库 'XXX' 中运行 BEGIN TRANSACTION,因为该数据库处于回避恢复模式。”      最终成功恢复的全部步骤   设置数据库为紧急模式   停掉SQL Server服务;      把应用数据库的数据文件XXX_Data.mdf移走;      重新建立一个同名的数据库XXX;      停掉SQL服务;      把原来的数据文件再覆盖回来;      运行以下语句,把该数据库设置为紧急模式;      运行“Use Master      Go      sp_configure 'allow updates', 1      reconfigure with override      Go”      执行结果:      DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。      已将配置选项 'allow updates' 从 0 改为 1。请运行 RECONFIGURE 语句以安装。      接着运行“update sysdatabases set status = 32768 where name = 'XXX'”      执行结果:      (所影响的行数为 1 行)      重启SQL Server服务;      运行以下语句,把应用数据库设置为Single User模式;      运行“sp_dboption 'XXX', 'single user', 'true'”      执行结果:      命令已成功完成。      ü     做DBCC CHECKDB;      运行“DBCC CHECKDB('XXX')”      执行结果:      'XXX' 的 DBCC 结果。      'sysobjects' 的 DBCC 结果。      对象 'sysobjects' 有 273 行,这些行位于 5 页中。      'sysindexes' 的 DBCC 结果。      对象 'sysindexes' 有 202 行,这些行位于 7 页中。      'syscolumns' 的 DBCC 结果。      ………       <
您需要登录后才可以回帖 登录 | 注册

本版积分规则

快速回复 返回顶部 返回列表