推薦：如何有效防止Java程序源碼被人偷窺?
Java程序的源代碼很容易被別人偷看，只要有一個反編譯器，任何人都可以分析別人的代碼。本文討論如何在不修改原有程序的情況下，通過加密技術保護源代碼。 一、為什么要加密? 對于傳統的C或

老鳥說事：Microsoft SQL Server數據庫增強版備份體驗

在歐洲，有一首流傳很廣的民諺：

因為丟失一根鐵釘，我們失去了一塊馬蹄鐵；

因為失去一塊馬蹄鐵，我們失去了一匹駿馬；

因為失去一匹駿馬，我們失去一名騎士；

因為失去一名騎士，我們輸掉了一場戰爭……

在企業的經營中，細節決定成敗，要規避一切潛在的風險，避免因為一些小的失誤而造成重大損失，在企業運營越來越依靠IT支撐的今天，企業的關鍵應用，比如財務軟件、CRM、OA、ERP等，一旦發生數據丟失，損失將非常慘重，想想財務數據的數據丟失的后果吧，工資無法正常發放；當年的財務總結沒辦法進行；盈利還是虧損無法計算；下一年的業務也無法正常開展；大客戶可能因此拂袖而去。

數據已經不再是0101這樣的二進制信息，而是人們的錢袋子，真正的真金白銀。人們應該及時做好數據備份。

中小企業最常使用的數據庫是微軟的是SQL Server，本身帶有自動備份功能，但多年來的經驗告訴我，SQL自帶的備份已經遠遠不能滿足企業業務的連續性、安全性需求了。

SQL SERVER自帶備份功能是一個簡單的入門級的備份小工具，在非常簡單的應用時，比如一兩臺SQL服務器，數據量又大，數據重要性一般的時候，SQL自帶備份功能就可以勝任了。

但是當數據重要性非常高時，企業不能夠承擔數據丟失的風險時，那么就需要尋求更加專業、更加安全可靠的數據備份解決方案。因為SQL自帶備份功能有以下不足和缺陷。經過反復的篩選和比較之后，本人找到一款在功能和性能上都能對SQL自帶備份功能帶來非常大改善的備份工具--愛數備份軟件。下面是功能比較：

備份功能之比較

大家都知道，數據庫備份有四種類型，分別應用于不同的場合，下面簡要介紹一下。

1、完全備份

這是大多數人常用的方式，它可以備份整個數據庫，包含用戶表、系統表、索引、視圖和存儲過程等所有數據庫對象。但它需要花費更多的時間和空間，所以，一般推薦一周或一月做一次完全備份。

2、事務日志備份

事務日志是一個單獨的文件，它記錄數據庫的改變，備份的時候只需要復制自上次備份以來對數據庫所做的改變，所以只需要很少的時間。為了使數據庫具有魯棒性，推薦每小時甚至更頻繁的備份事務日志。

3、差異備份

也叫增量備份。它是只備份數據庫一部分的另一種方法，它不使用事務日志，相反，它使用整個數據庫的一種新映象。它比最初的完全備份小，因為它只包含自上次完全備份以來所改變的數據庫。它的優點是存儲和恢復速度快。推薦每天做一次差異備份。

4、文件備份

數據庫可以由硬盤上的許多文件構成。如果這個數據庫非常大，并且一個晚上也不能將它備份完，那么可以使用文件備份每晚備份數據庫的一部分。由于一般情況下數據庫不會大到必須使用多個文件存儲，所以這種備份不是很常用。

如果你只做全備份，那么受限于全備份的大小和備份時間，不可能常做。而且只有全備份，不能將數據庫恢復至某個時間點。所以，我們需要全備份 日志備份。比如每天一個全備份，每隔1小時或若干分鐘一個日志備份。

說到差異備份，因為微軟的差異備份記錄的是上一次全備份以來發生的變化，所以，如果數據庫的改動很頻繁的話，沒過多久，差異備份就會和全備份的大小接近，因此這種情況下就不合適了。因此，全備份 日志備份的方案適合絕大多數的用戶。

備份文件傳送至備機后，就可以高枕無憂了嗎？不。作為DBA還需要檢查備機上的備份文件是否能將數據庫恢復至最新，如果采用日志備份，會不會因為丟失某一個日志備份文件而導致數據庫不能恢復至最新？如何檢查日志備份文件之間存在斷檔？

數據庫在備份的時候，并不會檢查數據頁面的完整性，如果數據頁壞了，備份作業仍會執行，而且不會報錯，等到你發現數據頁有錯誤的時候，你也很可能已經因為磁盤空間不足，而刪除了早期的備份，而此時剩下的那些備份可能都是包含損壞的數據頁，如果損壞的數據頁是某個表的表頭的話，那這個表你就再也沒辦法恢復了。

