BDB Native Version 5.0.21 - asynchronous write at the master node

Question

Hi There,
As part of performance tuning, we think of introducing asynchronous write capabilities at the master node in replication code that uses BDB native edition (11g).
Are there any known issues with the asynchronous write at the master node? We'd like to confirm with Oracle before we promote to production.
For asynchronous write at the master node we have configured a TaskExecutor with the following configuration:
<bean id="MasterAsynchronousWriteTaskExecutor" class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor">
<property name="corePoolSize" value="3"/>
<property name="maxPoolSize" value="10"/>
<property name="daemon" value="true"/>
<property name="queueCapacity" value="200000"/>
<property name="threadNamePrefix" value="Master_Entity_Writer_Thread"/>
<property name="threadGroupName" value="BDBMasterWriterThreads"/>
</bean>
Local test showed no issues. Please let us know at the EARLIEST convenience if there are any changes required to corePoolSize, “maxPoolSize” and “queueCapacity” values as a result of asynchronous write.
To summarize, 2 questions:
1) Are there any known issues with the asynchronous write at the master node for BDB Native, version 5.0.21?
2) If there are no issues, are any changes required to corePoolSize, “maxPoolSize” and “queueCapacity” values as a result of asynchronous write, and based on the configuration above?
Thank you!

Answer 1

Hello,
If you have not already, please take a look at the documentation
on "Database and log file archival" at:
http://download.oracle.com/docs/cd/E17076_02/html/programmer_reference/transapp_archival.html
Are you periodically creating backups of your database files?
These snapshots are either a standard backup, which creates a
consistent picture of the databases as of a single instant in
time; or an on-line backup (also known as a hot backup), which
creates a consistent picture of the databases as of an
unspecified instant during the period of time when the
snapshot was made. After backing up the database files you
should periodically archive the log files being created in the
environment. And I believe the question here is how often
the periodic archive should take place to establish the
best protocol for catastrophic recovery in the case of a
failure like physical hardware being destroyed, etc.
As the documentation describes, it is often helpful to think
of database archival in terms of full and incremental filesystem
backups. A snapshot is a full backup, whereas the periodic
archival of the current log files is an incremental backup.
For example, it might be reasonable to take a full snapshot
of a database environment weekly or monthly, and archive
additional log files daily. Using both the snapshot and the
log files, a catastrophic crash at any time can be recovered
to the time of the most recent log archival; a time long after
the original snapshot.
What other details can you provide about how how much activity
there is on your system with regards to log file creation
and how often a full backup is being taken, etc.
Thank,
Sandra