标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-00742 ORA-01110 ORA-01555 ORA-01578 ORA-01595 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (103)
- 数据库 (1,767)
- DB2 (22)
- MySQL (77)
- Oracle (1,608)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (166)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (69)
- Oracle Bug (8)
- Oracle RAC (54)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (590)
- Oracle安装升级 (97)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (86)
- PostgreSQL (30)
- pdu工具 (6)
- PostgreSQL恢复 (9)
- SQL Server (32)
- SQL Server恢复 (13)
- TimesTen (7)
- 达梦数据库 (3)
- 达梦恢复 (1)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (39)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (22)
-
最近发表
- ORA-00756 ORA-10567故障数据0丢失恢复
- 数据库文件变成32k故障恢复
- tcp连接过多导致监听TNS-12532 TNS-12560 TNS-00502错误
- 文件系统格式化MySQL数据库恢复
- .sstop勒索加密数据库恢复
- 解决一次硬件恢复之后数据文件0kb的故障恢复case
- Error in invoking target ‘libasmclntsh19.ohso libasmperl19.ohso client_sharedlib’问题处理
- ORA-01171: datafile N going offline due to error advancing checkpoint
- linux环境oracle数据库被文件系统勒索加密为.babyk扩展名溯源
- ORA-600 ksvworkmsgalloc: bad reaper
- ORA-600 krccfl_chunk故障处理
- Oracle Recovery Tools恢复案例总结—202505
- ORA-600 kddummy_blkchk 数据库循环重启
- 记录一次asm disk加入到vg通过恢复直接open库的案例
- CHECKDB 发现了 N 个分配错误和 M 个一致性错误
- 达梦数据库dm.ctl文件异常恢复
- Oracle Recovery Tools修复ORA-00742、ORA-600 ktbair2: illegal inheritance故障
- 可能是 tempdb 空间用尽或某个系统表不一致故障处理
- 11.2.0.4库中遇到ORA-600 kcratr_nab_less_than_odr报错
- [MY-013183] [InnoDB] Assertion failure故障处理
月归档:七月 2011
mysqld_safe启动报错
使用二进制编译文件的mysqld_safe启动报错,如下:
[mysql@ECP-UC-DB1 ~]$ mysqld_safe
110707 21:31:19 mysqld_safe Logging to ‘/opt/mysql/mysqldata/ECP-UC-DB1.err’.
110707 21:31:19 mysqld_safe The file /usr/local/mysql/bin/mysqld
does not exist or is not executable. Please cd to the mysql installation
directory and restart this script from there as follows:
./bin/mysqld_safe&
See http://dev.mysql.com/doc/mysql/en/mysqld-safe.html for more information
解决方法:
su – root
mkdir /usr/local/mysql/bin
ln -s /opt/mysql/product/5.5/bin/mysqld /usr/local/mysql/bin/mysqld
再次执行mysqld_safe
[mysql@ECP-UC-DB1 ~]$ mysqld_safe
110707 21:32:37 mysqld_safe Logging to ‘/opt/mysql/mysqldata/ECP-UC-DB1.err’.
110707 21:32:37 mysqld_safe Starting mysqld daemon with databases from /opt/mysql/mysqldata
启动结果:
mysql 26885 23452 0 21:32 pts/0 00:00:00 /bin/sh /opt/mysql/product/5.5/bin/mysqld_safe
mysql 27653 26885 0 21:32 pts/0 00:00:00 /usr/local/mysql/bin/mysqld –basedir=/opt/mysql/product/5.5 –datadir=/opt/mysql/mysqldata –plugin-dir=/usr/local/mysql/lib/plugin –log-error=/opt/mysql/mysqldata/ECP-UC-DB1.err –open-files-limit=8192 –pid-file=/var/run/mysqld/mysqld.pid –socket=/var/run/mysqld/mysqld.sock –port=3306
问题存在原因:
1、mysqld_safe只认识/usr/local/mysql/bin/mysqld(也许是配置问题)
2、my.cnf只能放置在/etc/下面,不然使用–defaults-file也不能读取my.cnf文件(有疑惑)
发表在 MySQL安装配置
评论关闭
mysql 安装并启动多个实例
1、数据库实例目录
drwxrwxrwx 6 mysql mysql 4096 Jul 6 23:25 mysqldata
drwxrwxr-x 5 mysql mysql 4096 Jul 6 23:23 mysqldata1
drwxrwxr-x 5 mysql mysql 4096 Jul 6 23:27 mysqldata2
2、创建实例
/opt/mysql/product/5.5/scripts/mysql_install_db –basedir=/opt/mysql/product/5.5 –datadir=/opt/mysql/mysqldata –user=mysql
/opt/mysql/product/5.5/scripts/mysql_install_db –basedir=/opt/mysql/product/5.5 –datadir=/opt/mysql/mysqldata1 –user=mysql
/opt/mysql/product/5.5/scripts/mysql_install_db –basedir=/opt/mysql/product/5.5 –datadir=/opt/mysql/mysqldata2 –user=mysql
3、修改my.cnf文件
[mysqld_multi]
mysqld = /opt/mysql/product/5.5/bin/mysqld
mysqladmin = /opt/mysql/product/5.5/bin/mysqladmin
user = root
password = passw0rd
[mysqld3306]
port = 3306
socket = /var/run/mysqld/mysqld3306.sock
pid-file = /var/run/mysqld/mysqld3306.pid
basedir = /opt/mysql/product/5.5
datadir = /opt/mysql/mysqldata
[mysqld3307]
port = 3307
socket = /var/run/mysqld/mysqld3307.sock
pid-file = /var/run/mysqld/mysqld3307.pid
basedir = /opt/mysql/product/5.5
datadir = /opt/mysql/mysqldata1
[mysqld3307]
port = 3307
socket = /var/run/mysqld/mysqld3308.sock
pid-file = /var/run/mysqld/mysqld3308.pid
basedir = /opt/mysql/product/5.5
datadir = /opt/mysql/mysqldata2
注:其他无关参数省略,日志等文件路径也不能相同(未写明)
4、启动数据库
mysqld_multi –defaults-file=/etc/mysql/my.cnf start 3306
mysqld_multi –defaults-file=/etc/mysql/my.cnf start 3307
mysqld_multi –defaults-file=/etc/mysql/my.cnf start 3308
5、登录数据库修改root密码
mysql -S /var/run/mysqld/mysqld3306.sock
mysql -S /var/run/mysqld/mysqld3307.sock
mysql -S /var/run/mysqld/mysqld3308.sock
use mysql
UPDATE user SET password=PASSWORD(‘passw0rd’) WHERE user=’root’;
FLUSH PRIVILEGES;
说明:三个库上分别操作
6、关闭数据库
mysqld_multi –defaults-file=/etc/mysql/my.cnf stop 3306
mysqld_multi –defaults-file=/etc/mysql/my.cnf stop 3307
mysqld_multi –defaults-file=/etc/mysql/my.cnf stop 3308
7、全部启动/关闭
mysqld_multi –defaults-file=/etc/mysql/my.cnf start 3306-3308
mysqld_multi –defaults-file=/etc/mysql/my.cnf stop 3306-3308
发表在 MySQL安装配置
评论关闭
Data Guard出现gap sequence修复
一、出现gap sequence现象
备库
Fetching gap sequence in thread 1, gap sequence 710-716 Tue May 31 15:02:38 2011 FAL[client]: Failed to request gap sequence GAP - thread 1 sequence 710-716 DBID 3240478808 branch 746916894 FAL[client]: All defined FAL servers have been attempted. ------------------------------------------------------------- Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization parameter is defined to a value that is sufficiently large enough to maintain adequate log switch information to resolve archivelog gaps. -------------------------------------------------------------
主库
Tue May 31 13:50:47 2011 FAL[server]: Fail to queue the whole FAL gap GAP - thread 1 sequence 710-716 DBID 3240478808 branch 746916894
二、修复操作
1、查询备库的scn
SQL> SELECT CURRENT_SCN FROM V$DATABASE; CURRENT_SCN ----------- 1154337 --在出现意外datafile header scn不一致的时候,需要根据提示归档日志,找出最小scn
2、确定主库是否添加数据文件
SQL> select FILE#,name from v$datafile where CREATION_CHANGE#> =1154337; no rows selected
确定主库在这个scn之后是否有添加数据文件,如果添加文件,需要手工在备库添加
3、备库停止日志应用
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
4、主库增量备份并传输到备库上
主库进行增量备份
RMAN> BACKUP INCREMENTAL FROM SCN 1154337 DATABASE FORMAT '/home/oracle/xff_%U' tag 'XIFENFEI'; [oracle@localhost ~]$ scp xff* 192.168.1.30:/home/oracle/rman
说明:主库之前必须要做过rman的全备(没有全备的库,基于scn的增量备份也能够成功)
5、备库上进行恢复
RMAN> CATALOG START WITH '/home/oracle/rman'; RMAN> RECOVER DATABASE NOREDO;
说明:CATALOG START WITH是10g及其以后版本中才存在功能,没有该功能可以采用catalog或者复制主库的控制文件,rman备份放置和主库备份时相同目录实现。
6、主库上创建standby controlfile文件并传输到备库
RMAN> BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT '/home/oracle/xff_ctl.bck'; [oracle@localhost ~]$ scp xff_ctl.bck 192.168.1.30:/home/oracle/rman
创建standby controlfile两步可以需要根据实际情况考虑,大多数情况下不需要
7、备库恢复控制文件
RMAN> shutdown; RMAN> STARTUP NOMOUNT; RMAN> RESTORE STANDBY CONTROLFILE FROM '/home/oracle/rman/xff_ctl.bck'; RMAN> alter database mount;
8、清空备库日志组
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 1; 注:如果采用了standby log模式,不需要清空,如果清空会出现 SQL> ALTER DATABASE CLEAR LOGFILE GROUP 1; ALTER DATABASE CLEAR LOGFILE GROUP 1 * ERROR at line 1: ORA-19527: physical standby redo log must be renamed ORA-00312: online log 1 thread 1: '/u01/oradata/xienfei/redo01.log'
说明:如果没有采用standby log模式,有几组需要清空几组
9、备库重设flashback
SQL> ALTER DATABASE FLASHBACK OFF; SQL> ALTER DATABASE FLASHBACK ON;
10、备库重新接收并应用日志
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
三、修复成功标志
1、sql中操作
在主库中执行alter system switch logfile;
分别主备库中执行select max(sequence#) from v$archived_log;如果一致标示修复成功
2、通过alert文件
主库
PING[ARC0]: Error 3113 when pinging standby xff. Tue May 31 14:11:51 2011 Thread 1 advanced to log sequence 719 Current log# 3 seq# 719 mem# 0: /u01/oradata/xienfei/redo03.log Tue May 31 14:20:05 2011 Thread 1 advanced to log sequence 720 Current log# 1 seq# 720 mem# 0: /u01/oradata/xienfei/redo01.log Tue May 31 14:20:16 2011 ARC0: Standby redo logfile selected for thread 1 sequence 719 for destination LOG_ARCHIVE_DEST_2
备库
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION Tue May 31 15:30:37 2011 Attempt to start background Managed Standby Recovery process (xff) MRP0 started with pid=18, OS id=14704 Tue May 31 15:30:37 2011 MRP0: Background Managed Standby Recovery process started (xff) Managed Standby Recovery not using Real Time Apply parallel recovery started with 2 processes Media Recovery Log /u01/archive/1_718_746916894.arc Tue May 31 15:30:43 2011 Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION Tue May 31 15:30:52 2011 RFS[1]: Successfully opened standby log 4: '/u01/oradata/xienfei/s_redo1.log' Media Recovery Log /u01/archive/1_719_746916894.arc Media Recovery Waiting for thread 1 sequence 720
发表在 Data Guard
2 条评论