Logical Standby

Oracle Logical Standby 10g

Rick van Ek

To Apply or not to Apply?

Wie ben ik?

●
Rick van Ek
●
rick.v.ek@xs4all.nl
●
Van Ek IT Consultancy BV
●
Werkt met Oracle producten sinds 1992
●
Zelfstandig sinds 1996
●
Oracle database
●
Baan software

Waar gaan we het over hebben?

●
De casus
●
Wat is een logical standby.
●
Opbouw van logical standby.
●
Monitoring logical apply.
●
Beheren van logical apply.
●
Problemen met logical apply.
●
Oplossen van problemen met logical apply.

De casus

●
De productie kant is een drukke OLTP
●
Behoefte aan een reporting database
●
Reporting mag geen invloed hebben op Prod.
●
Te veel transacties om bij te werken in timeslot
●
Reporting data is recent
●
Standaard is Oracle 10g
●
Er wordt geen switch of failover gedaan.

Welke problemen zijn er onderkend?

●
Beheer heeft eigen schema voor security, auditing
etc.
●
Users op logical standby niet dezelfde als primary
●
Path naar filenames zijn verschillend
●
Security user doet acties op primary die niet op
standby moeten plaats vinden
●
Security user moet zijn werk apart doen op standby

Introductie logical standby
Definition of Logical standby database as stated by Oracle

Contains the same logical information as the production database, although the
physical organization and structure of the data can be different. The logical
standby database is kept synchronized with the primary database though SQL
Apply, which transforms the data in the redo received from the primary
database into SQL statements and then executing the SQL statements on the
standby database.

A logical standby database can be used for other business purposes in addition to
disaster recovery requirements. This allows users to access a logical standby
database for queries and reporting purposes at any time. Also, using a logical
standby database, you can upgrade Oracle Database software and patch sets
with almost no downtime. Thus, a logical standby database can be used
concurrently for data protection, reporting, and database upgrades.

Consideratie dml

●
Een enkelvoudige statement die meerdere inserts of
updates tot gevolg heeft. Zal op de logical standby
meervoudige statements tot gevolg hebben.
●
Direct path inserts op primary worden gewone inserts
op de logical standby.
●
Create table as select * .... wordt een create table en
een aantal inserts.

Consideratie ddl

●
Parallel uit gevoerde ddl worden op de logical standby
serieel uitgevoerd
●
een aantal inserts.

Logical standby processes

●
Gedurende het mining process
– Reader
– Preparer
– Builder
●
Gedurende het apply process
– Coordinator
– Applier

Opbouw van logical standby

●
Maak een physical standby mbv RMAN
●
Configureer redolog transport correct
●
Stop redo log recovery
●
Setup logminer dict in redologs.(primary)
●
Start convert to logical op standby(standby)
●
Create standby redo log files. (redo)
●
Start logical standby apply

Configuratie Logical standby

●
Settings : dbms_logstdby.apply_set
●
log_auto_delete
●
max_events recorded
●
record_skip_ ddl
●
record_skip_errors
●
Record_applied_ddl
●
prepare_servers
●
apply_servers
●
max_sga
●
presurve_commit_order

Stappenplan om snel fouten te herleiden.

●
Kijk of redolog transport nog loopt.
●
Controleer of de processen nog bezig zijn.
●
Kijk in de event view of er foutmeldingen zijn
●
Vergelijk de huidige scn met de primary.
●

Monitoring redo log transport.

●
Transport primary naar standby
– v$managed_standby
●
Gap resolving
●
Cleanup archived redo log files
– Rman parameter primary
– Logstdby parameter standby
●
Status archived redo log files
– v$archived_log on primary

Monitoring van het Apply process

●
Kijk of alle processen nog werken
– v$logstdby_process
– newest_scn geeft laatste scn van dat process
weer
– Reader heeft laatste ontvangen scn
–

Foutmeldingen detecteren

●
Meldingen in dba_logstdby_events, v$logstdby
standaard de laatste 1000 records, is in een aantal
gevallen te weinig
– Alles wat overgeslagen wordt staat vermeld
– Circuliar herschreven
– Kan ook de applied statements weergeven.
– dba_logstdby_events weergeeft de transaction nr.
– v$logstdby, kan samen met v$session meer informatie
over het process geven.

Waar is de logical standby mee bezig?

●
DBA_LOGSTDBY_PROGRESS
information based on scn, thread, sequence
●
V$LOGSTDBY_PROGRESS
– Information based on scn and time.

Welke middelen zijn er om te meten?

