包括安裝時(shí)提示有掛起的操作、收縮數(shù)據(jù)庫(kù)、壓縮數(shù)據(jù)庫(kù)、轉(zhuǎn)移數(shù)據(jù)庫(kù)給新用戶以已存在用戶權(quán)限、檢查備份集、修復(fù)數(shù)據(jù)庫(kù)等 (一)掛起操作 在安裝Sql或sp補(bǔ)丁的時(shí)候系統(tǒng)提示之前有掛起的安裝操作,要求重啟,這里往往重啟無用,解決辦法: 到HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Session Manager 刪除PendingFileRenameOperations (二)收縮數(shù)據(jù)庫(kù) --重建索引 DBCC REINDEX DBCC INDEXDEFRAG --收縮數(shù)據(jù)和日志 DBCC SHRINKDB DBCC SHRINKFILE (三)壓縮數(shù)據(jù)庫(kù) dbcc shrinkdatabase(dbname) (四)轉(zhuǎn)移數(shù)據(jù)庫(kù)給新用戶以已存在用戶權(quán)限 exec sp_change_users_login 'update_one','newname','oldname' go (五)檢查備份集 RESTORE VERIFYONLY from disk='E:/dvbbs.bak' (六)修復(fù)數(shù)據(jù)庫(kù) ALTER DATABASE [dvbbs] SET SINGLE_USER GO DBCC CHECKDB('dvbbs',repair_allow_data_loss) WITH TABLOCK GO ALTER DATABASE [dvbbs] SET MULTI_USER GO
SET NOCOUNT ON DECLARE @LogicalFileName sysname, @MaxMinutes INT, @NewSize INT
USE tablename -- 要操作的數(shù)據(jù)庫(kù)名 SELECT @LogicalFileName = 'tablename_log', -- 日志文件名 @MaxMinutes = 10, -- Limit on time allowed to wrap log. @NewSize = 1 -- 你想設(shè)定的日志文件的大小(M) -- Setup / initialize DECLARE @OriginalSize int SELECT @OriginalSize = size FROM sysfiles WHERE name = @LogicalFileName SELECT 'Original Size of ' + db_name() + ' LOG is ' + CONVERT(VARCHAR(30),@OriginalSize) + ' 8K pages or ' + CONVERT(VARCHAR(30),(@OriginalSize*8/1024)) + 'MB' FROM sysfiles WHERE name = @LogicalFileName CREATE TABLE DummyTrans (DummyColumn char (8000) not null)
DECLARE @Counter INT, @StartTime DATETIME, @TruncLog VARCHAR(255) SELECT @StartTime = GETDATE(), @TruncLog = 'BACKUP LOG ' + db_name() + ' WITH TRUNCATE_ONLY' DBCC SHRINKFILE (@LogicalFileName, @NewSize) EXEC (@TruncLog) -- Wrap the log if necessary. WHILE @MaxMinutes > DATEDIFF (mi, @StartTime, GETDATE()) -- time has not expired AND @OriginalSize = (SELECT size FROM sysfiles WHERE name = @LogicalFileName) AND (@OriginalSize * 8 /1024) > @NewSize BEGIN -- Outer loop. SELECT @Counter = 0 WHILE ((@Counter < @OriginalSize / 16) AND (@Counter < 50000)) BEGIN -- update INSERT DummyTrans VALUES ('Fill Log') DELETE DummyTrans SELECT @Counter = @Counter + 1 END EXEC (@TruncLog) END SELECT 'Final Size of ' + db_name() + ' LOG is ' + CONVERT(VARCHAR(30),size) + ' 8K pages or ' + CONVERT(VARCHAR(30),(size*8/1024)) + 'MB' FROM sysfiles WHERE name = @LogicalFileName DROP TABLE DummyTrans SET NOCOUNT OFF
刪除數(shù)據(jù)庫(kù)中重復(fù)數(shù)據(jù)的幾個(gè)方法 數(shù)據(jù)庫(kù)的使用過程中由于程序方面的問題有時(shí)候會(huì)碰到重復(fù)數(shù)據(jù),重復(fù)數(shù)據(jù)導(dǎo)致了數(shù)據(jù)庫(kù)部分設(shè)置不能正確設(shè)置…… 方法一 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 方法二 有兩個(gè)意義上的重復(fù)記錄,一是完全重復(fù)的記錄,也即所有字段均重復(fù)的記錄,二是部分關(guān)鍵字段重復(fù)的記錄,比如Name字段重復(fù),而其他字段不一定重復(fù)或都重復(fù)可以忽略。 1、對(duì)于第一種重復(fù),比較容易解決,使用 select distinct * from tableName 就可以得到無重復(fù)記錄的結(jié)果集。 如果該表需要?jiǎng)h除重復(fù)的記錄(重復(fù)記錄保留1條),可以按以下方法刪除 select distinct * into #Tmp from tableName drop table tableName select * into tableName from #Tmp drop table #Tmp 發(fā)生這種重復(fù)的原因是表設(shè)計(jì)不周產(chǎn)生的,增加唯一索引列即可解決。 2、這類重復(fù)問題通常要求保留重復(fù)記錄中的第一條記錄,操作方法如下 假設(shè)有重復(fù)的字段為Name,Address,要求得到這兩個(gè)字段唯一的結(jié)果集 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) 最后一個(gè)select即得到了Name,Address不重復(fù)的結(jié)果集(但多了一個(gè)autoID字段,實(shí)際寫時(shí)可以寫在select子句中省去此列)
--存儲(chǔ)更改全部表 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中直接循環(huán)寫入數(shù)據(jù) 沒什么好說的了,大家自己看,有時(shí)候有點(diǎn)用處 declare @i int set @i=1 while @i<30 begin insert into test (userid) values(@i) set @i=@i+1 end
方法一 1.新建一個(gè)同名的數(shù)據(jù)庫(kù) 2.再停掉sql server(注意不要分離數(shù)據(jù)庫(kù)) 3.用原數(shù)據(jù)庫(kù)的數(shù)據(jù)文件覆蓋掉這個(gè)新建的數(shù)據(jù)庫(kù) 4.再重啟sql server 5.此時(shí)打開企業(yè)管理器時(shí)會(huì)出現(xiàn)置疑,先不管,執(zhí)行下面的語(yǔ)句(注意修改其中的數(shù)據(jù)庫(kù)名) 6.完成后一般就可以訪問數(shù)據(jù)庫(kù)中的數(shù)據(jù)了,這時(shí),數(shù)據(jù)庫(kù)本身一般還要問題,解決辦法是,利用 數(shù)據(jù)庫(kù)的腳本創(chuàng)建一個(gè)新的數(shù)據(jù)庫(kù),并將數(shù)據(jù)導(dǎo)進(jìn)去就行了. USE MASTER GO SP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE GO UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的數(shù)據(jù)庫(kù)名' Go sp_dboption '置疑的數(shù)據(jù)庫(kù)名', 'single user', 'true' Go DBCC CHECKDB('置疑的數(shù)據(jù)庫(kù)名') Go update sysdatabases set status =28 where name='置疑的數(shù)據(jù)庫(kù)名' Go sp_configure 'allow updates', 0 reconfigure with override Go sp_dboption '置疑的數(shù)據(jù)庫(kù)名', 'single user', 'false' Go 方法二 事情的起因 昨天,系統(tǒng)管理員告訴我,我們一個(gè)內(nèi)部應(yīng)用數(shù)據(jù)庫(kù)所在的磁盤空間不足了。我注意到數(shù)據(jù)庫(kù)事件日志文件XXX_Data.ldf文件已經(jīng)增長(zhǎng)到了3GB,于是我決意縮小這個(gè)日志文件。經(jīng)過收縮數(shù)據(jù)庫(kù)等操作未果后,我犯了一個(gè)自進(jìn)入行業(yè)以來的最大最愚蠢的錯(cuò)誤:竟然誤刪除了這個(gè)日志文件!后來我看到所有論及數(shù)據(jù)庫(kù)恢復(fù)的文章上都說道:“無論如何都要保證數(shù)據(jù)庫(kù)日志文件存在,它至關(guān)重要”,甚至微軟甚至有一篇KB文章講如何只靠日志文件恢復(fù)數(shù)據(jù)庫(kù)的。我真是不知道我那時(shí)候是怎么想的?! 這下子壞了!這個(gè)數(shù)據(jù)庫(kù)連不上了,企業(yè)管理器在它的旁邊寫著“(置疑)”。而且最要命的,這個(gè)數(shù)據(jù)庫(kù)從來沒有備份了。我唯一找得到的是遷移半年前的另外一個(gè)數(shù)據(jù)庫(kù)服務(wù)器,應(yīng)用倒是能用了,但是少了許多記錄、表和存儲(chǔ)過程。真希望這只是一場(chǎng)噩夢(mèng)! 沒有效果的恢復(fù)步驟 附加數(shù)據(jù)庫(kù) _Rambo講過被刪除日志文件中不存在活動(dòng)日志時(shí),可以這么做來恢復(fù): 1,分離被置疑的數(shù)據(jù)庫(kù),可以使用sp_detach_db 2,附加數(shù)據(jù)庫(kù),可以使用sp_attach_single_file_db 但是,很遺憾,執(zhí)行之后,SQL Server質(zhì)疑數(shù)據(jù)文件和日志文件不符,所以無法附加數(shù)據(jù)庫(kù)數(shù)據(jù)文件。 DTS數(shù)據(jù)導(dǎo)出 不行,無法讀取XXX數(shù)據(jù)庫(kù),DTS Wizard報(bào)告說“初始化上下文發(fā)生錯(cuò)誤”。 緊急模式 怡紅公子講過沒有日志用于恢復(fù)時(shí),可以這么做: 1,把數(shù)據(jù)庫(kù)設(shè)置為emergency mode 2,重新建立一個(gè)log文件 3,把SQL Server 重新啟動(dòng)一下 4,把應(yīng)用數(shù)據(jù)庫(kù)設(shè)置成單用戶模式 5,做DBCC CHECKDB 6,如果沒有什么大問題就可以把數(shù)據(jù)庫(kù)狀態(tài)改回去了,記得別忘了把系統(tǒng)表的修改選項(xiàng)關(guān)掉
我實(shí)踐了一下,把應(yīng)用數(shù)據(jù)庫(kù)的數(shù)據(jù)文件移走,重新建立一個(gè)同名的數(shù)據(jù)庫(kù)XXX,然后停掉SQL服務(wù),把原來的數(shù)據(jù)文件再覆蓋回來。之后,按照怡紅公子的步驟走。 但是,也很遺憾,除了第2步之外,其他步驟執(zhí)行非常成功。可惜,重啟SQL Server之后,這個(gè)應(yīng)用數(shù)據(jù)庫(kù)仍然是置疑! 不過,讓我欣慰的是,這么做之后,倒是能夠Select數(shù)據(jù)了,讓我大出一口氣。只不過,組件使用數(shù)據(jù)庫(kù)時(shí),報(bào)告說:“發(fā)生錯(cuò)誤:-2147467259,未能在數(shù)據(jù)庫(kù) 'XXX' 中運(yùn)行 BEGIN TRANSACTION,因?yàn)樵摂?shù)據(jù)庫(kù)處于回避恢復(fù)模式。”