深刻Mysql字符集設置[精髓聯合]。本站提示廣大學習愛好者：（深刻Mysql字符集設置[精髓聯合]）文章只能為提供參考，不一定能成為您想要的結果。以下是深刻Mysql字符集設置[精髓聯合]正文
包含裝置時提醒有掛起的操作、壓縮數據庫、緊縮數據庫、轉移數據庫給新用戶以已存在用戶權限、檢討備份集、修單數據庫等
（一）掛起操作
在裝置Sql或sp補釘的時刻體系提醒之前有掛起的裝置操作，請求重啟，這裡常常重啟無用，處理方法：
到HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
刪除PendingFileRenameOperations
（二）壓縮數據庫
--重建索引
DBCC REINDEX
DBCC INDEXDEFRAG
--壓縮數據和日記
DBCC SHRINKDB
DBCC SHRINKFILE
（三）緊縮數據庫
dbcc shrinkdatabase(dbname)
（四）轉移數據庫給新用戶以已存在用戶權限
exec sp_change_users_login 'update_one','newname','oldname'
go
（五）檢討備份集
RESTORE VERIFYONLY from disk='E:\dvbbs.bak'
（六）修單數據庫
ALTER DATABASE [dvbbs] SET SINGLE_USER
GO
DBCC CHECKDB('dvbbs',repair_allow_data_loss) WITH TABLOCK
GO
ALTER DATABASE [dvbbs] SET MULTI_USER
GO
--CHECKDB 有3個參數:
--REPAIR_ALLOW_DATA_LOSS
-- 履行由 REPAIR_REBUILD 完成的一切修復，包含對行和頁停止分派和撤消分派以糾正分派毛病、構造行或頁的毛病，和刪除已破壞的文本對象。這些修復能夠會招致一些數據喪失。修復操作可以在用戶事務下完成以許可用戶回滾所做的更改。假如回滾修復，則數據庫仍會含有毛病，應當從備份停止恢復。假如因為所供給修復品級的原因漏掉某個毛病的修復，則將漏掉任何取決於該修復的修復。修復完成後，備份數據庫。
--REPAIR_FAST 停止小的、不耗時的修復操作，如修復非集合索引中的附加鍵。這些修復可以很快完成，而且不會有喪失數據的風險。
--REPAIR_REBUILD 履行由 REPAIR_FAST 完成的一切修復，包含須要較長時光的修復（如重建索引）。履行這些修復時不會有喪失數據的風險。
--DBCC CHECKDB('dvbbs') with NO_INFOMSGS,PHYSICAL_ONLY
SQL SERVER日記消除的兩種辦法
在應用進程中年夜家常常碰著數據庫日記異常年夜的情形，在這裡引見了兩種處置辦法……
辦法一
普通情形下，SQL數據庫的壓縮其實不能很年夜水平上減小數據庫年夜小，其重要感化是壓縮日記年夜小，應該按期停止此操作以避免數據庫日記過年夜
1、設置數據庫形式為簡略形式：翻開SQL企業治理器，在掌握台根目次中順次點開Microsoft SQL Server-->SQL Server組-->雙擊翻開你的辦事器-->雙擊翻開數據庫目次-->選擇你的數據庫稱號（如服裝論壇t.vhao.net數據庫Forum）-->然後點擊右鍵選擇屬性-->選擇選項-->在毛病復原的形式當選擇“簡略”，然後按肯定保留
2、在以後數據庫上點右鍵，看一切義務中的壓縮數據庫，普通外面的默許設置不消調劑，直接點肯定
3、壓縮數據庫完成後，建議將您的數據庫屬性從新設置為尺度形式，操作辦法同第一點，由於日記在一些異常情形下常常是恢單數據庫的主要根據
辦法二
SET NOCOUNT ON
DECLARE @LogicalFileName sysname,
@MaxMinutes INT,
@NewSize INT
USE tablename -- 要操作的數據庫名
SELECT @LogicalFileName = 'tablename_log', -- 日記文件名
@MaxMinutes = 10, -- Limit on time allowed to wrap log.
@NewSize = 1 -- 你想設定的日記文件的年夜小(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
刪除數據庫中反復數據的幾個辦法
數據庫的應用進程中因為法式方面的成績有時刻會碰著反復數據，反復數據招致了數據庫部門設置不克不及准確設置……
辦法一
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'
Go
辦法二
工作的原由
昨天，體系治理員告知我，我們一個外部運用數據庫地點的磁盤空間缺乏了。我留意到數據庫事宜日記文件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 成果。
………
以後1/2頁 12下一頁浏覽全文
