Category Archives: 未分类

CENTOS 6.5 YUM安装 MYSQL 5.6

 1. 查看系统里面有没有mysql 的repo

12# yum repolist all | grep mysql#

 2. 如果没有发现,则需要配置repo

   注意,如果要使用5.7 或者其他任何版本,只能有一个是 enabled=1的,其他的都得enabled=0

12345678#vim /etc/yum.repos.d/mysql-community.repo# Enable to use MySQL 5.6[mysql56-community]name=MySQL 5.6 Community Serverbaseurl=http://repo.mysql.com/yum/mysql-5.6-community/el/6/$basearch/enabled=1gpgcheck=1gpgkey=

#vim /etc/yum.repos.d/mysql-community.repo

# Enable to use MySQL 5.6

[mysql56-community]

name=MySQL 5.6 Community Server

baseurl=http://repo.mysql.com/yum/mysql-5.6-community/el/6/$basearch/

enabled=1

gpgcheck=1

gpgkey=

3. 再看看是否存在mysql的repo

12# yum repolist enabled | grep mysqlmysql56-community     MySQL 5.6 Community Server                             214

   ok,说明已经有了,下面就可以安装mysql5.6了

 # yum install mysql-community-server  –nogpgcheck

漫长等待,等待 complete ;

记录一次 LINUX 病毒处理

1、查找文件修改(新增的二进制文件)

cd /bin
find . -name ‘*’ -mtime 0 -ls -type f

找到时间在 20201016 07:48前后一个小时的文件

2、查找调用的脚本
cd /etc/
find . -name ‘*’ -mtime 0 -ls -type f
查找这个里面修改的文件

如果是脚本,检查脚本内容是不是被修改了,修改的了会是执行一个文件

找到文件的路径
mv文件到/opt/badfile

注意,汇总所有机器的结构,相互检查文件

病毒的方式就是
修改crontab 定期执行
修改启动脚本或者systemd脚本,让开机或者定期执行

处理完成后重启机器,监控crontab执行的脚本

后期观察

(转)测试备库应用主库日志时有无using current logfile选项的区别 [复制链接]

原文 http://www.itpub.net/thread-1810379-1-1.html

测试备库应用主库日志时,alter database recover managed standby database语句中,有无using current logfile选项的区别


一、配置信息
库版本:11.2.0.1
DG保护模式:最大性能
DG配置方式:物理备库 LGWR ASYNC

详细如下:
主库配置信息:
[oracle@db u01]$ sqlplus / as sysdba
–库版本11.2.0.1
SQL*Plus: Release 11.2.0.1.0 Production on Sat Aug 17 13:31:33 2013
Copyright (c) 1982, 2009, Oracle.  All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 – Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

–主库状态是open
SQL> select status from v$instance;
STATUS
————
OPEN

–主库配置了standby redo
SQL> select group#,thread#,sequence#,status from v$standby_log;
    GROUP#    THREAD#  SEQUENCE# STATUS
———- ———- ———- ———-
         4          0          0 UNASSIGNED
         5          0          0 UNASSIGNED
         6          0          0 UNASSIGNED
         7          0          0 UNASSIGNED

–主库的配置信息
SQL> set lines 200
SQL> col name for a20
SQL> col value for a100
SQL> select name,value from v$parameter where name in (‘log_archive_dest_1′,’log_archive_dest_2’);
NAME                 VALUE
——————– —————————————————————————————————-
log_archive_dest_1   location=/u01/arclog/ valid_for=(all_logfiles,all_roles) db_unique_name=orcl
log_archive_dest_2   service=db2 lgwr async valid_for=(online_logfiles,primary_role) db_unique_name=db2

–主库的保护模式及open模式
SQL> select protection_mode,database_role,protection_level,open_mode from v$database;
PROTECTION_MODE      DATABASE_ROLE    PROTECTION_LEVEL     OPEN_MODE
——————– —————- ——————– ——————–
MAXIMUM PERFORMANCE  PRIMARY          MAXIMUM PERFORMANCE  READ WRITE


备库配置信息:
[oracle@db2 ~]$ sqlplus / as sysdba
–库版本11.2.0.1
SQL*Plus: Release 11.2.0.1.0 Production on Sat Aug 17 13:36:13 2013
Copyright (c) 1982, 2009, Oracle.  All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 – Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

