Oracle crtice – ili kako da ja to nekako sažvaćem :-)

Redo Log – The most crucial structure for recovery operations is the redo log, which consists of two or more preallocated files that store all changes made to the database as they occur. Every instance of an Oracle Database has an associated redo log to protect the database in case of an instance failure (link). The database requires a minimum of two files to guarantee that one is always available for writing while the other is being archived (if the database is in ARCHIVELOG mode). LGWR (log writer) writes to redo log files in a circular fashion. When the current redo log file fills, LGWR begins writing to the next available redo log file. When the last available redo log file is filled, LGWR returns to the first redo log file and writes to it, starting the cycle again. This enables you to restore your database to any point in time.
A Data Guard configuration involves log transfer and log apply services on individual sites to manage the standby database. Log transfer and log apply services on all the sites should be performing well enough that a redo log file should be archived and applied to the Oracle instance in near real-time.
The DBA needs to understand the redo generation rate of the primary database before the tuning objective can be quantified.

Data Guard – A data protection and availability solution for Oracle databases. The basic function of Oracle Data Guard is to keep a synchronized copy of a database as standby, in order to make provision, in case the primary database is inaccessible to end users (link).

Odlično objašnjenje o vezi redo logova i Data Guard-a : link

ODI – Oracle Data Integrator – data integration software product
*****
Oracle Schema – In Oracle, users and schemas are essentially the same thing. You can consider that a user is the account you use to connect to a database, and a schema is the set of objects (tables, views, etc.) that belong to that account.
A schema is collection of database objects, including logical structures such as tables, views, sequences, stored procedures, synonyms, indexes, clusters, and database links.
*A user owns a schema.
*A user and a schema have the same name.
*The CREATE USER command creates a user. It also automatically creates a schema for that user.
*The CREATE SCHEMA command does not create a “schema” as it implies, it just allows you to create multiple tables and views and perform multiple grants in your own schema in a single transaction.
*A USER can be called a SCHEMA if the “USER” owns any object, otherwise it will only remain a “USER”. Once the USER owns at least one object then by virtue of all of your definitions above… the USER can now be called a SCHEMA.
*For all intents and purposes you can consider a user to be a schema and a schema to be a user.
Dobar link.
*****
CDB$ROOT – root container, there can be only one :-). The root does not store user data. Thus, you must not add user data to the root or modify system-supplied schemas in the root. However, you can create common users and roles for database administration. A common user with the necessary privileges can switch between PDBs. The metadata for data dictionary tables and view definitions is stored only in the root.