demilitarized zones (DMZ)

A DMZ is simply a place that is under your control but outside of your internal network and it a place to put servers that you want outsiders to reach but you don't want them to get to your internal network. By limiting access, you can also fine tune monitoring.

However, you would want to expose a portion of these internal applications outside your enterprise for your non-employee users like customers and vendors. For example, Oracle E-Business Suite (flagship Oracle ERP application) has some of the modules like iRecruitment, iSupplier, iStore etc.

In Oracle Application how the nodes (FND_NODES) is to exposed:

>To expose to public use the profile “Node Trust Level”

>Set node to Public/Private (Normal -> private, External -> public)

>Set "Responsibility Trust Level" profile to decide whether to expose Application Responsibility to inside or outside firewall.

Internal Applications Tier
The internal applications tier is the server configured for internal users to access Oracle E-Business Suite. It runs the following major application services:

Web and Forms Services
WebLogic Administration service, Node Manager, Oracle HTTP Server, OPMN, WebLogic Managed Servers
Concurrent Manager Services
Reports and Discoverer Services
External Applications Tier
The external applications tier is the server configured for external users for accessing Oracle E-Business Suite. It runs the following application service:

Oracle HTTP Server
WebLogic components like node manager, managed servers etc.

OPMN
Oracle Process Manager and Notification Server (OPMN) is installed and configured on every tier designated to run the web application.  OPMN provides an integrated way to manage all Oracle Application Server components.  OPMN consists of two main pieces:  the Process Manager and the Notification Server. The Process manager (PM) is the centralized process management mechanism in Oracle Application Server and is used to manage the Oracle HTTP Server. The PM starts, restarts, stops, and monitors every process it manages. It also performs death-detection and automatic restart of the processes. Oracle Notification Server (ONS) is the transport mechanism for failure, recovery, startup, and other related notifications between components in Oracle Application Server.

OHS
Oracle HTTP Server (OHS) is installed and configured on every tier that is designated to run the web application . It provides the key infrastructure required for serving the static and dynamic content generated by Oracle E Business Suite products.

Webgate is an out-of-box client which enforces OAM policies on HTTP resources. Typically, it is installed on the webserver like apache and traps all incoming http traffic before it hits core apache. In this fashion, webgate can enforce OAM policies on the http resources residing on the http server.

Oracle id related reference:
Oracle E-Business Suite 11i Configuration in a DMZ (Metalink Note 287176.1)
Oracle E-Business Suite Release 12 Configuration in a DMZ (Metalink Note 380490.1)
Oracle E-Business Suite Release 12.2 Configuration in a DMZ (Doc ID 1375670.1)

Recover a table:

In previous releases point in time recovery of a table or table partition was only possible by manually creating a point in time clone of the database.

For TSPITR, we need to specify the auxiliary destination where RMAN would create a temporary database by restoring the controlfile, SYSTEM
tablespace, UNDO tablespace, SYSAUX tablespace and finally the tablespace that needs to be recovered.

Once the temporary database is restored and recovered, RMAN automatically exports the contents of tablespace to be recovered from the
temproary tablespace to a dump file and imports this dump into the Target(Main) database where the table was dropped.


rman target /
RMAN> run
2> {
3> recover tablespace MYTS until time "to_date('2013-05-04:11:38:00','YYYY-MM:DD:HH24:MI:SS')" auxiliary destination '+FRA';
4> }


Once the import is done successfully, RMAN automatically deletes the temporary database that it had created earlier.

Now, lets connect to the main database and check if we are able to access the dropped table. But, before that, you need to bring the tablespace online.

recovering a dropped table with flashback:The recyclebin feature introduced in Oracle 10g allows you to recover dropped tables using the flashback table...to before drop command. With recyclebin, Oracle does not automatically delete dropped tables. Instead, Oracle renames dropped and their associated objects, giving them system-generated recyclebin names that begin with BIN$.

SQL> select object_name, original_name, type from recyclebin;
 OBJECT_NAME                       ORIGINAL_NAME              TYPE   
  ------------------------------    -----------------------    -------
BIN$ABCSD5   TESTING                    TABLE
select * from "BIN$ABCSD5" ;
SQL> flashback table testing to before drop;
SQL> select index_name from user_indexes where table_name = 'testing';
 alter index "recyclebin_name" rename to original_name;


New in Oracle 12c is the Multitenant Architecture, as well as the ability to restore one table from an RMAN backup.


RECOVER TABLE TEST.T1 UNTIL SCN 1853267 AUXILIARY DESTINATION '/u01/aux' REMAP TABLE 'TEST'.'T1':'T1_PREV';
recover table hari.emp until time "to_date('2018-08-14 21:53:42','yyyy-mm-dd:hh24:mi:ss')" auxiliary destination '/u01/fra';
recover table hari.emp until time "to_date('2018-08-14 21:53:42','yyyy-mm-dd:hh24:mi:ss')" auxiliary destination '/u01/fra';

run {

recover table example.test_restore of pluggable database PDB2

until time "to_date('12-01-2016 17:16:00','mm/dd/yyyy hh24:mi:ss')"

auxiliary destination '/oradata/CDB2/aux'

;

}

RMAN> run {

recover table example.test_restore of pluggable database PDB2

until time "to_date('12-01-2016 17:16:00','mm/dd/yyyy hh24:mi:ss')"

auxiliary destination '/oradata/CDB2/aux'

;

}

=================

1.Flashback features:

SHOW RECYCLEBIN;
flashback table <table> to before drop;
FLASHBACK TABLE HR.REG_HIST TO BEFORE DROP;

