- 論壇徽章:
- 0
|
數(shù)據(jù)庫備份策略在維護系統(tǒng)數(shù)據(jù)安全起著非同小可的作用，好的備份策略應該考慮保證數(shù)據(jù)的安全，并且操作較為方便。
基本過程很簡單，如下：
1．備份到本地硬盤：
dump transaction with truncate_only
dump database … to …
dump transaction
。。。
2．當裝載數(shù)據(jù)庫和事務日志時，為防止其他用戶對數(shù)據(jù)庫的操作，須把數(shù)據(jù)庫設置為 dbo use only。
進行裝載時的順序為：
dump transaction with no_truncate
load database database_name from ...
load transaction database_name from ...
。。。
online database
也可以用until指定恢復到某個時間
使用閾值管理
可以使用閾值管理，在閾值管理中安排當超過某個閾值時自動轉儲事務日志。當超過閥值以后，SQL Serve中斷或掛起試圖寫這個日志的用戶事務。對每一個掛起的事務 向errorlog 發(fā)一條消息；然后執(zhí)行sp_thresholdaction
sp_thresholdaction用戶自己編寫
create procedure sp_thresholdaction
@dbname varchar（30）,
@segmentname varchar（30）,
as
dump transaction @dbname to "DEVICE"
print "LOG DUMP: %1! for %2! dumped", @segmentname, @dbname
其中參數(shù) ：
@dbname 為達到閥值的數(shù)據(jù)庫名；
@segmentname 為達到閥值的段名；
用戶數(shù)據(jù)庫損壞的處理
如果數(shù)據(jù)庫處于suspect狀態(tài)，無法用drop database 刪除時：
dbcc dbrepair (db_name, dropdb)
create database db_name on dev_name for load
load database db_name from dump_device
master庫損壞的處理
?使用 buildmaster -m 重建一個新的 master 數(shù)據(jù)庫；
buildmaster 建立 master 設備并在這個設備上建立 master， model， tempdb 庫。
-m 選項只重新寫 master 庫， 而不修改配置塊或初始化 master 設備。
? 以單用戶方式重啟動服務器， 如果需要的話， 則需增加轉儲設備；
? 從備份裝載 master 數(shù)據(jù)庫；
? 用 startserver 重啟 SQL Server；
? 檢查一致性： 對每一個數(shù)據(jù)庫運行 dbcc checkalloc，并對重要的表進行檢查；
但是，當我們問及sybase的技術支持是否建議使用threshold 時，他們并不積極建議這樣做，理由是自動化操作往往會出現(xiàn)一些難于預料的結果。當然，要是有那么負責的dba，天天定時手工備份，當然是再好不過了。
基本的備份操作是簡單，但是我們在實際實施備策略時，往往會考慮這樣那樣的問題，也會出現(xiàn)一些意想不到的問題，比如：
1、是整庫備份還是增量備份
2、每天什么時候備份，備份時間怎么安排
3、萬一需要恢復數(shù)據(jù)庫，當前的備份能恢復到一個什么程度
4、數(shù)據(jù)庫在恢復時可能出現(xiàn)哪些緊急情況
等等...
歡迎大家就這個主題進行一下討論，以激發(fā)出一些好的想法和經(jīng)驗，以共同增強系統(tǒng)數(shù)據(jù)的安全性！
(jazy)
*****************************************************
偶們的數(shù)據(jù)庫比較小，不需要經(jīng)常備份！
即使備份也是整庫備份！
(miniyoyo2002)
*****************************************************
有一個問題，就是一旦崩潰總面臨部分數(shù)據(jù)丟失，這在某些情況下是不能接受的。而sybase對日志的使用策略使很多管理員將日志設為截斷方式。這也不穩(wěn)當，在有復制服務器的時候，有時第二截斷點使日志始終無法清除，最后漲滿。
有一種方式是利用存儲或軟件方式形成的快照再對快照進行備份，可以并行地訪問數(shù)據(jù)，并對日志作standby方式的備份（好像需要12以上），但需要暫停對數(shù)據(jù)庫的訪問以保證完整性，雖然sybase宣稱可以不中止應用而屏蔽訪問，但不允許應用有bcp或truncate，這一點實在難以接受，也許很快就會有新的策略吧。
(丁一)
*****************************************************
我也有一點想法，那就是采取截斷日志的方式，究竟存在多大的風險？
sybase設計的是先寫日志方式，但是如果我們采取裸設備的直接存儲的方式，那么在數(shù)據(jù)庫每次chekpoint時，應該已經(jīng)將緩存中的數(shù)據(jù)寫入了磁盤中，所以，就算系統(tǒng)崩潰，丟失的數(shù)據(jù)應該只是在一個截斷點內(nèi)的交易信息，所以我覺得對于交易不是非常頻繁（每秒不超過10個的系統(tǒng)），采取截斷方式的風險不是太大。
丁一所說的：“sybase宣稱可以不中止應用而屏蔽訪問”，我發(fā)現(xiàn)在測試中即使是正在進行備份，交易還可正常進行阿？也許跟我的備份方式有關。
(jazy)
*****************************************************
假如磁盤系統(tǒng)是可靠的，截斷日志是沒有危險的，就如同我們基本可以殺掉dataserver的進程，重起sybase，會自動恢復。
但如果磁盤故障？raid并不保證安全。raid5只能壞一塊盤，raid10運氣差的話也只能壞一塊。應該說之所以要備份，多數(shù)是為了防止這種故障，可以在重建系統(tǒng)時，盡量少的丟失數(shù)據(jù)。如果我dump到磁帶上或另一物理上獨立的介質上，我就有了在這一時間點的一個0級備份。在這一點之后，如果沒有截斷日志，可以持續(xù)將日志備份。這樣丟失的數(shù)據(jù)可能是交易級的。
但即使這樣，仍有問題需要解決。如何驗證備份的介質就是完好的？會影響生產(chǎn)系統(tǒng)的性能嗎？操作繁瑣嗎？現(xiàn)在有遠程鏡像技術了，911樓都不見了，數(shù)據(jù)仍然恢復了，但代價對很多系統(tǒng)過于高昂，超過數(shù)據(jù)丟失的損失。也許備份首先要有一個定位，能接受什么樣的損失，愿意付出什么樣的代價。
(丁一)
****************************************************
數(shù)據(jù)庫備份方案應該看用戶數(shù)據(jù)的重要性！談一談我的備份方案（我的數(shù)據(jù)比命重要）。
每３０分鐘備份一次日志，定時追加備份（我為了安全備份到磁帶上，硬盤說不定哪天突然就。。。５５５５５５），每晚備份一次完整庫（磁帶上），完整庫備份完后清一次日志，
經(jīng)常檢查ｂａｃｋｕｐｓｅｒｖｅｒ日志有無錯誤，特別是備份不成功時�。�
定期在做完整庫備份前用ｄｂｃｃ檢查重要的表��！
備份磁帶的分配：２０盤磁帶，每天１盤備份完整庫、１盤備份日志（每天兩盤按天對應），保存一個星期的備份。
（續(xù)上貼）備份是很重要的，還別忘了養(yǎng)成經(jīng)常定期檢查系統(tǒng)的狀況，如：系統(tǒng)的ｍｅｓｓａｇｅ，ｍａｉｌ等。
談一次我的經(jīng)歷（想起就冤。。。５５５５）：有一次突然發(fā)現(xiàn)數(shù)據(jù)庫出問題了，需要恢復前一天的庫，結果無法恢復（５５５），因為每天備份都成功了的，所以奇怪，經(jīng)檢查（花了很長時間，專家會診（ｓｙｂａｓｅ的人）），
（續(xù)上貼）結果是服務器與陣列之間通訊不兼容的問題造成數(shù)據(jù)庫數(shù)據(jù)不能使用，結果問題已經(jīng)發(fā)生１０多天了，我還不知道，就因為ｓｙｂａｓｅ未有任何錯誤警告和日志記錄，結果錯誤警告和日志記錄只在系統(tǒng)的ｍｅｓｓａｇｅ中有硬件問題的警告，害的我花了兩個星期調整數(shù)據(jù)（命苦�。� ｓｏ 大家一定不要忘了系統(tǒng)的定期檢查啊，備份重要，系統(tǒng)好像跟重要�。�！
(hgy1999 )
*****************************************************
不知道大哥您殺了幾次dataserver進程，估計您是沒有遇到什么問題，您的手氣是夠好的，建議您以后殺dataserver進程時要三思，否則遇到大面積的表出現(xiàn)6xx，8xx錯誤，您就會后悔的。
(dangsl )
*****************************************************
決定采用的備份方案：
1、master庫 做個原始備份，有新的修改再做備份
2、生產(chǎn)庫：
數(shù)據(jù)：每天凌晨一個整庫備份
日志：每小時一個日志備份，同時清空日志
保留一周的備份，每天備份的時候，在陣列上保留最新備份的同時，將其壓縮轉備到另外的硬盤中。管理員定期完成每周的從該硬盤將備份轉移到磁帶上。
另外，在備份之前先做dbcc checkdb() ，保證備份的正確性。（雖然會影響交易�。�
(jazy)
*****************************************************
我的備份方法比較土：
一、用crontab命令定時調用shell命令備份。備份采用兩種方式，1、全庫備份：dump database to "/xxx/xxx.bk" at SYB_BKALL，SYB_BKALL是一臺專用的服務器上的備份服務器，硬盤較大，2、bcp out，同樣在那臺專用的備份服務器上定時執(zhí)行，編了一個shell腳本，把SQL SERVER、username、password、database作為參數(shù)，自動將所有表數(shù)據(jù)備份成為文件。當然檢查相應的log文件。然后集中定時倒入磁帶。
二、用crontab命令定時調用shell命令做dbcc檢查，內(nèi)容包括update statistics 表名sp_compile 表名，然后對庫作dbcc checkalloc。檢查相應的log文件。
用這種方法我每天晚上備份了12個庫，當然每個庫大小都不大最大dump備份文件才的377MB。
以下是我昨天晚上的dbcc的log文件（$DBCCDIR/log/today_dbcc.log）內(nèi)容。
02-10-30(21:40:00-->;21:40:03): dbcc BSH3_hz_ovnitdb succeed.
02-10-30(21:40:03-->;21:40:05): dbcc BSH3_xa_ovnitdb succeed.
02-10-30(21:40:05-->;21:40:06): dbcc BSH3_fz_ovnitdb succeed.
02-10-30(21:40:06-->;21:40:09): dbcc BSH3_xm_ovnitdb succeed.
02-10-30(21:40:09-->;21:40:17): dbcc BSH3_ovnitdb succeed.
02-10-30(21:40:17-->;21:40:34): dbcc ITS_MSH_itspdb succeed.
02-10-30(21:40:34-->;21:43:45): dbcc ITS_MSH_tbpdb succeed.
02-10-30(21:43:45-->;21:43:57): dbcc ITS_MSH_ibopdb succeed.
02-10-30(21:43:57-->;21:45:32): dbcc ITS_BSH3_itsbdb succeed.
02-10-30(21:45:32-->;21:46:47): dbcc MSH_ibopdb succeed.
02-10-30(21:46:47-->;21:48:12): dbcc BSH3_ibobdb succeed.
02-10-30(21:48:12-->;22:19:17): dbcc CFETSTJ1_infodb error.
今天早上我查了最后一個日志文件（$DBCCDIR/CFETSTJ1_infodb/tmpDbcc.log）的出錯信息：
Alloc page 389632 (# of extent=1 used pages=1 ref pages=1)
Msg 2540, Level 16, State 1:
Server 'CFETSTJ1', Line 1:
Table Corrupt: Page is allocated but not linked; check the following pages and
ids: allocation pg#=389888 extent id=389976 logical pg#=389980 object id on
extent=8 (object name = syslogs) indid on extent=0
Alloc page 389888 (# of extent=1 used pages=5 ref pages=1)
syslogs表的問題，關系不大，我抽空解決。
syslog錯我還不知道如何處理，我dbcc checkalloc(xxx,fix)也不行。不過好像還能用。
(jackhoo72)
*****************************************************
你在做dbcc時數(shù)據(jù)庫有訪問嗎？看你的情況是通過crontab處理的，如果不能保證沒有用戶使用，那么報syslog錯應該沒什么問題。
(chuxu )
*****************************************************
由于我的數(shù)據(jù)庫晚上都不對外用了，所以我dbcc的時候已經(jīng)置為單用戶狀態(tài)了，用sp_dboption db,"single user",true。但仍然報syslog錯，不過我這個庫不太重要，當然，如果那位大俠能指點一下非常感謝。
(jackhoo72)
*****************************************************
Error 2540
Severity Level
16
Error Message Text
Table Corrupt: Page is allocated but not linked; check the following pages and ids: allocation pg#=%ld extent id=%ld logical pg#=%ld object id on extent=%ld (object name = %S_OBJID) indid on extent=%ld
Explanation
This error occurs when dbcc checkalloc determines that a page is marked as allocated to an object but that page is not being used. There is no corruption or data loss associated with this error.
Each 2540 error means the loss of one blank data page. A few 2540 errors are no cause for concern. However, if many of these errors occur, the amount of "lost" disk space could be significant.
Note:The instructions below are for fixing 2540 errors once they have occurred. Two easy-to-use strategies exist for detecting this error sooner in the future. Refer to "Detecting Allocation Errors as Early as Possible" for information about these strategies.
Action
Occasionally dbcc checkalloc reports this error when no real error condition exists. You can either check to determine whether the error is real, or continue with this section and take action to correct it, whether or not it reflects a real allocation error.
Because the process used to discover whether or not the error is real can be time-consuming, you may want to go directly to "Error Resolution" now.
Verifying That the Error Is Real
Run dbcc checkalloc in single-user mode if you suspect the 2540 error messages are incorrect. If the error is in master, use the section "How to Start SQL Server in Single-User Mode" for instructions about how to invoke SQL Server in single-user mode. Refer to "dbcc" in the SQL Server Reference Manual for information about dbcc checkalloc.
Error Resolution
If many of these errors are occurring, it is possible to clear them all at once by using the dbcc checkalloc and dbcc checkalloc with fix option commands. Refer to "How to Fix and Prevent Allocation Errors" for information about using dbcc checkalloc.
If the text of the error message includes a real object name, not a number, then the error is on an existing object which the system catalog has correct references to, and you should continue now to "Identify Table: User or System Table".
If a number appears instead of the object name, then that object only partially exists and the error must be corrected using the procedure described in "How to Fix and Prevent Allocation Errors".
Identify Table: User or System Table
Look at the value for "object id on extent" in the error message. If it is 100 or greater, continue with "Action for User Tables". If the "object id on extent" is below 100, it is a system table and requires a different procedure as described in the section "Action for System Tables".
Action for User Tables
If the "object id on extent" in the error message is 100 or greater, follow these steps to correct the error:
1.Check the value of the "indid on extent" in the error message to determine whether it is a table (value = 0) or an index (value >; 0).
2.Run dbcc tablealloc or dbcc indexalloc, depending on whether the object named in the 2540 error message is a table or an index. Before you run the appropriate command, keep the following in mind:
- dbcc tablealloc corrects this problem on a table or an index, but if the problem is on an index, you can avoid affecting the entire table by using dbcc indexalloc. If the table is large or heavily used, it may be more practical to use dbcc indexalloc.
- These commands can correct the error only when run in the full or optimized mode, and with the nofix option not specified, the default for user tables.
- You can use the object name or object ID in the following commands where the argument "object_name" appears.
Use the command appropriate for your situation:
For Tables (index id in extent = 0)
For Indexes (0 < index id in extent < 255)
1>; dbcc tablealloc (object_name)
2>; go
1>; dbcc indexalloc (object_name,
2>; indid_on_extent)
3>; go
Refer to "dbcc" in the SQL Server Reference Manual and "Checking Database Consistency" in the System Administration Guide for information about dbcc tablealloc and dbcc indexalloc.
Action for System Tables
If the "object id on extent" in the error message is less than 100, follow these steps to correct the error:
1.Put the affected database in single-user mode:
- If the database is master, use the procedure in "How to Start SQL Server in Single-User Mode", and then go to step 2.
- If the database is not master, use the sp_dboption stored procedure to put the affected database in single-user mode:
1>; use master
2>; go
1>; sp_dboption database_name, single, true
2>; go
1>; use database_name
2>; go
1>; checkpoint
2>; go
2.Check the value of the "indid on extent" in the error message to determine whether it is a table (value is 0) or an index (value is greater than 0).
3.Run dbcc tablealloc or dbcc indexalloc, depending on whether the object named in the 2540 error message is a table or an index. Then execute the appropriate command. Before you run the appropriate command, keep the following in mind:
- dbcc tablealloc corrects either a table or an index, but if the problem is on an index, you can avoid affecting the entire table by using dbcc indexalloc. If you need to minimize the amount of time the table is unavailable, it may be most practical to use dbcc indexalloc.
- These commands correct the error only when run in the full or optimized mode, with the fix option specified, because the default value is nofix on system tables.
- You can use the "object name" or "object id on extent" in the commands above where the argument object_name appears.Use the command appropriate for your situation:
For Tables (index id in extent = 0)
For Indexes (0 < index id in extent < 255)
1>; dbcc tablealloc (object_name,
2>; full, fix)
3>; go
1>; dbcc indexalloc (object_name,
2>; indid_on_extent, full, fix)
3>; go
4.Turn off single-user mode in the database:
- If the database is master, refer to "Returning SQL Server to Multiuser Mode".
- If the database is not master, use the following procedure:
1>; use master
2>; go
1>; sp_dboption database_name, single, false
2>; go
1>; use database_name
2>; go
1>; checkpoint
2>; go
Refer to "dbcc" in the SQL Server Reference Manual and "Checking Database Consistency" in the System Administration Guide for information about dbcc tablealloc and dbcc indexalloc.
Releases in Which This Error Is Raised
11.0 and later
( molin )
*****************************************************
小小感受:
增量備份是個理論概念
全備的同時最好也來個bcp數(shù)據(jù)備份,這在生產(chǎn)環(huán)境中是最實用的. bcp可做在crontab中.
(aladdin )
****************************************************
這個問題我正好前幾天遇到了，我們采用11。9，數(shù)據(jù)量大概每天存儲二十萬條左右，而且有時實時系統(tǒng)，日志空間我也分配了1G多，我沒有備份只是定期清楚，dump tran dbname with no_log ，結果后來用這個也不行了，慢了以后我只好再分配空間，最后，我把所有有關對數(shù)據(jù)庫操做的應用都停了，最后才清調日志，但這也不是辦法，用戶不大可能自己清，（我們不考慮備份），我把dump tran dbname with no_log寫在定時器里，但有時候不起作用，各位又什么更好的辦法
(我愛SYBASE)
****************************************************
各位高手，大家的討論對我很有啟發(fā)。只是我現(xiàn)在對增量備份（即僅備份日志）有些懷疑，對于一些不完全記日志的操作（select into）對數(shù)據(jù)庫的改變將不能被恢復，是否存在這個問題呢？請各位指點一下。
(joson )
****************************************************
我現(xiàn)在才有點醒悟，我們給用戶做的有幾張表數(shù)據(jù)是固定的
剩余兩張表，歷史數(shù)據(jù)表，歷史告警表是不斷變化的，如果可以允許數(shù)據(jù)庫服務停止一段時間，那我們只需要備份我們的數(shù)據(jù)表不就可以了么，還那么麻煩作這么多庫備份，日志備份
最多壞了以后重新裝了。只要重要的表數(shù)據(jù)沒丟失就可以了
(我愛SYBASE)
****************************************************
continue.... |
|
免費注冊
發(fā)表于 2003-01-16 21:26
PATH
