Sometimes we need to change our database. In this case we have to migrate users and their grants to the new database server.
Here is a procedure for this issue
1- Prepare grant sqls
[root@olddb ~]# mysql -uroot -pmypass -s -N << EOF > showgr.sql
select distinct CONCAT('show grants for "', user, '"@"', host, '";') as query from mysql.user;
showgr.sql looks like :
[root@olddb ~]# head showgr.sql
show grants for "USER1"@"xxx.xxx.xxx.xxx";
show grants for "USER2"@"xxx.xxx.xxx.xxx";
show grants for "USER3"@"xxx.xxx.xxx.xxx";
Let’s create grant sqls running showgr.sql against to the old database.
[root@olddb ~]# mysql -uroot -N -ppmypass -s -r < showgr.sql > grant.sql
Unfortunately MySQL creates grant sql without “;” at the end. To add “;” at the end of every line we use sed.
[root@olddb ~]# more grant.sql |sed 's/$/;/g' > grants.sql
2- SCP file and import it!
Now we have a list of grants for importing too the new one.
[root@olddb ~]# scp grants.sql user@newdb:/tmp/
Now we can import grant file on the new host
[root@newdb ~]# mysql -uroot -pmypass < grants.sql
ORACLE Instance ORCL - Can not allocate log, archival required
Thread 1 cannot allocate new log, sequence xxx
Checkpoint not complete
These messages are written to alert.log when the database wants to reuse a redo log file but it can not do. This is related with
1- ) Not finished checkpointing (DBWR) or
2- ) ARCH process can not copy the redo log file to the archive destination.
Oracle wants to reuse log file but current checkpoint is in that log file. The database halts until checkpoint completion or archiving activity finishes. So Oracle waits until reusing redo log file safely.
As you see one reason is slow DBWR. OK, how can we make faster DBWR?
- You can use multiple DBWR processes
- Enable ASYNC I/O : For RHEL , you can verify if relink libaio with your Oracle binary using ldd and nm commands. Verifying Asynchronous I/O Usage.
- You can use DBWR slaves if ASYNC I/O is not supported.
Adding more redo log files can also solve this issue. This operation may create more room for DBWR as you guess.
Increasing size of redo log files can also help you. Like adding more redo log files, increasing size of them give you more time to reuse redo log file.
When you want to enable fast start failover, you may get “ORA-16651: requirements not met for enabling fast-start failover”.
1-) Check if flashback is enable
select flashback_on from v$database;
If this returns NO, then enable it using “alter database flashback ON;” command.
2-) Check FastStartFailoverTarget parameter
You can set it using these commands :
PS: DBA is Primary, DBB is Standby database
edit database ‘DBA’ set property FastStartFailoverTarget=’DBB’;
edit database ‘DBB’ set property FastStartFailoverTarget=’DBA’;
You can monitor your RMAN session using v$session_longops view.
Here is a script :
(SOFAR / TOTALWORK) * 100 done,
SYSDATE + TIME_REMAINING / 3600 / 24 EST_END_TIME,
WHERE TOTALWORK > SOFAR AND OPNAME LIKE '%backup%' AND OPNAME LIKE 'RMAN%'
When mysqld crashes before flushes the log , you may get this error and replication can not resume.
This can be shown like when “show slave status” performed:
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: ‘Could not find first log file name in binary log index file’
For solution :
Suppose that you have a Master-Master Replication on HostA and HostB.
1- stop slave;
1- stop slave;
After all you can set up replication between them using this method https://hsnyrd.wordpress.com/2013/07/15/setting-up-master-slave-mysql-replication/