●
Views archive log
– v$archived_log (primary)
– v$managed_standby (standby)
●
Views processes
●
Views events
– dba_logstdby_events

To Apply or not to Apply ?

●
Basis van wat we doen en willen.
– Niet alle transactions uitvoeren
– Transactions anders uitvoeren
– Transactions kunnen niet uitgevoerd worden

Oplossingen voor bekende problemen.

●
Methode om problemen te voorkomen (beinvloed het
apply processen)
●

– skip and replace
– Skipping schema's
– Skipping ddl
– Skip error
●
Conditioneel of niet uitvoeren van statements

Transactions kunnen/mogen niet uitgevoerd
worden
●
User management op logical is anders dan primary.
●
Schema's die eigen populatie hebben op zowel
primary als standby
●
Tables die wel op primary maar niet op logical
geupdate worden.
●

Transactions bewust skippen.
● ●
●

●

●

● STATEMENT_OPT OWNER NAME U E PROC
● --------------- ---------- ------------ - - --------------------
● NON_SCHEMA_DDL Y
● SCHEMA_DDL OCOR_OWN % Y
● DML OCOR_OWN % Y
● USER % % Y
● DIRECTORY % % Y
●

ORA-16205: DDL skipped due to skip setting alter user test default role all

ORA-16205: DDL skipped due to skip setting alter user test quota unlimited on test_d

ORA-16205: DDL skipped due to skip setting grant appl_own to test

ORA-16205: DDL skipped due to skip setting create user test identified by VALUES '8AEFD30E4A599DC7' default
tablespace test_d

ORA-16205: DDL skipped due to skip setting grant create view to appl_own

ORA-16205: DDL skipped due to skip setting grant create materialized view to appl_own

ORA-16205: DDL skipped due to skip setting "create bigfile tablespace test_d

datafile '/oracle/product/10.2.0/oradata/test/test_d01.dbf'

size 1M

autoextend on "

ORA-16205: DDL skipped due to skip setting grant create view to appl_own

ORA-16205: DDL skipped due to skip setting grant create materialized view to appl_own

ORA-16205: DDL skipped due to skip setting create role appl_own


●
DEMO
– Creeren van een nieuw schema voor een application
wordt geskipped.
– Omvat
●
Tablespace
●
Roles
●
Users
●
Privileges

Transactions anders uitvoeren

●
Voorbeelden
– Create tablespace
– Add datafile
– Create directory
●
Alle commando's die aangepast moeten worden voor
executie op de logical standby
●
Mechanisme is skip and replace. Regular expression.


●
Hoe werkt dat?
– Skip rule die transaction door procedure haalt
– Procedure replaced het commando
– Nieuwe commando wordt uitgevoerd

ORA-16204: DDL successfully applied "create tablespace dummy_d

datafile '/oracle/product/10.2.0/oradata/test2/dummy_d01.dbf'

size 1M

autoextend on "

ORA-16202: Skip procedure requested to replace statement "create tablespace dummy_d

datafile '/oracle/product/10.2.0/oradata/test2/dummy_d01.dbf'

size 1M

autoextend on "

ORA-16110: user procedure processing of logical standby apply DDL "create tablespace dummy_d

datafile '/oracle/product/10.2.0/oradata/test/dummy_d01.dbf'

size 1M

autoextend on "


●
DEMO
– Procedure replaced string in path name
– Tablespace wordt aangemaakt op de primary
– Path heeft <sid> in path staan, is niet hetzelfde
– Correcte path moet op standby bestaan

Transaction skippen met error

●
Indien een commando niet uitgevoerd kan wordt
stoppen de processes
●
Probleem moet eerst lokaal op de standby opgelost
worden
●
Transaction kan dan overgeslagen worden.
– Noodmaatregel wil je niet herhadelijk uitvoeren.


DBMS_LOGSTDBY.SKIP_TRANSACTION (
XIDUSN IN NUMBER,
XIDSLT NUMBER IN NUMBER,
XIDSQN NUMBER IN NUMBER);

Transaction nummers zijn in dba_logstdby_events terug
te vinden bij error melding.


●
DEMO
– Commando op primary wordt uitgevoerd die niet
door de logical standby wordt ondersteund
– Detectie op de logical standby.
– Oplossen van de foutmelding
– Transaction skippen en doorgaan.

Samenvatting

●
Toepassing is sterk afhankelijk van de complexiteit
van de applicatie.
●
management kan makkelijk gescheiden worden.
●
Gap resolving neemt meer tijd in beslag dan physical
standby.
●

Consideratie dml