–备库状态也是open,11g DG的备库是可以open的
SQL> select status from v$instance;
STATUS
————
OPEN

–备库配置了standby redo
SQL> select group#,thread#,sequence#,status from v$standby_log;
    GROUP#    THREAD#  SEQUENCE# STATUS
———- ———- ———- ———-
         4          1         47 ACTIVE
         5          0          0 UNASSIGNED
         6          0          0 UNASSIGNED
         7          0          0 UNASSIGNED

–备库的配置信息
SQL> set lines 200
SQL> col name for a20
SQL> col value for a100
SQL> select name,value from v$parameter where name in (‘log_archive_dest_1′,’log_archive_dest_2’);
NAME                 VALUE
——————– —————————————————————————————————-
log_archive_dest_1   location=/u01/arclog/  valid_for=(all_logfiles,all_roles)  db_unique_name=db2
log_archive_dest_2   service=orcl lgwr async valid_for=(online_logfiles,primary_role)  db_unique_name=orcl

–备库的保护模式及open模式
SQL> select protection_mode,database_role,protection_level,open_mode from v$database;
PROTECTION_MODE      DATABASE_ROLE    PROTECTION_LEVEL     OPEN_MODE
——————– —————- ——————– ——————–
MAXIMUM PERFORMANCE  PHYSICAL STANDBY MAXIMUM PERFORMANCE  READ ONLY




二、测试备库应用redo时有无using current logfile的区别
1.无using current logfile
备库执行:
SQL> alter database recover managed standby database disconnect from session;
Database altered.
SQL> col name for a50
SQL> col value for a50
SQL> select name,value,datum_time from v$dataguard_stats;
NAME                                               VALUE                                              DATUM_TIME
————————————————– ————————————————– ——————————
transport lag                                      +00 00:00:00                                       08/17/2013 13:57:07
apply lag                                          +00 00:40:55                                       08/17/2013 13:57:07
apply finish time                                  +00 00:00:05.000
estimated startup time                             22
–查出备库跟主库间有40分钟的应用延迟(我在主库执行alter database recover managed standby database cancel;后,去吃饭了)

主库切换一下redo
SQL> alter system archive log current;
System altered.
再查备库与主库的延迟:
SQL> select name,value,datum_time from v$dataguard_stats;
NAME                                               VALUE                                              DATUM_TIME
————————————————– ————————————————– ——————————
transport lag                                      +00 00:00:00                                       08/17/2013 14:01:14
apply lag                                          +00 00:00:21                                       08/17/2013 14:01:14
apply finish time                                  +00 00:00:00.001
estimated startup time                             22
–这次apply lag 是21秒了,我觉得主库切换redo后,备库才会应用日志。我们不切换主库redo,等一小会儿,再查备库与主库的应用延迟
SQL> select name,value,datum_time from v$dataguard_stats;
NAME                                               VALUE                                              DATUM_TIME
————————————————– ————————————————– ——————————
transport lag                                      +00 00:00:00                                       08/17/2013 14:03:45
apply lag                                          +00 00:02:52                                       08/17/2013 14:03:45
apply finish time                                  +00 00:00:01.000
estimated startup time                             22
–这次成了2份52秒了。
主库切换一下redo,备库马上查看跟主库的应用延迟:
SQL> alter system archive log current;
System altered.
以下备库连查了三次:
SQL> select name,value,datum_time from v$dataguard_stats;
NAME                                               VALUE                                              DATUM_TIME
————————————————– ————————————————– ——————————
transport lag                                      +00 00:00:00                                       08/17/2013 14:04:53
apply lag                                          +00 00:03:59                                       08/17/2013 14:04:53
apply finish time                                  +00 00:00:01.000
estimated startup time                             22
SQL> select name,value,datum_time from v$dataguard_stats;
NAME                                               VALUE                                              DATUM_TIME
————————————————– ————————————————– ——————————
transport lag                                      +00 00:00:00                                       08/17/2013 14:04:56
apply lag                                          +00 00:04:01                                       08/17/2013 14:04:56
apply finish time                                  +00 00:00:01.000
estimated startup time                             22
SQL> select name,value,datum_time from v$dataguard_stats;
NAME                                               VALUE                                              DATUM_TIME
————————————————– ————————————————– ——————————
transport lag                                      +00 00:00:00                                       08/17/2013 14:05:03
apply lag                                          +00 00:00:00                                       08/17/2013 14:05:03
apply finish time                                  +00 00:00:00.000
estimated startup time                             22
在主库切换redo后,备库跟主库的延迟没有立即归零,而是在继续增大,这充分证明了在主库切换归档后(此时备库也产生新归档),备库才会开始应用日志。
如果主库一直不切换redo,备库跟主库的差距会越来越大。

