Dear all,

I am feazed with BDB performation.
I use BDB db-4.2.52.NC with api c on windows.
There are some question for any help.

Question #1.
I use transaction in my application. I test the performation of BDB in
my application.
If I don't use DB_NO_SYNC, an insert within a transaction takes about
26msec.
But with DB_NO_SYNC flag,an insert within a transaction takes about
1.3msec,
It is more receivable.

I need stable and good-performation database, but if I use NO_SYNC
flag, some latest data will be lost for no-synchronization. Can a
method to solve this?
Can the replication mentioned in document solve it graceful?
My application runs only on local port.
If I use a second index db file ,Will It cost more time than no
associated db file?

Question #2.
For my application, I need to rename the database file after restart
up my application and recover db file,and open a new and empty
database file for a new store.The renamed db file will only be used to
retrieve data. Do I need to remove the renamed db file from env? if I
did't remove renamed db file from env,There are two same name of db
file appeared when I call "db_stat -m" .

Question #3:
If My applications can run without interruption some days, Do I need
to add archived files and manually remove log file at every
check-point?

I would be most greatful for any help.

Thank you in advance.

Sincerely,
bootes

hxy330 (AT) 21cn (DOT) com (bootes) wrote in message news:<46fca8d6.0409300129.6ea3195b@pos
ting.google.com>...
Berkeley DB must write and flush change records to stable
storage to enforce ACID semantics; one way to improve
performance is to relax the application's ACID guarantees,
using flags like DB_TXN_NOSYNC and DB_TXN_WRITE_NOSYNC.

You might want to consider the DB_TXN_WRITE_NOSYNC flag: If
DB_TXN_WRITE_NOSYNC is set, Berkeley DB will write, but will
not synchronously flush, the log on transaction commit. That
will give you full ACID unless the system itself crashes.

Replication can be used to increase the performance of an
application. Because replication adds a new component to
"stable storage", specifying DB_TXN_NOSYNC in a replicated
environment no longer sacrifices durability, as long as one or
more clients have acknowledged receipt of the messages sent by
the master. Since network connections are often faster than
local synchronous disk writes, replication becomes a way for
applications to significantly improve their performance as well
as their reliability.

Yes; Berkeley DB uses multiple databases to implement secondary
indices, and so secondary indices will require additional time.
However, secondary indices do not usually cost much performance
as their log records are flushed at the same time as the primary
indexes log records, so secondary indexes don't require
additional synchronous disk operations.

You should use the Berkeley DB method DB_ENV->dbrename to rename
the database file, rather than renaming the database file outside
of DB. That should take care of this problem.

You will need to add database and log file archiving support to
avoid data loss after catastrophic failure (for example, to
avoid data loss after a catastrophic disk failure). If you do
not care about catastrophic failure, you can configure Berkeley
DB to automatically remove log files using the DB_LOG_AUTOREMOVE
flag to the DB_ENV->set_flags method.

Regards,
--keith

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Keith Bostic bostic (AT) sleepycat (DOT) com
Sleepycat Software Inc. keithbosticim (ymsgid)
118 Tower Rd. +1-781-259-3139
Lincoln, MA 01773 http://www.sleepycat.com