Oracle RAC on Extended Cluster

January 4, 2019 1 comment

I have recently worked with Oracle RAC on Extended Cluster, and I would like to share here some knowledge I acquired regarding this technology.

This is an alternative to Oracle Data Guard, which provides an almost immediate replication method between two sites. However, it requires the availability of a fast network between the two sites, for the interconnect.

Let’s imagine the following scenario: We have a production database hosted in our main building. Our enterprise has also a data center in another building, which is located 10 km away. How can we install a solution to replicate the data from our primary site to our standby site?

Here we have different options: we can install and configure DataGuard, creating a standby database in our second building. We can even use Active Dataguard to allow the standby database to the open in order to perform queries or reports.

But we can also have RAC on Extended Cluster. In this case, the database will be integrated in a RAC, where node1 will be our main site, and node2 will be our secondary site.

The application will then access only to the primary site, as it was done normally. The secondary site will have a separate storage, and the data will be replicated through the interconnect. This requires that the bandwidth for the interconnect is high enough, but the recovery would be almost immediate in case of failure, as the data will be always be available after commit in both sites. This is not the case on Dataguard, as the data is replicated only after the generation of archivelogs.

But then we face a new problem, how do we solve brain splitting? If we have two nodes, and the interconnect has a failure but both nodes are up, which node will know that he is the node that needs to be up, and which node needs to be shutdown?

To solve this problem, Voting Disk has a major importance in this scenario. We need a third server allocating a Voting Disk, and visible from both Oracle servers. This voting disk will act as a third vote to decide which server will remain up in case of failure, and which server is unavailable.

This third server can be an Oracle server, and we would allocate the voting disk in an ASM instance. But it is also possible to use an inexpensive NFS device for this purpose.

To do this, you can use the following command:

[root@nodo1]# crsctl query css votedisk
## STATE File Universal Id File Name Disk group
— —– —————– ——— ———
1. ONLINE xxxxxxxxxxxx (/nfs/cluster1/vote1) []
2. ONLINE xxxxxxxxxxxxx (/nfs/cluster2/vote2) []

Then, add the third voting disk on cluster node 3 (the mount point must be created previously):

[root@nodo1 /]# crsctl add css votedisk /nfs/cluster3/vote3
Now formatting voting disk: /nfs/cluster3/vote3.
CRS-4603: Successful addition of voting disk /nfs/cluster3/vote3.

Using this method, we will be able to provide service in the standby database immediately in case the primary database fails, as the standby database will always be available. After all, it’s a RAC.

Additionally, we can use the standby node as primary node for another database, using the primary site as a standby site for this second database. By doing this, we will use more effectively the resources of the server.

Advertisements

Oracle Jobs

If you want to schedule a job in the Oracle Database to execute a certain task regularly, basically you can use one of the following methods:

1. Oracle Scheduler (DBMS_SCHEDULER):

DBMS_SCHEDULER is a powerful feature that you can use to schedule jobs on the database, which can be very useful for certain DBA tasks like indexes rebuilding, backups checking or data consistency.

To view the information about currently running jobs, you can execute this query:

SELECT * FROM ALL_SCHEDULER_RUNNING_JOBS;

With this query you can check all the scheduled jobs into the database:

SELECT JOB_NAME, STATE FROM DBA_SCHEDULER_JOBS;

It is a very strong feature and very recommended currently. If you want to find more information about the scheduler, check the Oracle documentation in this link:

https://docs.oracle.com/database/121/ARPLS/d_sched.htm

2. Oracle Jobs (DBMS_JOB):

DBMS_JOB is a deprecated feature but you can still use it even in Oracle 12c, even if it started in Oracle 7!

The DBMS JOB feature is a lot less intuitive to use, although some DBAs state that it is more flexible. In any case, either if you want to take advantage of its flexibility or if you need to understand how it works because your database already uses this feature, it is another option.
You can find the Oracle documentation here:

https://docs.oracle.com/database/121/ARPLS/d_job.htm#ARPLS66577

And a very good and practical post explaining how to use DBMS_JOB:

http://www.orafaq.com/node/871
3. Crontab (Unix/Linux) / Windows Task Scheduler

The third option is to externalize the task execution to the Operating System, so that the tasks are executed through a .sh in Unix, or a .bat in Windows, executing later a .sql to the database.

This method is easier to manage if you are already using crontab or Task Scheduler for other tasks not related with the database, but the disadvantage is that it is node dependent so it can be a problem in the case of Oracle RAC.
Do you know any other method to schedule jobs in Oracle? What is your prefered one?

Create new default temporary tablespace

To create new temporary tablespace and set it as default, follow these steps:

1. Check the path of the current tempfiles to reuse the path:
SELECT NAME FROM V$TEMPFILE;

2. Create the new temporary tablespace:
CREATE TEMPORARY TABLESPACE TEMP_MARIO
TEMPFILE ‘/your_path/tempfile_name’;

or if you have OMF just:

CREATE TEMPORARY TABLESPACE TEMP_MARIO;

3. Establish this temporary tablespace as default:

ALTER DATABASE DEFAULT TEMPORARY TABLESPACE TEMP_MARIO;

4. Check that the change has been made:
SELECT *
FROM database_properties
WHERE property_name like ‘%TEMP%TABLESPACE’;

Categories: DBA's day, oracle

