|
There are lots of questions here, so I'll take them one at a time.
- In order to make any changes to the database, you need the ability
to be able to undo those changes, or roll the changes back. That is the
purpose of your rollback segments. The rollback segment needs to have
enough space to hold all the changes for your transaction. Inserting 10
million rows will take a lot of space in the rollback segments. You
have two choices here. You can commit more often (like every 1 million
rows), and you shouldn't have a problem, or you can increase the
MAXEXTENTS of your rollback segments with a command similar to the
following:
ALTER ROLLBACK SEGMENT r01 STORAGE (MAXEXTENTS 500);
You'll need to ensure that your rollback segment tablespace is
sufficiently large to handle this.
- The hot backup maintains consistency by the ALTER TABLESPACE
[BEGIN|END] BACKUP commands. When you place a tablespace in backup
mode, the database freezes the System Change Number (SCN) in the
data file's header. The SCN is like an incremental transaction number.
The lower the SCN value, the older the transaction that caused the data
to be changed. You then copy the data files with operating system commands. While this
is going on, the database can be making changes to the data files, thus
making the backup inconsistent. When you restore, the database uses
information logged in the redo logs to build a consistent image of the
data. This is why you must be in Archive Log mode before you can put a
tablespace in backup mode. It is the combination of freezing the
data file header's SCN and the redo logs that create a consistent
data file from the inconsistent backup image. The database starts at the
SCN in the frozen header and applies any changes to that data file since
that SCN was frozen.
- RMAN uses a slightly different technique. You still need the
archived redo logs to resolve the inconsistency. But you do not have to
freeze the datafile's header SCN. Instead, RMAN looks at the block
level for the SCN of the last change of that block. Otherwise, the
process is the same.
- During a backup, transactions are allowed to proceed and modify the
data files. All transaction information is written to the online redo
logs, which eventually become archived. So even though your data files
are inconsistent when backed up, the transactions are recorded and
played back on recovery.
- When a user performs a COMMIT, then the changed data does not
immediately get written to the datafiles. However, the changed data
must be written to the online redo log files. A COMMIT is not complete
until the online redo log files are updated. That's the only rule at
play. Changed data will be flushed from the database buffer cache to
the data files when room is needed in the cache and that changed block
needs to be cleared out. Notice that the last sentence says nothing
about a COMMIT. It is possible for uncommitted data to be written to
data files. It is the job of the undo segments to revert the change in
case of a ROLLBACK or a system failure.
- RMAN should be giving you that message during backup when an
archived redo log is missing. What I would do is to perform a full
backup of the database immediately. That way, you won't miss any
transactions that were in the missing archived redo logs.
|