也许视图不能说明什么,我们进行DML操作,模拟下实际应用.
主库建张表:
SQL> create table t (id number);
Table created.
主库切日志:
SQL> alter system archive log current;         
System altered.

主库切日志后,备库能查到新建的表:
SQL> select * from t;
        ID
———-
         0
主库插入数据,并提交
SQL> insert into t values (1);
1 row created.
SQL> commit;
Commit complete.

备库能查数据:
SQL> select * from t;
        ID
———-
         0
SQL> select * from t;
        ID
———-
         0
主库提交后,备库查询若干次,都查不到数据!

再查备库与主库的应用延迟:
SQL> select name,value,datum_time from v$dataguard_stats;
NAME                                               VALUE                                              DATUM_TIME
————————————————– ————————————————– ——————————
transport lag                                      +00 00:00:00                                       08/17/2013 14:23:59
apply lag                                          +00 00:02:50                                       08/17/2013 14:23:59
apply finish time                                  +00 00:00:00.001
estimated startup time                             22
备库被主库拉开了2分50秒。

主库再切日志:
SQL> alter system archive log current;         
System altered.
备库能查到了:
SQL> select * from t;   
        ID
———-
         1
呵呵,无using current logfile感觉很像是ARCH ASYNC。


2.有using current logfile
备库先退出应用主库日志:
SQL> alter database recover managed standby database cancel;
Database altered.


备库使用using current logfile方式应用主库日志:
SQL> alter database recover managed standby database using current logfile disconnect from session;
Database altered.


检查备库与主库的应用延迟:
SQL> select name,value,datum_time from v$dataguard_stats;
NAME                                               VALUE                                              DATUM_TIME
————————————————– ————————————————– ——————————
transport lag                                      +00 00:00:00                                       08/17/2013 14:34:54
apply lag                                          +00 00:00:00                                       08/17/2013 14:34:54
apply finish time                                  +00 00:00:00.000
estimated startup time                             22
没用apply lag,而且一直是没有延迟。
SQL> select name,value,datum_time from v$dataguard_stats;
NAME                                               VALUE                                              DATUM_TIME
————————————————– ————————————————– ——————————
transport lag                                      +00 00:00:00                                       08/17/2013 14:35:00
apply lag                                          +00 00:00:00                                       08/17/2013 14:35:00
apply finish time                                  +00 00:00:00.000
estimated startup time                             22

主库插入数据测试:
SQL> insert into t values (2);
1 row created.
SQL> commit;
Commit complete.

无须等主库切换归档,备库很快就就能查到:
SQL> select * from t;
        ID
———-
         1
         2



三、参考官方文档
关于USING CURRENT LOGFILE官方文档有如下解释:
Specify USING BACKUP CONTROLFILE if you want to use a backup control file instead of the current control file.
–备库的控制文件确实是从主库备份来的。
USING CURRENT LOGFILE Clause Specify USING CURRENT LOGFILE to invoke real-time apply, which recovers redo from the standby redo log files as soon as they are written, without requiring them to be archived first at the physical standby database.
–这句写得很明白,大体意思是:指定USING CURRENT LOGFILE会调用实施应用,它从standby redo中还原信息并尽快写到数据文件中,不需要在备库上先归档。
另外在官方文档上还看到了这句话:
FINISH  Specify FINISH to complete applying all available redo data in preparation for a failover.
所以,在failover时,执行alter database recover managed standby database finish;是有必要的。




四、总结
无using current logfile感觉像下面这张图,主库切换日志后,备库才从归档文件挖掘出变化,然后应用到库文件中。


而using current logfile感觉像下面这张图,备库根据接收到的redo信息,实时应用到备库上,即便是最大性能。



测试应用日志usingcurrent