Incremental restore from primary database to standby database

January 21, 2016 Leave a comment

If we have Dataguard, either with physical or logical standby, our databases will always be synchronized and we will be able to do switchover whenever we want.

Or not… maybe when we want to do a switchover, we notice that the standby database hasn’t been synchronized in months, and we need to restore the synchronization as soon as possible.

If the gap resolution is not an option, we will have to use RMAN in order to perform this operation. The steps will be the following ones:

1. On standby site, identify the minimum SCN used by all the datafiles:

SQL> select min(CHECKPOINT_CHANGE#) from v$datafile_header;

MIN(CHECKPOINT_CHANGE#)
———————–
262044906

2. On primary site, take an incremental backup of the database using a number a bit smaller than the smallest SCN obtained.

backup as compressed backupset incremental from scn 262044600 database format ‘/opt/oracle/install/restore_syncr/full_backup_mario_%U’;

3. Take also a backup of the controlfile:

backup as copy current controlfile format ‘/opt/oracle/install/restore_syncr/backup_control_file_mario’;

4. Copy the files to standby site (scp, ftp, diskettes)

5. Execute the following commands on RMAN in order to apply the incremental backup:

shutdown immediate;
startup force nomount;
restore standby controlfile from ‘/opt/oracle/install/restore_syncr/backup_control_file_mario’ ;
alter database mount;
catalog start with ‘+DATA/mario/datafile’ ;
catalog start with ‘/opt/oracle/install/restore_syncr/’ ;
switch database to copy ;

run {
allocate channel a0 device type disk ;
allocate channel a1 device type disk ;
allocate channel a2 device type disk ;
allocate channel a3 device type disk ;
allocate channel a4 device type disk ;
allocate channel a5 device type disk ;
allocate channel a6 device type disk ;
allocate channel a7 device type disk ;
allocate channel a8 device type disk ;
allocate channel a9 device type disk ;

recover database ;
}

6. Start the MRP process:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT ;

7. Enjoy your synchronized database and make sure that you don’t have to restore it again

How to read Oracle Datafiles without Oracle RDBMS

December 3, 2014 1 comment

In the following post we will explain how to access to the information of Oracle datafiles without the original database, only with the database files.

This is particularly useful in case that you had some kind of disaster and the information has to be recovered at any cost. Of course, making a restore with RMAN, Data Pump or other methods would be desirable… but we all know that some people just work with databases in production without a backup system right?

If you ask Oracle support how to make a recovery ONLY with some datafiles, they will tell you that this is impossible. However, by definition these files contain information, although it is encrypted. Let’s see how can we access to this information:

1. Trying to restore into another database.

There is a slight that you are able to restore a datafile from one database into another, just having the .dbf. The concept is that you need to modify the header of this datafile, to fool the database and make it belive that the datafile belongs to it.

You will still need a foresnic tool to modify the datafile and addapt it to a new database. But the advantage is that you will be able to make a clean export and restore it in a new database if you are successful.

Personally, I have never succeded with this method, although it would be technically possible.

2. DBF Viewer and Editor

There is an application for Windows that you can use to read directly the datafiles using ODBC or BDE. It’s called DBF Viewer and Editor, and you can find more information here:

http://dbf-viewer-editor.com/read-oracle-dbf-file.html

The license costs 71€, but you can try it for free, although you won’t be able to read the whole datafile.

3. BBED

For many years, BBED has been considered a secret tool, only known by a few, because it allows not only to read directly from datafiles, but also to write on them.

Nowdays, it is not included in Oracle installations anymore, but you can still use it on older versions.

The advantage of BBED is that it’s a free tool. It is really complex, and even if you are able to access the data, you can’t read this information easily, and much less perform selects. But if the information is really critical, and you don’t have any kind of backups, this could be a really valuable option.

I have personally used this tool, and I can assure that it works.

For more information, you can find a full explanation in this link:

http://orafaq.com/papers/dissassembling_the_data_block.pdf

Please keep in mind that this is the last resource, in case that restoring with RMAN or other backup methods is completely impossible.

Never try this tools in production, because overwritting a datafile will probably cause a database corruption, and you won’t be able to work with the database anymore. You should always work with a copy of the datafile.

Of course, there are more datafile foresnic methods. If you have worked with other programs and you have a better solution for this problem, please don’t hesitate to make a comment and share your knowledge with us.

Changing sys password in RAC databases

May 24, 2011 5 comments

If you ever have worked with a RAC database, and you have changed a normal user password, you will notice that it has no difference between a single instance database. You just have to perform “ALTER USER xxx IDENTIFIED BY yyyy” and your password will be changed.

However, today I had a problem with a RAC database. I had to change the SYS password, and I did it the same way I would do in a single-instance database. But when I tried to connect with sys user, the error “ORA-01017: invalid username/password; logon denied” appeared. What I was doing wrong?

After a few thoughts, I found the solution. SYS password is instance specific in RAC databases, so you have to change it in every single instance. That’s all.

Removing an Oracle Instance in silent mode

February 14, 2011 3 comments

This post will be simple but really efective. If you want to delete an instance in silent mode, without using any GUI, you just have to write the following as oracle user:

 

dbca -silent -deleteDatabase -sourceDB YOUR_DATABASE

 

I hope you will find this command as useful as it is for me 🙂

Categories: linux, oracle Tags: ,