This discussion is archived
2 Replies Latest reply: Feb 1, 2012 11:33 AM by Oracle, Sandra Whitman RSS

environment creation, detection and opening

Lucas Vogel Newbie
Currently Being Moderated
I want to use BDBXML in a CDS capacity.

When I go to open an environment, I add the DB_CREATE parameter to the environment Open method, along with the CDS settings. I can create and open an environment this way successfully. However, if I leave the DB_CREATE parameter in my Open method, I get an error indicating I need to run recovery.

Is there a way to prevent this from happening?
  • 1. Re: environment creation, detection and opening
    Lucas Vogel Newbie
    Currently Being Moderated
    I've done some more tests. Let me elaborate on what I've seen work and not work (note: this is all in C++ on Windows):

    - DB_INIT_CDB | DB_INIT_MPOOL | DB_CREATE | DB_SYSTEM_MEM
    This works the first time when the environment is created. The second time the Open method calls, it returns DB_RUNRECOVERY.

    - DB_INIT_CDB | DB_INIT_MPOOL | DB_CREATE | DB_SYSTEM_MEM | DB_PRIVATE
    This works for new and existing environments. The Open method returns 0 consistently.

    - DB_INIT_CDB | DB_INIT_MPOOL | DB_CREATE | DB_SYSTEM_MEM | DB_LOCKDOWN
    This works the first time when the environment is created. The second time the Open method calls, it returns DB_RUNRECOVERY.

    - DB_INIT_CDB | DB_INIT_MPOOL | DB_CREATE | DB_SYSTEM_MEM | DB_LOCKDOWN
    This works for new and existing environments. The Open method returns 0 consistently.

    Is it safe to assume that when using the CDS functionality that DB_PRIVATE must be enabled as well?
  • 2. Re: environment creation, detection and opening
    Oracle, Sandra Whitman Journeyer
    Currently Being Moderated
    Hello,

    I have looked over the posted results:

    1. - DB_INIT_CDB | DB_INIT_MPOOL | DB_CREATE | DB_SYSTEM_MEM
    This works the first time when the environment is created. The second time the Open method calls, it returns DB_RUNRECOVERY.

    2. - DB_INIT_CDB | DB_INIT_MPOOL | DB_CREATE | DB_SYSTEM_MEM | DB_PRIVATE
    This works for new and existing environments. The Open method returns 0 consistently.

    3. - DB_INIT_CDB | DB_INIT_MPOOL | DB_CREATE | DB_SYSTEM_MEM | DB_LOCKDOWN
    This works the first time when the environment is created. The second time the Open method calls, it returns DB_RUNRECOVERY.

    4. - DB_INIT_CDB | DB_INIT_MPOOL | DB_CREATE | DB_SYSTEM_MEM | DB_LOCKDOWN
    This works for new and existing environments. The Open method returns 0 consistently.


    The third and forth case look very close but one returns DB_RUNRECOVERY
    and one does not.

    It might be helpful to review some of the concepts around shared memory
    regions as you should not be using DB_PRIVATE and DB_SYSTEM_MEM together.
    Please take a look at the "Shared memory regions" documentation at:
    http://docs.oracle.com/cd/E17076_02/html/programmer_reference/env_region.html


    From that documentation, each of the Berkeley DB subsystems within
    an environment is described by one or more regions, or chunks of memory.
    The regions contain all of the per-process and per-thread shared
    information (including mutexes), that comprise a Berkeley DB environment.
    These regions are created in one of three types of memory, depending
    on the flags specified to the DB_ENV->open() method.

    By default if no memory-related flags are specified to DB_ENV->open(),
    regions are stored in memory backed by the filesystem. If the DB_PRIVATE
    is specified to the DB_ENV->open() method, regions are created in
    per-process heap memory; that is, memory returned by malloc(). If this
    flag is specified then you cannot open more than a single handle for
    the environment. If DB_SYSTEM_MEM is set then shared regions are created
    in system memory rather than files. This is an alternative mechanism
    for sharing the Berkeley DB environment among multiple processes and
    multiple threads within processes.


    Note that on Windows platforms, the use of the DB_SYSTEM_MEM flag is
    problematic because the operating system uses reference counting to
    clean up shared objects in the paging file automatically. In addition,
    the default access permissions for shared objects are different from
    files, which may cause problems when an environment is accessed by
    multiple processes running as different users. See the Windows Notes
    section in the Berkeley DB Installation and Build Guide for more
    information.

    I did just try a 5.3.15 test on Linux with:
    long key = <key value>
    (void)envp->set_shm_key(envp, key);
    ret = envp->open(envp, db_home_dir, DB_CREATE|DB_INIT_CDB|DB_INIT_MPOOL|DB_SYSTEM_MEM, 0);

    I ran my test repeated without any error. If the problem persists,
    and you can post a small stand-alone test which reproduces the results,
    I can try it. DB_PRIVATE need not be enabled for CDB.


    Thanks,
    Sandra

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points