●
Een enkelvoudige statement die meerdere inserts of
updates tot gevolg heeft. Zal op de logical standby
meervoudige statements tot gevolg hebben.
●
Direct path inserts op primary worden gewone inserts
op de logical standby.
●
een aantal inserts.

DML Apply Considerations

SQL Apply has the following characteristics when applying DML transactions that affect the throughput
and latency on the logical standby database:

Batch updates or deletes done on the primary database, where a single statement results in multiple rows
being modified, are applied as individual row modifications on the logical standby database. Thus, it is
imperative for each maintained table to have a unique or a primary key. See Section 4.1.2, "Ensure
Table Rows in the Primary Database Can Be Uniquely Identified" for more information.

Direct path inserts performed on the primary database are applied using a conventional INSERT
statement on the logical standby database.

Parallel DML (PDML) transactions are not executed in parallel on the logical standby database.

Consideratie ddl

●
Parallel uit gevoerde ddl worden op de logical standby
serieel uitgevoerd
●
een aantal inserts.

DDL Apply Considerations

SQL Apply has the following characteristics when applying DDL transactions that affect the throughput
and latency on the logical standby database:

Parallel DDL (PDDL) transactions are not performed in parallel on a logical standby database.

DDL transactions are applied serially on the logical standby database. Thus, DDL transactions applied
concurrently on the primary database are applied one at a time on the logical standby database.

CREATE TABLE AS SELECT (CTAS) statements are executed such that the DML activities (that are
part of the CTAS statement) are suppressed on the logical standby database. The rows inserted in
the newly created table as part of the CTAS statement are mined from the redo log files and applied
to the logical standby database using INSERT statements.

Logical standby processes

●
Gedurende het mining process
– Reader
– Preparer
– Builder
●
Gedurende het apply process
– Coordinator
– Applier

During log mining:
The READER process reads redo records from the archived redo log files or standby redo log files.
The PREPARER process converts block changes contained in redo records into logical change records
(LCRs). Multiple PREPARER processes can be active for a given archived redo log file or standby redo
log file. The LCRs are staged in the shared pool of the system global area (SGA), known as the LCR
cache.
The BUILDER process groups LCRs into transactions, and performs other tasks, such as memory
management in the LCR cache, checkpointing related to SQL Apply restart and filtering out of
uninteresting changes.

During apply processing:
The ANALYZER process examines the transaction chunks containing a group of LCRs, possibly filtering
out uninteresting transactions, and identifying dependencies between different transactions.
The COORDINATOR process (LSP):
Assigns transactions
Monitors dependencies between transactions and coordinates scheduling
Authorizes the commitment of changes to the logical standby database
The APPLIER processes:
Applies the LCRs to the database
Asks the COORDINATOR process to approve transactions with unresolved dependencies
Commits the transactions

Opbouw van logical standby

●
Maak een physical standby mbv RMAN
●
Configureer redolog transport correct
●
Stop redo log recovery
●
Setup logminer dict in redologs.(primary)
●
Start convert to logical op standby(standby)
●
Create standby redo log files. (redo)
●
Start logical standby apply

- RMAN => duplicate target database for standby
- log_archive_dest_x=' service max connedtions logwrt arch sync async etc.
- alter database recover managed standby database [cancel / disconnect from session]
- exec dbms_logstdby.build()
- alter datebase recover to logical standby <SID>
- alter database start logical standby apply immediate.

Configuratie Logical standby

●
Settings : dbms_logstdby.apply_set
●
log_auto_delete
●
max_events recorded
●
record_skip_ ddl
●
record_skip_errors
●
Record_applied_ddl
●
prepare_servers
●
apply_servers
●
max_sga
●
presurve_commit_order

Table 56-2 APPLY_SET Procedure Parameters

