① mysql報警日誌文件位置在哪裡
C:\Users\15175\AppData\Roaming\SQLyog\sja.log
這是系統默認存放位置，日誌文件記錄了所有在任務運行期間發生的錯誤；
SQL Server 2005有4個系統資料庫，它們分別為Master、Model、Msdb、Tempdb。
SQL 的所有系統信息都記錄在Master資料庫中。
model 資料庫用作在 SQL Server 實例上創建的所有資料庫的模板（比如你利用模板創建一張表、一個存儲過程、函數等等，這些模板都是在Model資料庫中存儲的）
Msdb資料庫是代理服務資料庫，你設置的一些報警、任務調度、計劃任務等，她們的存儲空間就是這個資料庫。
Tempdb是臨時資料庫，你使用的臨時表就是存儲在這個資料庫中。
希望對你有所幫助。
③ linux 下 apache mysql 報警機制，自動監控mysql健康狀態
由於php是一個zip文件(非install版),安裝較為簡單
解壓就行.把解壓的 php-5.2.1-Win32 重命名為 php5.並復制到C盤目錄下.即安裝路徑為 c:\php
1 找到php目錄下的 php.ini.recommended (或者php.ini-dist)文件,重命名為 php.ini
並復制到系統盤的windows目錄下(以c:\windows為例).
2 再把php目錄下的php5ts.dll,libmysql.dll復制到目錄 c:\windows\system32下.
3 把php\ext目錄下的php_gd2.dll,php_mysql.dll,php_mbstring.dll文件復制到c:\windows\system32下
注意:不要把 php_mysql.dll 和 php_mssql.dll 混淆
如果沒有載入 php_gd2.dll php將不能處理圖像.沒有載入php_mysql.dll php將不支持mysql函數庫
php_mbstring.dll在後面使用phpmyadmin時支持寬字元
配置php並關聯MySQL
1 設置擴展路徑
查找 extension_dir 有這么一行
extension_dir = "./"
將此行改成
extension_dir = "C:\php\ext"
其中C:\php是你安裝php的路徑.路徑不正確將無法載入dll
(注意:有些php版本是 ;extension_dir = "./" 要把前面的分號去掉)
2 分別查找
;extension=php_mbstring.dll
;extension=php_gd2.dll
;extension=php_mysql.dll
把上面3項前面的分號去掉,這樣apache啟動時就可以載入這些dll了
注意不要把 ;extension=php_mysql.dl 和 ;extension=php_mssql.dl 混淆
當然前面我們也把這些dll復制到system32下了.(大家在安裝的過程中都注意到如何把一些dll載入入來了.
以後要載入一些dll,比如說php_mysqli.dll,也就懂得怎麼載入了)
3 設置會話保存路徑
查找session.save_path 有這么一行
; session.save_path = "N;/path"
在此行後加入一行(注意是加入一行,不是加到後面)
session.save_path = "C:\WINDOWS\Temp"
保存到你的臨時目錄下,這里完全可以保存到windows臨時目錄Temp下
4 是否顯示錯誤 display_errors
出於安全性考慮,display_errors 有些版本也默認為 Off.
就是說在調試時,如果php代碼有誤,就只出現一個空白頁.而不會顯示出錯原因和出錯行數.
這樣調試起來將非常不便,建議根據自己需要修改
查找
display_errors = Off (注意不是 ; - display_errors = Off [Security])
改成
display_errors = On
5 php5時差問題
<?php echo date("Y-m-d H:i:s");?>時間相差八小時
為什麼呢?PHP5系列版本新增了時區設置,默認為格林威治時間,與中國所在的東8區正好相差8個小時
查找date.timezone有這么一行
;date.timezone =
將;去掉,改成、
date.timezone = PRC
其中PRC：People's Republic of China 中華人民共和國,
PHP的文件上傳問題
文件上傳成敗關鍵的幾點php.ini配置
文件上傳的程序沒有錯,但php的配置很可能導致文件不能上傳成功.
一般的文件上傳,除非文件很小.就像一個5M的文件,很可能要超過一分鍾才能上傳完.
但在php中,默認的該頁最久執行時間為 30 秒.就是說超過30秒,該腳本就停止執行.
這就導致出現 無法打開網頁的情況.這時我們可以修改 max_execution_time
在php.ini里查找
max_execution_time
默認是30秒.改為
max_execution_time = 0
0表示沒有限制
另一種方法是可以在php程序中加入
set_time_limit();
來設定頁面最久執行時間.
set_time_limit(0);//0表示沒有限制
修改 post_max_size 設定 POST 數據所允許的最大大小。此設定也影響到文件上傳。
php默認的post_max_size 為2M.如果 POST 數據尺寸大於 post_max_size $_POST 和 $_FILES superglobals 便會為空.
查找 post_max_size .改為
post_max_size = 150M
很多人都會改了第二步.但上傳文件時最大仍然為 8M.
為什麼呢.我們還要改一個參數upload_max_filesize 表示所上傳的文件的最大大小。
查找upload_max_filesize,默認為8M改為
upload_max_filesize = 100M
另外要說明的是,post_max_size 大於 upload_max_filesize 為佳.
active perl 需要安裝到c:/perl
ZendOptimizer 安裝時把 apache 伺服器關掉，在過程中要指定 apache 和 php 的安裝路徑
在Win2K環境下安裝Apache PHP
軟體需求：
Windows 2000 Professional ； Apache 1.3.19 (apache_1.3.19-win32-src-r2.msi) ； PHP 4.0.5 (php-4.0.5-Win32.zip) ； MySQL 3.23.38 (mysql-3.23.38-win.zip)
安裝過程
將 Apache 1.3.19 安裝到 C:\Web\apache\ 目錄下。
將 PHP 4.0.5 解壓到 C:\Web\php\ 目錄下。
將 MySQL 3.23.38 安裝到 C:\Web\mysql\ 目錄下。
將 C:\web\php\php4ts.dll 文件拷貝到 C:\WINNT\system32\ 目錄下。
將 C:\web\php\php.exel 文件拷貝到 C:\WINNT\ 目錄下。
將 C:\web\php\php.ini-dist 文件拷貝到 C:\WINNT\ 目錄下，並將php.ini-dist 更名為 php.ini。
運行 C:\Web\apache\Apache\Apache.exe -i –n
運行 C:\Web\mysql\bin\mysqld-nt.exe --install
編輯 C:\WINNT\php.ini
找到 「extension_dir = ./ 」 欄位，將其改為 extension_dir = "C:\myphp\php\extensions"。
運行 C:\Web\apache\Apache\Apache.exe -i –n
編輯 C:\Web\apache\Apache\conf\httpd.conf
找到「 #BindAddress*」 欄位
將其改為 BindAddress 127.0.0.1 。（如果主機有固定IP地址，此處改為主機IP地址。如 BindAddress 211.101.152.106），找到 「ServerName」 欄位，將其改為 ServerName localhost。（如主機有固定主機名，此處改為主機的主機名。如ServerName bn001 ）。
找到「 ScriptAlias /cgi-bin/ "C:/Web/apache/Apache/cgi-bin/" 」 欄位，在其下面加入 ScriptAlias /php/ "C:/Web/php/" 。找到 「# And for PHP 4.x, use: 」 欄位，在其後面加入：
AddType application/x-httpd-php .php3
AddType application/x-httpd-php .php4
AddType application/x-httpd-php .php
AddType application/x-httpd-php .phtml
Action Application/x-httpd-php "c:/Web/php/php.exe"
找到「 #LoadMole usertrack_mole moles/mod_usertrack.so」 欄位，LoadMole php4_mole c:/web/php/sapi/php4apache.dll
UNIX下的PHP環境配置
所需軟體
php-3.0.14-win32.zip；php-3.0.14-win32.zip；mysql-shareware-3.22.32-win.zip
所有軟體均安裝在/export/home/guoj/下，也可在其他目錄。
安裝mysql
gzip -dc mysql-3.22.30.tar.gz | tar xvf-
cd mysql-3.22.30
./configure -prefix= /export/home/guoj/mysql
Make
make install
scripts/mysql_install_db
cd../mysql/bin
bin/safe_mysqld & 安裝php apache
gzip -dc apache_1.3.11.tar.gz | tar xvf-
gzip -dc php-3.0.11.tar.gz | tar xvf-
cd apache_1.3.11
./configure -prefix= /export/home/guoj/www
cd ../php-3.0.11
./configure -with-apache= /export/home/guoj/apache_1.3.11
-with-mysql= /export/home/guoj/mysql -enable-track-vars
Make
make install
cd ../apache_1.3.11
./configure --prefix= /export/home/guoj/www
--activate-mole=src/moles/php3/libphp3.aP
Make
make install
cd ../php-3.0.11
cd ../php3.ini-dist php3.ini
vi php3.ini修改php3.ini
doc_root=/export/home/guoj/www/htdocs/
extension_dir=/export/home/guoj/php-3.0.11/
extension=php3_mysql.dllcp php3.ini/usr/local/lib/php3.inivi ../www/conf/httpd.conf
加上以下幾句：
AddType application/x-httpd-php3 .php3
<Directory "/export/home/guoj/php-3.0.11/">
Options FollowSymLinks
AllowOverride None
</Directory>../www/bin/apachectl start
④ 監控系統採用SQL資料庫,可否更改某天數據
你要能接觸到
資料庫伺服器
，當然可以修改。
可以用
SQL語言
修改，你要不會最好是找個懂SQL的到你本地修改
⑤ ifix報警和SQL問題
系統配置裡面的SQL配置，你配置了嗎？
⑥ sql 錯誤 823
--------------------- 1.日誌文件被破壞823錯誤 ---------------------- 日誌文件被破壞的資料庫文件，通過如下方法附加上去後，資料庫里所有的表都不能訪問，提示錯誤832，請問要如何解決？？ use master go sp_configure 'allow updates',1 go reconfigure with override go update sysdatabases set status=-32768 where dbid=DB_ID('linyi_pljy') go dbcc rebuild_log('linyi_pljy','e:Program FilesMicrosoft SQL ServerMSSQLDatalinyi_pljy_log.ldf') go sp_dboption 'linyi_pljy','dbo use only','false' go sp_configure 'allow updates',0 go reconfigure with override go --------------------- 2.附加資料庫文件時,提示823錯誤 ---------------------- EXEC sp_configure 'allow updates',1 RECONFIGURE WITH OVERRIDE /* 打開修改系統表的開關 */ update sysdatabases set status = 32768 where name = '資料庫名' DBCC REBUILD_LOG ('資料庫名', 'E: dzzdatabase dzz1204_Log.LDF' ) update sysdatabases set status = 0 where name = '資料庫名' restore database 資料庫名 WITH RECOVERY EXEC sp_configure 'allow updates',0 RECONFIGURE WITH OVERRIDE /* 關閉打開修改系統表的開關 */ --------------------- 3.因為停電等原因造成MSSQL資料庫,提示823錯誤 ---------------------- USE MASTER GO sp_dboption 『databaseName』, 』single user』, 『true』 Go DBCC CHECKDB(』databaseName』, REPAIR_REBUILD) Go USE databaseName go exec sp_msforeachtable 『DBCC CHECKTABLE(''』?''』,REPAIR_REBUILD)』 go sp_dboption 『databaseName』, 』single user』, 『false』 Go 如果還不行，可以採用允許丟失數據的方式修復，如下： USE MASTER GO sp_dboption 『databaseName』, 』single user』, 『true』 Go DBCC CHECKDB(』databaseName』, REPAIR_ALLOW_DATA_LOSS) Go USE databaseName go exec sp_msforeachtable 『DBCC CHECKTABLE(''』?''』,REPAIR_REBUILD)』 go sp_dboption 『databaseName』, 』single user』, 『false』 Go --------------------- 4.在大富翁論壇收集的資料庫恢復資料 ---------------------- SQL Server資料庫備份有兩種方式，一種是使用BACKUP DATABASE將資料庫文件備份出去，另外一種就是直接拷貝資料庫文件mdf和日誌文件ldf的方式。下面將主要討論一下後者的備份與恢復。本文假定您能熟練使用SQL Server Enterprise Manager(SQL Server企業管理器)和SQL Server Quwey Analyser(SQL Server查詢分析器) 1、正常的備份、恢復方式正常方式下，我們要備份一個資料庫，首先要先將該資料庫從運行的數據伺服器中斷開，或者停掉整個資料庫伺服器，然後復制文件。卸下資料庫的命令：Sp_detach_db 資料庫名連接資料庫的命令：Sp_attach_db或者sp_attach_single_file_db s_attach_db [@dbname =] ′dbname′, [@filename1 =] ′filename_n′ [,...16] sp_attach_single_file_db [@dbname =] ′dbname′, [@physname =] ′physical_name′ 使用此方法可以正確恢復SQL Sever7.0和SQL Server 2000的資料庫文件，要點是備份的時候一定要將mdf和ldf兩個文件都備份下來，mdf文件是資料庫數據文件，ldf是資料庫日誌文件。例子：假設資料庫為test，其數據文件為test_data.mdf，日誌文件為test_log.ldf。下面我們討論一下如何備份、恢復該資料庫。卸下資料庫：sp_detach_db 'test' 連接資料庫：sp_attach_db 'test','C:Program FilesMicrosoft SQL ServerMSSQLData est_data.mdf','C:Program FilesMicrosoft SQL ServerMSSQLData est_log.ldf' sp_attach_single_file_db 'test','C:Program FilesMicrosoft SQL ServerMSSQLData est_data.mdf' 2、只有mdf文件的恢復技術由於種種原因，我們如果當時僅僅備份了mdf文件，那麼恢復起來就是一件很麻煩的事情了。如果您的mdf文件是當前資料庫產生的，那麼很僥幸，也許你使用sp_attach_db或者sp_attach_single_file_db可以恢復資料庫，但是會出現類似下面的提示信息設備激活錯誤。物理文件名 'C:Program FilesMicrosoft SQL ServerMSSQLdata est_Log.LDF' 可能有誤。已創建名為 'C:Program FilesMicrosoft SQL ServerMSSQLData est_log.LDF' 的新日誌文件。但是，如果您的資料庫文件是從其他計算機上復制過來的，那麼很不幸，也許上述辦法就行不通了。你也許會得到類似下面的錯誤信息伺服器: 消息 1813，級別 16，狀態 2，行 1 未能打開新資料庫 'test'。CREATE DATABASE 將終止。設備激活錯誤。物理文件名 'd: est_log.LDF' 可能有誤。怎麼辦呢？別著急，下面我們舉例說明恢復辦法。 A．我們使用默認方式建立一個供恢復使用的資料庫(如test)。可以在SQL Server Enterprise Manager裡面建立。 B．停掉資料庫伺服器。 C．將剛才生成的資料庫的日誌文件test_log.ldf刪除，用要恢復的資料庫mdf文件覆蓋剛才生成的資料庫數據文件test_data.mdf。 D．啟動資料庫伺服器。此時會看到資料庫test的狀態為「置疑」。這時候不能對此資料庫進行任何操作。 E．設置資料庫允許直接操作系統表。此操作可以在SQL Server Enterprise Manager裡面選擇資料庫伺服器，按右鍵，選擇「屬性」，在「伺服器設置」頁面中將「允許對系統目錄直接修改」一項選中。也可以使用如下語句來實現。 use master go sp_configure 'allow updates',1 go reconfigure with override go F．設置test為緊急修復模式 update sysdatabases set status=-32768 where dbid=DB_ID('test') 此時可以在SQL Server Enterprise Manager裡面看到該資料庫處於「只讀置疑離線緊急模式」可以看到資料庫裡面的表，但是僅僅有系統表 G．下面執行真正的恢復操作，重建資料庫日誌文件 dbcc rebuild_log('test','C:Program FilesMicrosoft SQL ServerMSSQLData est_log.ldf') 執行過程中，如果遇到下列提示信息：伺服器: 消息 5030，級別 16，狀態 1，行 1 未能排它地鎖定資料庫以執行該操作。 DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。[brown] 說明您的其他程序正在使用該資料庫，如果剛才您在F步驟中使用SQL Server Enterprise Manager打開了test庫的系統表，那麼退出SQL Server Enterprise Manager就可以了。正確執行完成的提示應該類似於： [brown]警告: 資料庫 'test' 的日誌已重建。已失去事務的一致性。應運行 DBCC CHECKDB 以驗證物理一致性。將必須重置資料庫選項，並且可能需要刪除多餘的日誌文件。 DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。此時打開在SQL Server Enterprise Manager裡面會看到資料庫的狀態為「只供DBO使用」。此時可以訪問資料庫裡面的用戶表了。 H．驗證資料庫一致性（可省略） dbcc checkdb('test') 一般執行結果如下： CHECKDB 發現了 0 個分配錯誤和 0 個一致性錯誤（在資料庫 'test' 中）。 DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。 I．設置資料庫為正常狀態 sp_dboption 'test','dbo use only','false' 如果沒有出錯，那麼恭喜，現在就可以正常的使用恢復後的資料庫啦。 J．最後一步，我們要將步驟E中設置的「允許對系統目錄直接修改」一項恢復。因為平時直接操作系統表是一件比較危險的事情。當然，我們可以在SQL Server Enterprise Manager裡面恢復，也可以使用如下語句完成 sp_configure 'allow updates',0 go reconfigure with override go 來自：yzhshi, 時間：2003-3-11 9:59:00, ID：1670897 為藍色頁面用戶再提供一份，不過建議使用黃色頁面，頁面標志更清晰一些。 SQL Server資料庫文件恢復技術 yzhshi([email protected]) SQL Server資料庫備份有兩種方式，一種是使用BACKUP DATABASE將資料庫文件備份出去，另外一種就是直接拷貝資料庫文件mdf和日誌文件ldf的方式。下面將主要討論一下後者的備份與恢復。本文假定您能熟練使用SQL Server Enterprise Manager (SQL Server企業管理器)和SQL Server Quwey Analyser(SQL Server查詢分析器) 1、正常的備份、恢復方式正常方式下，我們要備份一個資料庫，首先要先將該資料庫從運行的數據伺服器中斷開，或者停掉整個資料庫伺服器，然後復制文件。卸下資料庫的命令：Sp_detach_db 資料庫名連接資料庫的命令：Sp_attach_db或者sp_attach_single_file_db s_attach_db [@dbname =] ′dbname′, [@filename1 =] ′filename_n′ [,...16] sp_attach_single_file_db [@dbname =] ′dbname′, [@physname =] ′physical_name′ 使用此方法可以正確恢復SQL Sever7.0和SQL Server 2000的資料庫文件，要點是備份的時候一定要將 mdf和ldf兩個文件都備份下來，mdf文件是資料庫數據文件，ldf是資料庫日誌文件。例子：假設資料庫為test，其數據文件為test_data.mdf，日誌文件為test_log.ldf。下面我們討論一下如何備份、恢復該資料庫。卸下資料庫：sp_detach_db 'test' 連接資料庫：sp_attach_db 'test','C:Program FilesMicrosoft SQL ServerMSSQLData est_data.mdf','C:Program FilesMicrosoft SQL ServerMSSQLData est_log.ldf' sp_attach_single_file_db 'test','C:Program FilesMicrosoft SQL ServerMSSQLData est_data.mdf' 2、只有mdf文件的恢復技術由於種種原因，我們如果當時僅僅備份了mdf文件，那麼恢復起來就是一件很麻煩的事情了。如果您的mdf文件是當前資料庫產生的，那麼很僥幸，也許你使用sp_attach_db或者 sp_attach_single_file_db可以恢復資料庫，但是會出現類似下面的提示信息 設備激活錯誤。物理文件名 'C:Program FilesMicrosoft SQL ServerMSSQLdata est_Log.LDF' 可能有誤。已創建名為 'C:Program FilesMicrosoft SQL ServerMSSQLData est_log.LDF' 的新日誌文件。 但是，如果您的資料庫文件是從其他計算機上復制過來的，那麼很不幸，也許上述辦法就行不通了。你也許會得到類似下面的錯誤信息 伺服器: 消息 1813，級別 16，狀態 2，行 1 未能打開新資料庫 'test'。CREATE DATABASE 將終止。設備激活錯誤。物理文件名 'd: est_log.LDF' 可能有誤。 怎麼辦呢？別著急，下面我們舉例說明恢復辦法。 A．我們使用默認方式建立一個供恢復使用的資料庫(如test)。可以在SQL Server Enterprise Manager 裡面建立。 B．停掉資料庫伺服器。 C．將剛才生成的資料庫的日誌文件test_log.ldf刪除，用要恢復的資料庫mdf文件覆蓋剛才生成的數據 庫數據文件test_data.mdf。 D．啟動資料庫伺服器。此時會看到資料庫test的狀態為"置疑"。這時候不能對此資料庫進行任何操作。 E．設置資料庫允許直接操作系統表。此操作可以在SQL Server Enterprise Manager裡面選擇資料庫服 務器，按右鍵，選擇"屬性"，在"伺服器設置"頁面中將"允許對系統目錄直接修改"一項選中。也可以 使用如下語句來實現。 use master go sp_configure 'allow updates',1 go reconfigure with override go F．設置test為緊急修復模式 update sysdatabases set status=-32768 where dbid=DB_ID('test') 此時可以在SQL Server Enterprise Manager裡面看到該資料庫處於"只讀置疑離線緊急模式"可以 看到資料庫裡面的表，但是僅僅有系統表 G．下面執行真正的恢復操作，重建資料庫日誌文件 dbcc rebuild_log('test','C:Program FilesMicrosoft SQL ServerMSSQLData est_log.ldf') 執行過程中，如果遇到下列提示信息： 伺服器: 消息 5030，級別 16，狀態 1，行 1 未能排它地鎖定資料庫以執行該操作。 DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。 說明您的其他程序正在使用該資料庫，如果剛才您在F步驟中使用SQL Server Enterprise Manager 打開了test庫的系統表，那麼退出SQL Server Enterprise Manager就可以了。 正確執行完成的提示應該類似於： 警告: 資料庫 'test' 的日誌已重建。已失去事務的一致性。應運行 DBCC CHECKDB 以驗證物理一致 性。將必須重置資料庫選項，並且可能需要刪除多餘的日誌文件。 DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。 此時打開在SQL Server Enterprise Manager裡面會看到資料庫的狀態為"只供DBO使用"。此時可以 訪問資料庫裡面的用戶表了。 H．驗證資料庫一致性（可省略） dbcc checkdb('test') 一般執行結果如下： CHECKDB 發現了 0 個分配錯誤和 0 個一致性錯誤（在資料庫 'test' 中）。 DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。 I．設置資料庫為正常狀態 sp_dboption 'test','dbo use only','false' 如果沒有出錯，那麼恭喜，現在就可以正常的使用恢復後的資料庫啦。 J．最後一步，我們要將步驟E中設置的"允許對系統目錄直接修改"一項恢復。因為平時直接操作系統表 是一件比較危險的事情。當然，我們可以在SQL Server Enterprise Manager裡面恢復，也可以使用 如下語句完成 sp_configure 'allow updates',0 go reconfigure with override go ===================================================================================== (轉) 修復SQLSERVER2000資料庫之實戰經驗 我所講的一個故事的背景是這樣的，在某一個POS的項目中使用SQLSERVER 2000做前台資料庫，IBM 的DB2做後台資料庫。前台資料庫的環境是這樣的操作系統是WINDOWS2000 SERVER(10 USERS),資料庫是 SQLSERVER2000(E)+SP3,Application是POS的收銀系統（是一種實時的交易系統）。硬體的配置是：P4 XRON 2.4G*2,36G HDD*5 做的RAID5 ,1G MEMORY，HP DDS4 磁帶機,資料庫的容量一般保持在5G左右。 因為數據比較的重要，並且數據容量也不大，我們要求的備份策略是每天在磁帶機做POS_DB的全備份（一個星期7天一個循環），在晚上還在硬碟上做全部備份（MASTER,MSDB,POS_DB).這樣保持雙重的保險。 1.故障爆發： 2003－12－26 13:00 客戶報告所有的POS死機和SERVER運行速度非常的慢。經過重新啟動伺服器（啟動到檢查RAID卡時開始報警）我們發現在WINDEOWS 2000 SERVER的「系統日誌」中有這樣的信息： Error: 823, Severity: 24, State: 2 I/O error (torn page) detected ring read at offset 0x0000001bf96000 in file D :DATAPOS_DB.mdf'. SQLSERVER的「錯誤日誌」中有這樣的信息： 2003-12-10 03:34:22.23 spid56 Error: 823, Severity: 24, State: 2 2003-12-10 03:34:22.23 spid56 I/O error (torn page) detected ring read at offset 0x00000074964000 in file 'D:DATAPOS_DB.mdf'.. 來自msdn的解釋： I/O logical check failure: If a read Windows API call or a write Windows API call for a database file is successful, but specific logical checks on the data are not successful (a torn page, for example), an 823 error is raised. The following error message is an example of an 823 error for an I/O logical check failure: 2003-09-05 16:51:18.90 spid17 Error: 823, Severity: 24, State: 2 2003-09-05 16:51:18.90 spid17 I/O error (torn page) detected ring read at offset 0x00000094004000 in file 'F:SQLDatamydb.MDF'.. To resolve this problem, first run the DBCC CHECKDB statement on the database that is associated with the file in the error message. If the DBCC CHECKDB statement reports errors, correct those errors before you troubleshoot this problem. If the problem persists even after the DBCC CHECKDB errors have been corrected, or if the DBCC CHECKDB statement does not report any errors, review the Microsoft Windows NT system event log for any system errors or disk-related errors. You can also contact your hardware vendor to run any appropriate diagnostics. I/O邏輯檢查失敗：如果有一個WINDOWS程序在讀取和寫資料庫文件時是成功的，但是在詳細的數據邏輯檢查時沒有成功（比如：不完整的頁），SQLSERVER會返回MSG 823的錯誤。下面就是一個I/O邏輯檢查失敗MSG 823的實例： 2003-09-05 16:51:18.90 spid17 Error: 823, Severity: 24, State: 2 2003-09-05 16:51:18.90 spid17 I/O error (torn page) detected ring read at offset 0x00000094004000 in file 'F:SQLDatamydb.MDF'.. 要解決這樣的問題，首先要在該資料庫中執行DBCC CHECKDB（錯誤信息提示的資料庫文件）。如果DBCC CHECKDB報錯，在你修復錯誤之前糾正這些錯誤。如果這些錯誤信息一直保留到執行DBCC CHECKDB運行之後，或者DBCC CHECKDB沒有報告任何錯誤，檢查WINDOWS NT系統的的事件查看器的和系統錯誤或磁碟錯誤相關的信息。你也可以聯系硬體廠商運行正確的診斷工具。 壞了:-(，資料庫文件有問題，在檢查OS的事件查看器，我們發現在一個星期之前就有錯誤信息（只是OFFSET的偏移地址不同）。 趕緊檢查HDD,果然發現在RAID5的第一快HDD亮了紅燈（灰塵太多，很難於看清） 執行 DBCC CHECKDB('POS_DB')檢查發現： Server: Msg 8909, Level 16, State 1, Line 1 Table error: Object ID 26342838, index ID 35207, page ID (1:50978). The PageId in the page header =(32230:-2048732002). Server: Msg 8939, Level 16, State 1, Line 1 Table error: Object ID 859150106, index ID 255, page (1:238770). Test (IS_ON (BUF_IOERR, bp->bstat) && bp->berrcode) failed. Values are 2057 and -1. Server: Msg 8928, Level 16, State 1, Line 1 Object ID 861246123, index ID 0: Page (1:57291) could not be processed. See other errors for details. Server: Msg 2511, Level 16, State 1, Line 1 Table error: Object ID 862626116, Index ID 0. Keys out of order on page (1:269310), slots 0 and 1. 啊哈，果然有很多的表都有錯誤關聯（請記錄每一個錯誤表的OBJECT ID) 從MSDN查到： 錯誤號Msg 823:表示SQLSERVER在讀取數據和寫數據時檢測到硬體設備有問題或者系統有問題。 TORN PAGE:的意思是不完整的頁 0x0000001bf96000：這是從數據文件開始處到TORN PAGE 的位元組數。 錯誤號Msg 8939 ：大家可以看看：http://support.microsoft.com/default.aspx?kbid=320434 FIX：在運行 CHECKDB 時，具有 TABLOCK 提示的大容量插入（bulk insert, bcp 等）可能導致錯誤 8929 和 8965 錯誤號MSG 8928:是和8939相關聯的信息， 錯誤號MSG 8965:是和8939相關聯的信息， 大家可以到下面的地址找到相關的信息： http://support.microsoft.com/default.aspx?scid=kb;en-us;826433 PRB: Additional SQL Server Diagnostics Added to Detect Unreported I/O Problems http://support.microsoft.com/default.aspx?scid=kb;en-us;828339 PRB: Error message 823 may indicate hardware problems or system problems http://support.microsoft.com/default.aspx?scid=kb;en-us;308795 FIX: CheckDB May Not Fix Error 8909 or Error 8905 故障確診：RAID有一塊HDD壞，造成資料庫文件破壞 2.更換HDD 2003－12－28 23:00 現在就體現了RAID5的好處，壞了一塊HDD，系統可以照常運行，不過系統的日誌和SQLSERVER的日誌還是有MSG823的報錯信息。 按照RAID 卡的REBUILD的步驟將新的HDD綁定到原始的RAID5中，順利完成:-) 用DBCC檢查資料庫的完整性 DBCC CHECKDB('POS_DB') WITH ALL_ERRORMSGS 發現還是有和更換HDD之前一樣的ERROR信息，看來資料庫文件還是有問題。 --有一個奇怪問題1，既然是5塊HDD的RAID5，為何有一塊HDD壞會影響資料庫文件的損壞，不解？？？:-( 3.恢復資料庫 2003－12－29 00:30 沒有辦法，用備份的數據集恢復資料庫（看來備份是多麼的重要） USE MASTER GO RESTORE DATABASE POS_DB FROM DISK='D:DATABASEBACKUPPOS_DB_BACKUP.DAT' 重新啟動MSSQLSERCVER服務， NET STOP MSSQLSERVER / NET START MSSQLSERVER 用DBCC檢查資料庫的完整性 DBCC CHECKDB('POS_DB') WITH ALL_ERRORMSGS 和恢復之前的錯誤信息一致，沒有改變。 --奇怪問題之2，SQLSERVER BACKUP 之前並不驗證資料庫的完整性，資料庫的全備份竟然是有問題的。氣憤！！ 看來只能通過工具修復資料庫了（--在修改之前記錄錯誤表的記錄數，以便修復資料庫後進行比較）。