随笔 - 6  文章 - 0  trackbacks - 0
<2012年8月>
2930311234
567891011
12131415161718
19202122232425
2627282930311
2345678

常用链接

留言簿

随笔档案

文章档案

搜索

  •  

最新评论

阅读排行榜

评论排行榜

今天在给客户服务器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 阅读(1506) | 评论 (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 阅读(143) | 评论 (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 阅读(2024) | 评论 (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 阅读(1673) | 评论 (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 阅读(652) | 评论 (0)编辑 收藏
1、查看/etc/oratab这个文件:

[oracle@readhatAS53 etc]$ cat /etc/oratab
#

 

# This file is used by ORACLE utilities.  It is created by root.sh
# and updated by the Database Configuration Assistant when creating
# a database.

# A colon, ':', is used as the field terminator.  A new line terminates
# the entry.  Lines beginning with a pound sign, '#', are comments.
#
# Entries are of the form:
#   $ORACLE_SID:$ORACLE_HOME:<N|Y>:
#
# The first and second fields are the system identifier and home
# directory of the database respectively.  The third filed indicates
# to the dbstart utility that the database should , "Y", or should not,
# "N", be brought up at system boot time.
#
# Multiple entries with the same $ORACLE_SID are not allowed.
#
#
ORCL:/u01/oracle/product/ora10g:Y
当$ORACLE_SID:$ORACLE_HOME:<N|Y> 设置为Y时,允许实例自启动,当设置为N时,则不允许自启动。 这个文件里的配置仅仅起一个开关的作用,其并不会具体的执行启动和关闭,具体的操作由$ORACLE_HOME/bin/dbstart和dbshut 脚本来实现。 这2个脚本在执行时会检查/etc/oratab 文件里的配置,为Y时才能继续执行。因此只要将ORCL:/u01/oracle/product/ora10g:N修改为Y就行了。
2、使用root用户在/etc/rc.d/rc.local这个文件中添加如下内容:

#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.

touch /var/lock/subsys/local
su - oracle -c'lsnrctl start'//启动oracle数据库监听
su - oracle -c'/u01/oracle/product/ora10g/bin/dbstart start'//启动oracle数据库实例
su - oracle -c'/opt/tomcat/apache-tomcat-6.0.20/bin/startup.sh'//启动tomcat服务器的配置。

3、reboot系统,oracle数据库与tomcat服务器就可以自动启动了。

posted @ 2012-08-31 10:04 Glorin 阅读(912) | 评论 (0)编辑 收藏