2.Database Point-in-Time Recovery:

3. Tablespace point-in-time recovery (TSPITR) :

4. Oracle 12c Table Point-in-time Recovery:

rman target /

RMAN> recover table emp.emp until time "to_date('2010-05-16 02:21:27','yyyy-mm-dd:hh24:mi:ss')" auxiliary destination '/u02/RC_BKP';

RMAN> recover table mm.test until time "to_date('00/17/2013 21:01:15','mm/dd/yyyy hh24:mi:ss')" auxiliary destination '/u03/app/oracle/ux' remap table mm.test:test_temp;

Redo logs Details:

Oracle writes to only one online redo log group at a time.Once the online redo log(s) in that group are filled then Oracle will switch to writing the next online redo log group, and so on in a circular fashion.

Each online redo log is assigned a unique sequence number.

We can multiplex each online redo log group. This means that each redo log group can consist of more than one online redo log file. Each file is known as a member. Each member should be located on a different disk, to protect the group from losing all of its members in the event a disk failure should occur. Oracle writes to those members in parallel, to ensure that the database is always recoverable while maintaining performance.

The online redo logs are first created when the database is created, and the database cannot live without them.If all members of the active redo log group are lost, the database crashes, and worse yet, there will be data loss.

Redo logs can have following STATUS’s (select status from v$log;):-

CURRENT – Current redo log. This implies that the redo log is active. The redo log could be open or closed.
ACTIVE – Log is active but is not the current log. It is needed for crash recovery. It may be in use for block recovery. It may or may not be archived.
INACTIVE – Log is no longer needed for instance recovery. It may be in use for media recovery. It might or might not be archived.
CLEARING – Log is being re-created as an empty log after an ALTER DATABASE CLEAR LOGFILE statement. After the log is cleared, the status changes to UNUSED.
CLEARING_CURRENT – Current log is being cleared of a closed thread. The log can stay in this status if there is some failure in the switch such as an I/O error writing the new log header.
UNUSED – Online redo log has never been written to. This is the state of a redo log that was just added, or just after a RESETLOGS, when it is not the current redo log.

Alter system switch logfile;

To switch the logfile to change the STATUS of the logfile from CURRENT to ACTIVE or INACTIVE.

"alter system checkpoint" causes the current active redo log file members inactive
by flushing dirty buffers to data files and recording SCN to data file header and control file,
so that we could drop this group.

ALTER SYSTEM SWITCH LOGFILE vs ALTER SYSTEM ARCHIVE LOG CURRENT:

Both will force a log switch but  will be different way.
ALTER SYSTEM ARCHIVELOG CURRENT is the preferred one that should be used for backup scripts.

The reason being,when you do an 'ALTER SYSTEM SWITCH LOGFILE', you get the prompt back immediately. This command performs a database checkpoint, switches to the next log, In background signals the  archiver to copy the logfile to the archive destination, and returns the prompt.This does not wait for the archive to complete.

Whereas, an 'ALTER SYSTEM ARCHIVE LOG CURRENT' does all of the above, but does not return back to the prompt until the archive is complete.This command is safer because it waits for the OS to acknowledge(ACK) that the redo log has been successfully written.

If you are running RAC, the ALTER SYSTEM ARCHIVE LOG CURRENTwill switch the logs on all RAC nodes (instances), whereas ALTER SYSTEM SWITCH LOGFILE will only switch he logfile on the instance where you issue the switch command.  Hence, ALTER SYSTEM ARCHIVE LOG CURRENT is a best practice for RAC systems.

Alter system switch logfile, tells the background processes to perform the archiving of the current redo log and returns control immediately to the session issuing the statement.

Alter system archive log current, means your server/shadow process performs the arhciving and control is only returned to the session once the archiving is complete.

It issues database checkpoint
It immediately starts writing to the next redo log
In the background, the "switch logfile" command tells the ARCH background process to copy the "old" redo log file to the redo log filesystem. 

ARCHIVE LOG CURRENT waits for the ARCHiver to complete its writing.

SWITCH LOGFILE will not wait for the ARCHiver to complete writing online redo logs to archivelog log filesystem. This is fast.

Few related queries:

set lines 200 pages 200

col GROUP for a10

col TYPE for a20

col MEMBER for a100

col IS_ for a70

select * from v$log; 1:00 PM 

select GROUP#,THREAD#,MEMBERS,STATUS from v$log;

col status for a10;

col GROUP# for 9999;

col type for a10;

col member for a85;

col IS_RECOVERY_DEST_FILE for a5;

set lines 300

select * from v$logfile; 

col status for a10;

col GROUP# for 9999;

col type for a10;

col member for a85;

col IS_RECOVERY_DEST_FILE for a5;

set lines 300

select group#,thread#,members,status,bytes from v$log; 

select * from v$logfile; 

set lines 200 pages 200

col GROUP for a10

col TYPE for a20

col MEMBER for a100

col IS_ for a70

select * from v$log;  

select GROUP#,THREAD#,MEMBERS,STATUS,MEMBERS from v$log;

select * from v$logfile; 

select member, a.group#, a.status, b.status from v$log a, v$logfile b where  a.group# = b.group#  order by a.group#, member;

https://databaseinternalmechanism.com/oracle-backup-recovery/recovering-from-the-loss-of-redo-log-files/

Recovering from the LOSS of REDO log files >>https://databaseinternalmechanism.com/oracle-backup-recovery/recovering-from-the-loss-of-redo-log-files/