(转)oracle11g dataguard 备库数据同步的检查方法


本文链接:https://blog.csdn.net/ydwheel/article/details/70124908
概述:

一、环境
     主库:
      ip地址:192.168.122.203
      oracle根目录:/data/db/oracle
      SID:qyq
      数据文件路径/data/db/oracle/oradata/qyq
      归档文件路径:/data/db/oracle/archive’

     备库:
      ip地址:192.168.122.204
      oracle根目录:/data/app/oracle
      SID:qyq
      数据文件路径/data/app/oracle/oradata/qyq
      归档文件路径:/data/app/oracle/archive’

二、备库不同步的问题检查方法

1、检查主备两边的序号
select max(sequence#) from v$log;   —检查发现一致

2、备库执行,查看是否有数据未应用
select name,SEQUENCE#,APPLIED from v$archived_log order by sequence#;

select SEQUENCE#,FIRST_TIME,NEXT_TIME ,APPLIED from v$archived_log order by 1;

3、检查备库是否开启实时应用
select recovery_mode from v$archive_dest_status where dest_id=2;

4、检查备库状态
select switchover_status from v$database; –发现状态not allowed 

3、看看进程MRP是否存在
 ps aux|grep mrp      –发现进程不存在

4、如果不存在执行以下:
alter database recover managed standby database using current logfile disconnect;

alter database recover managed standby database disconnect from session;  –后台执行

alter database recover managed standby database –前台执行,执行这个可以看到报错的情况

如果有报错,查看alert日志和log.xml日志 

5、验证是否正常
select process,status from v$managed_standby;
select process,status,sequence# from v$managed_standby;

如果看到mrp0正常

6、以上步骤处理好后,如果数据还不正常,接着处理

关闭备库,接着处理:
把主库上 undotbs01.dbf 文件,物理的重拷到备库机上以前undotbs01.dbf 所在目录下;

$scp /data/oracle/oradata/voip/undotbs01.dbf   192.168.122.204:/data/oracle/oradata/voip

再在主库上重新生成一个standby control file ,拷到备库机上相应目录下,

alter database create standby controlfile as ‘/data/oracle/oradata/voip/qyqdg01.ctl’

$scp /data/oracle/oradata/voip/qyqdg01.ctl   192.168.122.204:/data/oracle/oradata/voip
$ mv qyqdg01.ctl  control01.ctl
$ cp control01.ctl /data/oracle/flash_recovery_area/qyq/
$cd /data/oracle/flash_recovery_area/qyq/
$ mv control01.ctl  control02.ctl

接着
STARTUP NOMOUNT;
ALTER DATABASE MOUNT STANDBY DATABASE;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;


session恢复完成后,重启打开备库;

alter database open read only;
————————————————
版权声明:本文为CSDN博主「dingding_2017」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/ydwheel/article/details/70124908

(转)物理standby database的日常维护

1.停止Standby

select process, status from v$managed_standby; –查看备库是否在应用日志进行恢复

alter database recover managed standby database cancel;
shutdown immediate; 

2.切换到只读模式

—-由shutdown模式切换到只读模式-

——startup nomount;
alter database mount standby database;
alter database open read only;-

—-由应用日志模式切换到只读模式——-alter database recover managed standby database cancel; —

取消日志应用
alter database open read only;

 3.切换回管理恢复模式

startup nomount;
alter database mount standby database;
alter database recover managed standby database disconnect from session; — 启动日志应用alter database recover managed standby database using current logfile disconnect from session; 

4.主库和备库之间角色切换

4.1 主库切换为备库
alter database commit to switchover to physical standby;alter database commit to switchover to physical standby with session shutdown;– 主库有会话连接的时候
shutdown immediate
startup nomount;
alter database mount standby database;
alter database recover managed standby database disconnect from session; 

4.2 从库切换为主库alter database commit to switchover to primary;
shutdown immediate;
startup
alter system switch logfile; 

5.备库自动使用主库传过来的日志进行恢复

alter database recover automatic standby database; 

6.更改保护模式

alter database set standby database to maximize protection;
alter database set standby database to maximize availability;
alter database set standby database to maximize performancen;

 7.取消自动恢复模式

alter database recover managed standby database cancel;
alter database recover managed standby database finish;
alter database recover managed standby database finish force;