今天在给客户服务器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 阅读(1592) |
评论 (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 阅读(151) |
评论 (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 阅读(2040) |
评论 (0) |
编辑 收藏