Parameter Description
LOG_AUTO_DELETE Automatically deletes archived redo log files once they have been applied on the logical standby database.
Set to TRUE to enable automatic deletion of archived redo log files, and FALSE to disable automatic deletion.The default
value is TRUE.
MAX_SGA Number of megabytes from shared pool in System Global Area (SGA) that SQL Apply will use. The default value is
30 megabytes or one quarter of the value set for SHARED_POOL_SIZE, whichever is lower.
MAX_SERVERS Number of parallel query servers that SQL Apply uses to read and apply redo. It defaults to the value of
the PARALLEL_MAX_SERVERS initialization parameter or 9, whichever is lower.
MAX_EVENTS_RECORDED Number of recent events that will be visible through the DBA_LOGSTDBY_EVENTS view. To
record all events encountered by SQL Apply, use the DBMS_LOGSTDBY.MAX_EVENTS constant as the number value.
PRESERVE_COMMIT_ORDER TRUE: Transaction are applied to the logical standby database in the exact order in which they
were committed on the primary database. This is the default parameter setting.
FALSE: Transactions are applied out of order from how they were committed on the primary database, and no attempt is made to
provide read-consistent results.
Regardless of the level chosen, modifications done to the same row are always applied in the same order as they happened in the
primary database. See the Usage Notes for details and recommendations.
RECORD_SKIP_ERRORS Controls whether skipped errors (as described by the SKIP_ERROR procedure) are recorded in
the DBA_LOGSTDBY_EVENTS table and the alert log. Specify one of the following values:
TRUE: Skipped errors are recorded in the DBA_LOGSTDBY_EVENTS table and the alert log. This is the default parameter
setting.
FALSE: Skipped errors are not recorded in the DBA_LOGSTDBY_EVENTS table and the alert log.
RECORD_SKIP_DDL Controls whether skipped DDL statements are recorded in the DBA_LOGSTDBY_EVENTS table and the
alert log. Specify one of the following values:
TRUE: Skipped DDL statements are recorded in the DBA_LOGSTDBY_EVENTS table and the alert log. This is the default
parameter setting.
FALSE: Skipped DDL statements are not recorded in the DBA_LOGSTDBY_EVENTS table and the alert log.
RECORD_APPLIED_DDL Controls whether DDL statements that have been applied to the logical standby database are
recorded in the DBA_LOGSTDBY_EVENTS table and the alert log. Specify one of the following values:
TRUE: Indicates that DDL statements applied to the logical standby database are recorded in the DBA_LOGSTDBY_EVENTS
table and the alert log.
FALSE: Indicates that applied DDL statements are not recorded. This is the default parameter setting.
APPLY_SERVERS Controls the number of APPLIER processes (parallel execution servers) used to apply changes
PREPARE_SERVERS Controls the number of PREPARER processes (parallel execution servers) used to prepare changes

Monitoring redo log transport.

●
Transport primary naar standby
– v$managed_standby
●
Gap resolving
●
Cleanup archived redo log files
– Rman parameter primary
– Logstdby parameter standby
●
Status archived redo log files
– v$archived_log on primary

Processes
RFS - Remote file server
MRP0 - Detached recovery server process
ARCH - Archiver process
LGWR
RFS(FAL)
RFS(NEXP)
LNS network server process

Status
UNUSED - No active process
ALLOCATED - Process is active but not currently connected to a primary database
CONNECTED - Network connection established to a primary database
ATTACHED - Process is actively attached and communicating to a primary database
IDLE - Process is not performing any activities
ERROR - Process has failed
OPENING - Process is opening the archived redo log
CLOSING - Process has completed archival and is closing the archived redo log
WRITING - Process is actively writing redo data to the archived redo log
RECEIVING - Process is receiving network communication
ANNOUNCING - Process is announcing the existence of a potential dependent archived redo log
REGISTERING - Process is registering the existence of a completed dependent archived redo log
WAIT_FOR_LOG - Process is waiting for the archived redo log to be complete
WAIT_FOR_GAP - Process is waiting for the archive gap to be resolved

Monitoring van het Apply process

●
Kijk of alle processen nog werken
– newest_scn geeft laatste scn van dat process
weer
– Reader heeft laatste ontvangen scn
–

V$LOGSTDBY_PROCESS

V$LOGSTDBY_PROCESS displays dynamic information about what is happening to the Data Guard log
apply services. This view is very helpful when diagnosing performance problems during the logical
application of archived redo logs to the standby database, and it can be helpful for other problems.
This view is for logical standby databases only.

Column Datatype Description
SID NUMBER The session id of the associated session. This matches the SID column of the
corresponding row in the V$SESSION view.
SERIAL# NUMBER The serial number of the associated session. (SID,SERIAL#) together
uniquely identifies the session in the current database instance.
LOGSTDBY_ID NUMBER Parallel query slave ID
SPID VARCHAR2(12)This corresponds to the SPID value of the row corresponding to this process
in the V$PROCESS view
TYPE VARCHAR2(30) The role that the process plays in the context of SQL Apply. Can take
one of the following values: COORDINATOR, APPLIER, ANALYZER, READER, PREPARER, or
BUILDER
STATUS_CODE NUMBER Operation code identifying the current action of the process
STATUS VARCHAR2(256) Description of the current action of the process
HIGH_SCN NUMBER Identifies the highest redo record/LCR processed by this process

Foutmeldingen detecteren

