I tried the binary db5_checkpoint -1 and db5_archives -d, but no change.
What concretely DBXML when I open a container by configuring transactional true ?
Because it's slow at the opening of the container, not on the execution of the request itself.
It's good to know that the execution of the request has no degradation.
For the transactional environment, DBXML (BDB) has to open and deal with log files and region files (including locking subsystem). So it does make sense that transactional environment cost a longer time.
Since you said that by running db5_recover you can get correct response times. I just doubt if there are something wrong in the environment. It would be great if you can provide a program to reproduce the issue. Thanks.
You mentioned that "But after a few thousand I/O, opening the container can be counted in seconds". Could you please tell me the exact number? e.g.: 5 seconds, 7 seconds. Thanks.
Oracle Berkeley DB XML
The opening of the container up to 10 seconds.
Also, yesterday I realized that DBXML did not release the hold of a log file, open for several hours.
Have you ever encountered this behavior?
It seems that the environment does not be closed correctly.
* try the flag "DBXML_ADOPT_DBENV" (http://download.oracle.com/docs/cd/E17276_01/html/api_reference/CXX/XmlManager.html).
* Refer http://download.oracle.com/docs/cd/E17276_01/html/gsg_xml_txn/cxx/envopen.html to check your transactional environment configuration.
If the problem still can not be solved, please show me your code that how you open/close DB_ENV and/or XmlManager.
sorry for this answer so late, but I expected that my environment will take time to respond.
This time the container will not open even through the prompt DBXML.
Here is how I instantiate my environment and I open the containers.
/* Exemples of my code */
define("FLAGS", DB_CREATE | DB_INIT_LOCK | DB_INIT_LOG | DB_INIT_MPOOL | DB_INIT_TXN | DB_THREAD | DB_RECOVER | DB_REGISTER);
$oEnv = new Db4Env();
$oManager = new XmlManager($oEnv, DBXML_ALLOW_EXTERNAL_ACCESS | DBXML_ALLOW_AUTO_OPEN | DBXML_ADOPT_DBENV);
// Test exist
$bEnable = IS_WRITE ? true : false;
$oConfig = new XmlContainerConfig();
$oContainer = $oManager->createContainer('myContainer.dbxml', $oConfig);
I don't understand.
When I delete my environment (__db *) and I recreated, I have no problem.
Edited by: gdievart on 31 janv. 2011 04:16
could you please create a container once more with auto-indexing off. Then check whether you have the same problem again.
Can you also post your updated code. If it doesn't help, the original data and the code would be helpful to try to reproduce the problem on my machine as well.
I can't provide the complete code, but the procedures followed are those of the above.
To know that I insert and remove approximately 500 documents per day + updates.
Reading about 50,000 per day or more.
I'll try removing the auto-indexing, but I don't see how the index would have any influence on the opening of the container.
At the flags that I pass to the opening of my environment, I do not mistake?
Thank you for your investment.
I will also provide you with my configurations file DB_CONFIG for you to tell me what you think.
Edited by: gdievart on 31 janv. 2011 12:46
Definitely remove auto-indexing. If you can't re-create your container, you should remove auto-indexing, and delete the indexes that you don't need.
Which flags are you providing?
Can you send you container to me for further checking?
So I'll test by disabling the auto-indexing.
I'm sorry, but I can't provide the container, because the content belongs to the company where I work.
I look back after disable auto-indexing.
set_cachesize 0 26214400 1
rep_set_request 20000 80000
What do you think? I don't make a mistake?
Looks ok, except that the cache size may be very small for your purposes. You can try to increase the value and then re-create the environment.
Also you may want to setup the following flag in DB_CONFIG: