今天在給客戶服務器Microsoft SQL Server2008數據庫服務器添加維護計劃時報錯：
創建維護計劃失敗。
------------------------------
其他信息:
從 IClassFactory 為 CLSID 為 {17BCA6E8-A95D-497E-B2F9-AF6AA475916F} 的 COM 組件創建實例失敗，原因是出現以下錯誤: c001f011。 (Microsoft.SqlServer.ManagedDTS)
------------------------------
從 IClassFactory 為 CLSID 為 {17BCA6E8-A95D-497E-B2F9-AF6AA475916F} 的 COM 組件創建實例失敗，原因是出現以下錯誤: c001f011。 (Microsoft.SqlServer.ManagedDTS)
解決方法：
C:\Documents and Settings\Administrator>regsvr32 "C:\Program Files\Microsoft SQL Server\100\DTS\Binn\DTS.dll"，
（或者
C:\Documents and Settings\Administrator>regsvr32 "C:\Program Files(x86)\Microsoft SQL Server\100\DTS\Binn\DTS.dll"）
posted @
2017-01-17 13:17 Glorin 閱讀(1642) |
評論 (0) |
編輯 收藏1、shutdown normal
正常方式關閉數據庫。
2、shutdown immediate
立即方式關閉數據庫。
在SVRMGRL中執行shutdown immediate，數據庫并不立即關閉，
而是在Oracle執行某些清除工作后才關閉（終止會話、釋放會話資源），
當使用shutdown不能關閉數據庫時，shutdown immediate可以完成數據庫關閉的操作。
3、shutdown abort
直接關閉數據庫，正在訪問數據庫的會話會被突然終止，
如果數據庫中有大量操作正在執行，這時執行shutdown abort后，重新啟動數據庫需要很長時間
--------------------------------------------------------
shutdown abort 的時候，跟kill 進程是一樣的效果
數據庫立即關閉，這個時候文件狀態可能不一致
因為正常關閉數據庫會同步校驗各文件，使得重新啟動的時候文件時間點一致并且不用進行崩潰恢復
若檢查點信息一致，則做崩潰恢復
若檢查點信息不一致（正好在更新文件頭）則需要做介質恢復
這些問題都好處理，最怕的問題是這個時候系統有大量IO，結果這樣造成寫的突然中斷，碰巧造成文件塊的邏輯壞塊，那麻煩比較大一些，尤其是系統表空間的block損壞
雖然shutdown abort 出錯的幾率很小，1000個人可能只有一個人碰到，但是我們還是要小心。
正確的處理流程是，shutdown immediate ,若數據庫遲遲不能down下來，在os上觀察IO狀況，幾乎沒有io的時候，另開一窗口shutdown abort ，幾乎不會出問題了
--------------------------------------------------------
http://www.itpub.net/showthread.php?threadid=180315&pagenumber=
先用IMMEDIATE來DOWN，實在不行了，看一下數據庫文件上沒IO了，再用ABORT
------------------------------------------------------------------------------
你可以嘗試先在系統級殺掉非后臺Oracle進程，在連接shutdown immediate就安全多了
在Oracle8i里，當數據庫失去響應以后，你在操作系統上殺掉用戶進程后，一般數據庫就可以恢復正常了
-------------------------------------------------------------------------------
先 shutdown immediate 應該是首選
然后不行再重新shutdown abort
其實起不來也是因為os的緣故，在文件正在寫的時候出現問題導致文件不一致或者損壞……
posted @
2015-11-02 15:04 Glorin 閱讀(157) |
評論 (0) |
編輯 收藏
在給mysql數據庫備份時，報錯：mysqldump: Got error: 145: Table './jxzhtopenfire/ofoffline' is marked as crashed and should be repaired when using LOCK TABLES。
如上錯誤的解決方法如下：
1、進入數據庫對該表進行檢測：
mysql> check tables ofoffline;
+-------------------------+-------+----------+-------------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+-------------------------+-------+----------+-------------------------------------------------------+
| jxzhtopenfire.ofoffline | check | warning | Table is marked as crashed |
| jxzhtopenfire.ofoffline | check | warning | 1 client is using or hasn't closed the table properly |
| jxzhtopenfire.ofoffline | check | error | Record at pos: 1175720 is not remove-marked |
| jxzhtopenfire.ofoffline | check | error | record delete-link-chain corrupted |
| jxzhtopenfire.ofoffline | check | error | Corrupt |
+-------------------------+-------+----------+-------------------------------------------------------+
5 rows in set
2、使用repair解決方法：
mysql> repair table ofoffline;
+-------------------------+--------+----------+------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+-------------------------+--------+----------+------------------------------------------+
| jxzhtopenfire.ofoffline | repair | warning | Number of rows changed from 2349 to 2451 |
| jxzhtopenfire.ofoffline | repair | status | OK |
+-------------------------+--------+----------+------------------------------------------+
再次進行dump備份就可以了。
備份mysql數據庫時報錯：mysqldump: Got error: 145: Table './jxzhtopenfire/ofoffline' is marked as crashed and should be repaired when using LOCK TABLES。
這樣的錯誤。
搜索了一下，發現只要在mysqldump的時候加上--lock-tables=false就可以解決問題。
mysqldump -u root -pMyPassword DbName --lock-tables=false > data.sql
posted @
2015-09-30 09:56 Glorin 閱讀(2045) |
評論 (0) |
編輯 收藏
問題：
SQL> startup
ORACLE instance started.
Total System Global Area 538514184 bytes
Fixed Size 451336 bytes
Variable Size 503316480 bytes
Database Buffers 33554432 bytes
Redo Buffers 1191936 bytes
Database mounted.
ORA-01113: file 26 needs media recovery
ORA-01110: data file 26: '/opt/ora9/product/oradata/NTDB/EXAMPLE02.dbf'
解決方法：
SQL> recover datafile '/opt/ora9/product/oradata/NTDB/EXAMPLE02.dbf'
ORA-00279: change 244674111 generated at 09/24/2013 15:20:41 needed for thread
1
ORA-00289: suggestion : /opt/ora9/product/oracle/dbs/arch1_1123.dbf
ORA-00280: change 244674111 for thread 1 is in sequence #1123
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto
Log applied.
Media recovery complete.
SQL> alter database open;
Database altered.
posted @
2013-09-26 09:49 Glorin 閱讀(1719) |
評論 (0) |
編輯 收藏
oracle9i在進行數據庫全庫備份時出現如下錯誤：
Connected to: Oracle9i Enterprise Edition Release 9.2.0.8.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.8.0 - Production
Export done in ZHS16GBK character set and AL16UTF16 NCHAR character set
About to export the entire database ...
. exporting tablespace definitions
EXP-00008: ORACLE error 1187 encountered
ORA-01187: cannot read from file 201 because it failed verification tests
ORA-01110: data file 201: '/opt/ora9/product/oradata/NTDB/temp1.dbf'
EXP-00000: Export terminated unsuccessfully
從上面的錯誤信息可以看出是temp臨時表空間的數據文件有問題，解決辦法：
1、刪除臨時表空間： alter database tempfile '/opt/ora9/product/oradata/NTDB/temp1.dbf' drop;
2、重建數據文件：
alter tablespace temp add tempfile '/opt/ora9/product/oradata/NTDB/temp01.dbf' size 512M REUSE AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED;
通過上述兩個步驟就可以解決在進行數據庫備份時出現的ORACLE error 1187 encountered錯誤。
posted @
2013-06-17 09:58 Glorin 閱讀(669) |
評論 (0) |
編輯 收藏