●
Meldingen in dba_logstdby_events, v$logstdby
standaard de laatste 1000 records, is in een aantal
gevallen te weinig
– Alles wat overgeslagen wordt staat vermeld
– Circuliar herschreven
– Kan ook de applied statements weergeven.
– dba_logstdby_events weergeeft de transaction nr.
– v$logstdby, kan samen met v$session meer informatie
over het process geven.

DBA_LOGSTDBY_EVENTS

DBA_LOGSTDBY_EVENTS displays information about the activity of the logical standby database
system. It can be used to determine the cause of failures that occur when applying redo data to
logical standby databases. This view is for logical standby databases only.

Column Datatype NULL Description
EVENT_TIME DATE Time the event was logged
EVENT_TIMESTAMP TIMESTAMP(6) Timestamp when the event was logged
CURRENT_SCN NUMBER Change vector SCN for the change. If a failure occurred, then
examine this column to determine which archived log file contains the source of the failure (for
example, an unsupported record).
COMMIT_SCN NUMBER SCN value on which the change was committed
XIDUSN NUMBER Transaction ID undo segment number
XIDSLT NUMBER Transaction ID slot number
XIDSQN NUMBER Transaction ID sequence number
EVENT CLOB Statement that was being processed when the failure occurred
STATUS_CODE NUMBER Status (or Oracle error code) belonging to the STATUS
message
STATUS VARCHAR2(2000) Description of the current activity of the process or the
reason why the apply operation stopped

Waar is de logical standby mee bezig?

●
information based on scn, thread, sequence
●
V$LOGSTDBY_PROGRESS
– Information based on scn and time.


DBA_LOGSTDBY_PROGRESS displays the progress of log apply services on the logical standby database.
This view is for logical standby databases only.

APPLIED_SCN NUMBER Newest SCN at which all changes have been applied. The
values in the APPLIED_SCN and NEWEST_SCN columns will match if all available redo log data has
been processed.
APPLIED_THREAD# NUMBER Thread number for the log file containing the
APPLIED_SCN
APPLIED_SEQUENCE# NUMBER Sequence number for the log file containing the
APPLIED_SCN
APPLIED_TIME DATE Estimate of the time and date of the APPLIED_SCN
READ_SCN NUMBER All log data less than this SCN has been read and saved
READ_THREAD# NUMBER Thread number for a log file containing the READ_SCN
READ_SEQUENCE# NUMBER Sequence number for a log file containing the
READ_SCN
READ_TIME DATE Estimate of the time and date of the READ_SCN
NEWEST_SCN NUMBER Most recent SCN available on the standby system. If no more
logs are being shipped, then changes could be applied to this SCN. The values in the APPLIED_SCN
and NEWEST_SCN columns will match if all available redo log data has been processed.
NEWEST_THREAD# NUMBER Thread number for a log containing the NEWEST_SCN
NEWEST_SEQUENCE# NUMBER Sequence number for a log containing the
NEWEST_SCN
NEWEST_TIME DATE Estimate of the time and date of the NEWEST_SCN

To Apply or not to Apply ?

●
Basis van wat we doen en willen.
– Niet alle transactions uitvoeren
– Transactions anders uitvoeren
– Transactions kunnen niet uitgevoerd worden

Het beheer van de logical standby bestaat voornamelijk uit het beinvloeden van het apply process.
Gebaseerd op type transaction kan je deze filteren en manupuleren.

Oplossingen voor bekende problemen.

●
Methode om problemen te voorkomen (beinvloed het
apply processen)
●

– skip and replace
– Skipping schema's
– Skipping ddl
– Skip error
●
Conditioneel of niet uitvoeren van statements

DBA_LOGSTDBY_SKIP

DBA_LOGSTDBY_SKIP displays the tables that will be skipped by log apply services. This view is for
logical standby databases only.

ERROR VARCHAR2(1) Indicates whether the statement should be skipped (Y) or just return
errors for the statement (N)
STATEMENT_OPT VARCHAR2(30) Specifies the type of statement that should be
skipped. It must be one of the SYSTEM_AUDIT statement options.
OWNER VARCHAR2(30) Name of the schema under which the skip option should be
used
NAME VARCHAR2(30) Name of the table that is being skipped
USE_LIKE VARCHAR2(1) Indicates whether the statement should use a SQL wildcard search
when matching names (Y) or not (N)
ESC VARCHAR2(1) Escape character used when performing wildcard matches
PROC VARCHAR2(98) Name of a stored procedure that will be executed when
processing the skip option

Logical Standby

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (20)

Logical Standby