A materialized view in Oracle is a database object that contains the results of a query.They are local copies of data located remotely, or are used to create summary tables based on aggregations of a table’s data.
A materialized view can query tables, views, and other materialized views.
A materialized view, or snapshot as they were previously known, is a table segment whose contents are periodically refreshed based on a query, either against a local or remote table.
Syntax
CREATE MATERIALIZED VIEW view-name BUILD [IMMEDIATE | DEFERRED] REFRESH [FAST | COMPLETE | FORCE ] ON [COMMIT | DEMAND ][[ENABLE | DISABLE] QUERY REWRITE] AS SELECT …;
Methods
BUILD
IMMEDIATE : The materialized view is populated immediately.This option is default one.
DEFERRED : The materialized view is populated on the first requested refresh.
Refresh Types
FAST: A fast refresh is attempted only there is a change in the base table. If materialized view logs are not present against the source tables in advance, the creation fails. To maintain the history of change in the base table, it is known as materialized view log.It is named as MLOG$_<base_table>. Materialized view log will be located in the source database in the same schema as the master table. Refresh fast will perform refresh according to the changes that occurred in the master table.
COMPLETE: The table segment supporting the materialized view is truncated and repopulated completely using the associated query.
FORCE: A fast refresh is attempted. If one is not possible a complete refresh is performed.
ON COMMIT : The refresh is triggered by a committed data change in one of the dependent tables.
ON DEMAND : The refresh is initiated by a manual request or a scheduled task.
GRANT CREATE MATERIALIZED VIEW TO INDIA;
Grant succeeded.
GRANT CREATE DATABASE LINK TO INDIA;
Grant succeeded.
Creating Database link to point remote database
SQL> CREATE DATABASE LINK PROD_LINK CONNECT TO ph IDENTIFIED BY ph USING 'orcl';
Database link created.
COMPLETE REFRESH
Creating Materialized View
SQL> CREATE MATERIALIZED VIEW dept_mv BUILD IMMEDIATE REFRESH COMPLETE AS SELECT * FROM ph.emp@PROD_LINK;
Materialized view created.
SQL> select * from emp;
NO NAME SALARY
---------- -------------------- ----------
1 apple 20000
2 orange 23000
3 mango 32000
Table Data present in Remote database
SQL> insert into emp values (6,'ice',30000);
1 row created.
SQL> commit;
Commit complete.
SQL> select rowid,no,name,salary fromdept_mv;
ROWID NO NAME SALARY
------------------ ---------- -------------------- ----------
AAAR36AABAAAbURAAA 1 apple 20000
AAAR36AABAAAbURAAB 2 orange 23000
AAAR36AABAAAbURAAC 3 mango 32000
Manually using complete refresh using the DBMS_VIEW package
SQL> execute DBMS_MVIEW.REFRESH( LIST => 'dept_mv', METHOD => 'C' );
PL/SQL procedure successfully completed.
SQL> select rowid,no,name,salary from dept_mv;
ROWID NO NAME SALARY
------------------ ---------- -------------------- ----------
AAAR36AABAAAbURAAD 1 apple 20000
AAAR36AABAAAbURAAE 2 orange 23000
AAAR36AABAAAbURAAF 3 mango 32000
AAAR36AABAAAbURAAG 6 ice 30000
DEFERRED
Initially drop the existing materialized view
SQL> drop MATERIALIZED VIEW dept_mv;
Materialized view dropped.
Thank you for giving your valuable time to read the above information. If you want to be updated with all our articles send us the Invitation or Follow us:
In this article we are going to see RMAN recovery through RESETLOGS.
What does a RESETLOGS do?
Archives the current online redo logs (if they are accessible) and then erases the contents of the online redo logs and resets the log sequence number to 1.
Creates the online redo log files if they do not currently exist.
Updates all current datafiles and online redo logs and all subsequent archived redo logs with a new RESETLOGS SCN and time stamp.
The Recovery through Resetlogs feature provides the following benefits:
There is no need to perform a full backup after an incomplete recovery.There is no need to recreate a new standby database after a failover operation.
You can take incremental backups based on full backups of a previous incarnation when you use RMAN.
Block media recovery can restore backups from parent incarnation backups and recover the corrupted blocks through a RESETLOGS operation.
You can use the newly generated logs with an earlier incarnation of the database.
Step 1:- Check the log_archive format as ‘%r’
SQL> show parameter log_archive_format
Note : To perform recovery through RESETLOGS you must have all archived logs generated after the most recent backup. The database would not start if you remove the %r from the log archive format specification.
Oracle 10g introduces a new format specification for archived log files. This new format avoids overwriting archived redo log files with the same sequence number across incarnations.The format specification of the log_archive_format string “%”r represents the resetlogs id. It will ensure that a unique name is constructed for the archived redo log file during RMAN restore and as well as restoring via SQL*plus auto recovery mode.
What is an incarnation?
A database incarnation is created whenever you open the database with the RESETLOGS option.
The Current incarnation is the one in which the database is running at present
The incarnation from which the current incarnation branched after a ALTER DATABASE OPEN RESETLOGS was performed is called the Parent incarnation.
If you want to go back to some SCN which is not part of the Current database incarnation, we need to use the RESET DATABASE TO INCARNATION
command as shown in the example below
Step 2:-Let us check what the current incarnation of the database
[oracle@localhost scripts]$ rman target /
Recovery Manager: Release 19.0.0.0.0 – Production on Sun Jan 31 18:39:21 2021
Version 19.10.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.
connected to target database: INBAA (DBID=936024966)
RMAN> list incarnation of database;
using target database control file instead of recovery catalog
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
Step 4:- Now, let us make a change in the database which we will then try to undo by restoring and recovering the database to a point in time before the media failure or as in this case, a wrong transaction has happened.
Simulate the wrong DML execution,
SQL> conn inba/inba
Connected.
SQL> create table student(id number);
Table created.
SQL> begin
for i in 1 .. 100000 loop
insert into student values(1);
end loop;
end;
/
SQL> select count(*) from student;
COUNT(*)
100000
SQL> delete from student where rownum < 1001;
1000 rows deleted.
SQL> commit;
Commit complete.
SQL> select count(*) from student;
Recovery Manager: Release 19.0.0.0.0 – Production on Sun Jan 31 18:48:55 2021
Version 19.10.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.
connected to target database: INBAA (DBID=936024966, not open)
RMAN> run
{
set until scn 2406389;
restore database;
recover database;
}2> 3> 4> 5> 6>
executing command: SET until clause
Starting restore at 31-JAN-21
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=46 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /u01/app/oracle/oradata/INBAA/system01.dbf
channel ORA_DISK_1: restoring datafile 00002 to /u01/app/oracle/oradata/INBAA/inba_02.dbf
channel ORA_DISK_1: restoring datafile 00003 to /u01/app/oracle/oradata/INBAA/sysaux01.dbf
channel ORA_DISK_1: restoring datafile 00004 to /u01/app/oracle/oradata/INBAA/undotbs01.dbf
channel ORA_DISK_1: restoring datafile 00005 to /u01/app/oracle/oradata/INBAA/inba_01.dbf
channel ORA_DISK_1: restoring datafile 00007 to /u01/app/oracle/oradata/INBAA/users01.dbf
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/recovery_area/INBAA/backupset/2021_01_31/o1_mf_nnndf_TAG20210131T143717_j1dwt60r_.bkp
channel ORA_DISK_1: piece handle=/u01/app/oracle/recovery_area/INBAA/backupset/2021_01_31/o1_mf_nnndf_TAG20210131T143717_j1dwt60r_.bkp tag=TAG20210131T143717
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:25
Finished restore at 31-JAN-21
Starting recover at 31-JAN-21
using channel ORA_DISK_1
starting media recovery
archived log for thread 1 with sequence 7 is already on disk as file /u01/app/oracle/recovery_area/INBAA/archivelog/2021_01_31/o1_mf_1_7_j1dww74c_.arc
archived log for thread 1 with sequence 8 is already on disk as file /u01/app/oracle/recovery_area/INBAA/archivelog/2021_01_31/o1_mf_1_8_j1f4jhv9_.arc
archived log for thread 1 with sequence 1 is already on disk as file /u01/app/oracle/recovery_area/INBAA/archivelog/2021_01_31/o1_mf_1_1_j1f6hkwh_.arc
archived log file name=/u01/app/oracle/recovery_area/INBAA/archivelog/2021_01_31/o1_mf_1_7_j1dww74c_.arc thread=1 sequence=7
archived log file name=/u01/app/oracle/recovery_area/INBAA/archivelog/2021_01_31/o1_mf_1_8_j1f4jhv9_.arc thread=1 sequence=8
archived log file name=/u01/app/oracle/recovery_area/INBAA/archivelog/2021_01_31/o1_mf_1_1_j1f6hkwh_.arc thread=1 sequence=1
media recovery complete, elapsed time: 00:00:07
Finished recover at 31-JAN-21
RMAN>
Step 7:- After open resetlogs,check the table count. We can now see that the deleted rows have been recovered and the number of rows in the table is now the same as before the delete operation was performed.
RMAN> alter database open resetlogs;
SQL> select count(*) from inba.student;
COUNT(*)
100000
Step 8:- Now let us check what the incarnation of the database,
RMAN> list incarnation of database;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
Step 10:- Set the SCN number of incarnation 10 and try to restore & recover the database
RMAN> run
{
set until scn 2406389;
restore database;
recover database;
}2> 3> 4> 5> 6>
executing command: SET until clause
Starting restore at 31-JAN-21
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=46 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /u01/app/oracle/oradata/INBAA/system01.dbf
channel ORA_DISK_1: restoring datafile 00002 to /u01/app/oracle/oradata/INBAA/inba_02.dbf
channel ORA_DISK_1: restoring datafile 00003 to /u01/app/oracle/oradata/INBAA/sysaux01.dbf
channel ORA_DISK_1: restoring datafile 00004 to /u01/app/oracle/oradata/INBAA/undotbs01.dbf
channel ORA_DISK_1: restoring datafile 00005 to /u01/app/oracle/oradata/INBAA/inba_01.dbf
channel ORA_DISK_1: restoring datafile 00007 to /u01/app/oracle/oradata/INBAA/users01.dbf
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/recovery_area/INBAA/backupset/2021_01_31/o1_mf_nnndf_TAG20210131T143717_j1dwt60r_.bkp
channel ORA_DISK_1: piece handle=/u01/app/oracle/recovery_area/INBAA/backupset/2021_01_31/o1_mf_nnndf_TAG20210131T143717_j1dwt60r_.bkp tag=TAG20210131T143717
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:35
Finished restore at 31-JAN-21
Starting recover at 31-JAN-21
using channel ORA_DISK_1
starting media recovery
archived log for thread 1 with sequence 7 is already on disk as file /u01/app/oracle/recovery_area/INBAA/archivelog/2021_01_31/o1_mf_1_7_j1dww74c_.arc
archived log for thread 1 with sequence 8 is already on disk as file /u01/app/oracle/recovery_area/INBAA/archivelog/2021_01_31/o1_mf_1_8_j1f4jhv9_.arc
archived log for thread 1 with sequence 1 is already on disk as file /u01/app/oracle/recovery_area/INBAA/archivelog/2021_01_31/o1_mf_1_1_j1f6hkwh_.arc
archived log file name=/u01/app/oracle/recovery_area/INBAA/archivelog/2021_01_31/o1_mf_1_7_j1dww74c_.arc thread=1 sequence=7
archived log file name=/u01/app/oracle/recovery_area/INBAA/archivelog/2021_01_31/o1_mf_1_8_j1f4jhv9_.arc thread=1 sequence=8
archived log file name=/u01/app/oracle/recovery_area/INBAA/archivelog/2021_01_31/o1_mf_1_1_j1f6hkwh_.arc thread=1 sequence=1
archived log file name=/u01/app/oracle/recovery_area/INBAA/archivelog/2021_01_31/o1_mf_1_1_j1fcq16s_.arc thread=1 sequence=1
media recovery complete, elapsed time: 00:00:08
Finished recover at 31-JAN-21
RMAN>
Step 11:- Open the database using resetlogs option
Now we open the database with the ALTER DATABASE OPEN RESETLOGS command and see that a new incarnation key (12) has been allocated to the database as the CURRENT incarnation.
SQL> alter database open resetlogs;
Database altered.
RMAN> list incarnation of database;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
Thank you for giving your valuable time to read the above information.
If you want to be updated with all our articles send us the Invitation or Follow us:
Ramkumar’s LinkedIn: https://www.linkedin.com/in/ramkumardba/
LinkedIn Group: https://www.linkedin.com/in/ramkumar-m-0061a0204/
Facebook Page: https://www.facebook.com/Oracleagent-344577549964301
Ramkumar’s Twitter : https://twitter.com/ramkuma02877110
Ramkumar’s Telegram: https://t.me/oracleageant
Ramkumar’s Facebook: https://www.facebook.com/ramkumarram8