愛數的解決方案：

自動將完全備份和日志備份完整有機結合起來，并自動將日志文件組織一個文件包里，不用擔心丟失和遭病毒破壞，不用擔心日志斷檔。

高級的循環備份功能，可以自動設置多久執行一次全備份，以及每個全備份下面帶多少個增量備份點。比如：每周執行一次完整備份，保留三個完全備份；每個全備份下面帶有30個增量備份，這樣，既保證了數據庫備份的完整性，又保證了數據備份的速度和效率。

恢復功能之比較

SQL自帶備份：

為了將數據庫盡可能的恢復到最新，你可能會每隔10分鐘（甚至1分鐘）執行一次日志備份，那么萬一數據庫壞了，在恢復的時候，手動恢復成百上千個日志文件，就非常非常麻煩~~~

愛數的解決方案：

將完整備份與日志備份自動組織，抽象成一個一個時間點，只要選擇時間點便可以輕松到該備份時間點。

備份的完整性充分保障，不用擔心日志斷檔，不用手動恢復成百上千個日志文件，節省大量的恢復的時間，在數據發生后能夠迅速恢復應用，減少企業的損失。

備份管理之比較

如果你所在公司有很多的數據庫服務器（就像我所在的公司），而且磁盤空間有限，那么你不得不經常登錄服務器來刪除舊的備份文件，如果哪天忘了，或者五一十一長假，磁盤空間用完了，就麻煩了。

所以你需要定期執行DBCC檢查，來盡早發現數據庫頁面的完整性。在未作完DBCC檢查之前，你不能刪除舊的備份，以防止新的備份存在問題。所以，刪除備份文件的工作變的有些麻煩。

你可能知道SQL Server提供了數據庫維護計劃。沒錯，使用它可以定期做備份，執行DBCC檢查，但這一切僅限于本機操作。為了使數據庫可靠，你還是需要自己把本地備份傳送至備機。

愛數的解決方案：

利用集中式管理工具的幫助，系統管理員可對全網的備份策略進行統一管理，備份服務器可以監控所有機器的備份作業，也可以修改備份策略，具有自動刪除老數據功能，多種加密算法，保護數據隱私，三種壓縮模式，可以將數據量大大減小，自有文件格式，病毒冰凍技術，詳細的日志與報表，保障用戶的可省閱性。

系統支撐功能之比較

在網絡條件不好的時候？如果數據庫備份文件的傳送在某一時刻停止了，你多久才能發現？公司值晚班的同事有權限檢查數據庫的備份情況嗎？系統崩潰了，SQL的運行也成了空中樓閣。

服務器被盜，或者遭遇火災、地震或者其它自然災害，那SQL的數據丟失更加成為必然。SQL自帶備份對以上這些情況毫無辦法。

愛數的解決方案：網絡不穩定時可以自動重聯；具有系統備份功能；高性價比、易實施的遠程數據備份

總體來說愛數優勢還比較多：

完全備份＋日志備份整合非常優秀，實現了數據庫小粒度的增量備份。

按時間點的恢復，我們不用考慮恢復到數據庫崩潰前需要恢復哪些日志文件。

可以設置保留最新N個全備份的版本，自動刪除老版本的備份數據。

每個全備份帶有N個日志備份。恢復靈活性很大。

可以設置備用的備份目的地，這樣就不用擔心放假時備份空間被消耗掉。

可以將備份數據加密、壓縮等。

可以將數據備份到異地，甚至遠程的FTP服務器。

更低的TCO。

詳細比較：

SQL Server自帶備份功能

的不足與缺陷 愛數SQL Server備份選件的優勢

備份功能 日志管理太復雜 自動組織備份文件與日志

恢復功能 手動恢復大量日志文件太麻煩，無法滿足恢復的時間要求

要是某個日志丟失形成斷檔，就會造成數據無法正常恢復 將完整備份與日志備份自動組織，抽象成一個一個時間點，用戶只要選擇時間點便可以輕松、快速的恢復

備份管理 無法自動刪除過期老文件

無法加密

無法壓縮

易被病毒感染 具有自動刪除老數據功能

多種加密算法，保護數據隱私

三種壓縮模式，可以將數據量大大減小

自有文件格式，病毒冰凍技術

詳細的日志與報表

系統支撐功能 網絡不穩定 網絡不穩定時可以自動重聯

系統崩潰 具有系統備份功能

電腦、服務器被盜

火災、地址及其它自然災害 高性價比、易實施的遠程數據備份

分享：如何快速生成100萬不重復的8位編號
最近在論壇看到有人問，如何快速生成100萬不重復的8位編號，對于這個問題，有幾點是需要注意的： 1． 如何生成8位隨機數，生成的數越隨機，重復的可能性當然越小 2． 控制不重復