0% found this document useful (0 votes)

43 views94 pages

BerkeleyDB Core C GSG

This document provides an introduction to Oracle Berkeley DB for C developers. It summarizes the key concepts and features of Berkeley DB including database access methods, database limits, error handling, and getting started with Berkeley DB. The document contains code examples for common tasks like opening and closing databases, reading and writing records, using cursors, and configuring secondary databases.

Uploaded by

junk email

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

43 views94 pages

BerkeleyDB Core C GSG

Uploaded by

junk email

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Welcome to Berkeley DB (DB). DB is a general-purpose embedded database engine that is
capable of providing a wealth of data management services. It is designed from the ground up
for high-throughput applications requiring in-process, bullet-proof management of missioncritical data. DB can gracefully scale from managing a few bytes to terabytes of data. For the
most part, DB is limited only by your system's available physical resources.
You use DB through a series of programming APIs which give you the ability to read and write
your data, manage your database(s), and perform other more advanced activities such as
managing transactions.
Because DB is an embedded database engine, it is extremely fast. You compile and link it into
your application in the same way as you would any third-party library. This means that DB
runs in the same process space as does your application, allowing you to avoid the high cost of
interprocess communications incurred by stand-alone database servers.
To further improve performance, DB offers an in-memory cache designed to provide rapid
access to your most frequently used data. Once configured, cache usage is transparent. It
requires very little attention on the part of the application developer.
Beyond raw speed, DB is also extremely configurable. It provides several different ways of
organizing your data in its databases. Known as access methods, each such data organization
mechanism provides different characteristics that are appropriate for different data
management profiles. (Note that this manual focuses almost entirely on the BTree access
method as this is the access method used by the vast majority of DB applications).
To further improve its configurability, DB offers many different subsystems, each of which can
be used to extend DB's capabilities. For example, many applications require write-protection
of their data so as to ensure that data is never left in an inconsistent state for any reason
(such as software bugs or hardware failures). For those applications, a transaction subsystem
can be enabled and used to transactional-protect database writes.
The list of operating systems on which DB is available is too long to detail here. Suffice to say
that it is available on all major commercial operating systems, as well as on many embedded
platforms.
Finally, DB is available in a wealth of programming languages. DB is officially supported in C,
C++, and Java, but the library is also available in many other languages, especially scripting
languages such as Perl and Python.

Note
Before going any further, it is important to mention that DB is not a relational
database (although you could use it to build a relational database). Out of the box,
DB does not provide higher-level features such as triggers, or a high-level query
language such as SQL. Instead, DB provides just those minimal APIs required to store
and retrieve your data as efficiently as possible.

6/18/2015

Getting Started with DB

Page 1

Introduction to Berkeley DB

Library Version 12.1.6.1

About This Manual

This manual introduces DB. As such, this book does not examine intermediate or advanced
features such as threaded library usage or transactional usage. Instead, this manual provides a
step-by-step introduction to DB's basic concepts and library usage.
Specifically, this manual introduces DB environments, databases, database records, and
storage and retrieval of database records. This book also introduces cursors and their usage,
and it describes secondary databases.
For the most part, this manual focuses on the BTree access method. A chapter is given at
the end of this manual that describes some of the concepts involving BTree usage, such as
duplicate record management and comparison routines.
Examples are given throughout this book that are designed to illustrate API usage. At the
end of each chapter, a complete example is given that is designed to reinforce the concepts
covered in that chapter. In addition to being presented in this book, these final programs are
also available in the DB software distribution. You can find them in
DB_INSTALL/examples/c/getting_started
where DB_INSTALL is the location where you placed your DB distribution.
This book uses the C programming languages for its examples. Note that versions of this book
exist for the C++ and Java languages as well.

Berkeley DB Concepts
Before continuing, it is useful to describe some of the larger concepts that you will encounter
when building a DB application.
Conceptually, DB databases contain records. Logically each record represents a single entry
in the database. Each such record contains two pieces of information: a key and a data. This
manual will on occasion describe a a record's key or a record's data when it is necessary to
speak to one or the other portion of a database record.
Because of the key/data pairing used for DB databases, they are sometimes thought of as a
two-column table. However, data (and sometimes keys, depending on the access method) can
hold arbitrarily complex data. Frequently, C structures and other such mechanisms are stored
in the record. This effectively turns a 2-column table into a table with n columns, where n-1
of those columns are provided by the structure's fields.
Note that a DB database is very much like a table in a relational database system in that most
DB applications use more than one database (just as most relational databases use more than
one table).
Unlike relational systems, however, a DB database contains a single collection of records
organized according to a given access method (BTree, Queue, Hash, and so forth). In a
relational database system, the underlying access method is generally hidden from you.

6/18/2015

Getting Started with DB

Page 2

Introduction to Berkeley DB

Library Version 12.1.6.1

In any case, frequently DB applications are designed so that a single database stores a specific
type of data (just as in a relational database system, a single table holds entries containing
a specific set of fields). Because most applications are required to manage multiple kinds of
data, a DB application will often use multiple databases.
For example, consider an accounting application. This kind of an application may manage data
based on bank accounts, checking accounts, stocks, bonds, loans, and so forth. An accounting
application will also have to manage information about people, banking institutions, customer
accounts, and so on. In a traditional relational database, all of these different kinds of
information would be stored and managed using a (probably very) complex series of tables.
In a DB application, all of this information would instead be divided out and managed using
multiple databases.
DB applications can efficiently use multiple databases using an optional mechanism called an
environment. For more information, see Environments (page 6).
You interact with most DB APIs using special structures that contain pointers to functions.
These callbacks are called methods because they look so much like a method on a C++ class.
The variable that you use to access these methods is often referred to as a handle. For
example, to use a database you will obtain a handle to that database.
Retrieving a record from a database is sometimes called getting the record because the
method that you use to retrieve the records is called get(). Similarly, storing database
records is sometimes called putting the record because you use the put() method to do this.
When you store, or put, a record to a database using its handle, the record is stored according
to whatever sort order is in use by the database. Sorting is mostly performed based on the
key, but sometimes the data is considered too. If you put a record using a key that already
exists in the database, then the existing record is replaced with the new data. However, if
the database supports duplicate records (that is, records with identical keys but different
data), then that new record is stored as a duplicate record and any existing records are not
overwritten.
If a database supports duplicate records, then you can use a database handle to retrieve only
the first record in a set of duplicate records.
In addition to using a database handle, you can also read and write data using a special
mechanism called a cursor. Cursors are essentially iterators that you can use to walk over the
records in a database. You can use cursors to iterate over a database from the first record
to the last, and from the last to the first. You can also use cursors to seek to a record. In the
event that a database supports duplicate records, cursors are the only way you can access all
the records in a set of duplicates.
Finally, DB provides a special kind of a database called a secondary database. Secondary
databases serve as an index into normal databases (called primary database to distinguish
them from secondaries). Secondary databases are interesting because DB records can hold
complex data types, but seeking to a given record is performed only based on that record's
key. If you wanted to be able to seek to a record based on some piece of information that is
not the key, then you enable this through the use of secondary databases.

6/18/2015

Getting Started with DB

Page 3

Introduction to Berkeley DB

Library Version 12.1.6.1

Access Methods
While this manual will focus primarily on the BTree access method, it is still useful to briefly
describe all of the access methods that DB makes available.
Note that an access method can be selected only when the database is created. Once
selected, actual API usage is generally identical across all access methods. That is, while some
exceptions exist, mechanically you interact with the library in the same way regardless of
which access method you have selected.
The access method that you should choose is gated first by what you want to use as a key, and
then secondly by the performance that you see for a given access method.
The following are the available access methods:
Access Method

Description

BTree

Data is stored in a sorted, balanced tree structure. Both the key

and the data for BTree records can be arbitrarily complex. That
is, they can contain single values such as an integer or a string, or
complex types such as a structure. Also, although not the default
behavior, it is possible for two records to use keys that compare
as equals. When this occurs, the records are considered to be
duplicates of one another.

Hash

Data is stored in an extended linear hash table. Like BTree, the

key and the data used for Hash records can be of arbitrarily
complex data. Also, like BTree, duplicate records are optionally
supported.

Queue

Data is stored in a queue as fixed-length records. Each record

uses a logical record number as its key. This access method is
designed for fast inserts at the tail of the queue, and it has a
special operation that deletes and returns a record from the head
of the queue.
This access method is unusual in that it provides record level
locking. This can provide beneficial performance improvements in
applications requiring concurrent access to the queue.

Recno

Data is stored in either fixed or variable-length records. Like

Queue, Recno records use logical record numbers as keys.

Selecting Access Methods

To select an access method, you should first consider what you want to use as a key for you
database records. If you want to use arbitrary data (even strings), then you should use either
BTree or Hash. If you want to use logical record numbers (essentially integers) then you should
use Queue or Recno.
Once you have made this decision, you must choose between either BTree or Hash, or Queue
or Recno. This decision is described next.

6/18/2015

Getting Started with DB

Page 4

Introduction to Berkeley DB

Library Version 12.1.6.1

Choosing between BTree and Hash

For small working datasets that fit entirely in memory, there is no difference between BTree
and Hash. Both will perform just as well as the other. In this situation, you might just as well
use BTree, if for no other reason than the majority of DB applications use BTree.
Note that the main concern here is your working dataset, not your entire dataset. Many
applications maintain large amounts of information but only need to access some small
portion of that data with any frequency. So what you want to consider is the data that you will
routinely use, not the sum total of all the data managed by your application.
However, as your working dataset grows to the point where you cannot fit it all into memory,
then you need to take more care when choosing your access method. Specifically, choose:
BTree if your keys have some locality of reference. That is, if they sort well and you
can expect that a query for a given key will likely be followed by a query for one of its
neighbors.
Hash if your dataset is extremely large. For any given access method, DB must maintain a
certain amount of internal information. However, the amount of information that DB must
maintain for BTree is much greater than for Hash. The result is that as your dataset grows,
this internal information can dominate the cache to the point where there is relatively little
space left for application data. As a result, BTree can be forced to perform disk I/O much
more frequently than would Hash given the same amount of data.
Moreover, if your dataset becomes so large that DB will almost certainly have to perform
disk I/O to satisfy a random request, then Hash will definitely out perform BTree because it
has fewer internal records to search through than does BTree.

Choosing between Queue and Recno

Queue or Recno are used when the application wants to use logical record numbers for the
primary database key. Logical record numbers are essentially integers that uniquely identify
the database record. They can be either mutable or fixed, where a mutable record number
is one that might change as database records are stored or deleted. Fixed logical record
numbers never change regardless of what database operations are performed.
When deciding between Queue and Recno, choose:
Queue if your application requires high degrees of concurrency. Queue provides record-level
locking (as opposed to the page-level locking that the other access methods use), and this
can result in significantly faster throughput for highly concurrent applications.
Note, however, that Queue provides support only for fixed length records. So if the size of
the data that you want to store varies widely from record to record, you should probably
choose an access method other than Queue.
Recno if you want mutable record numbers. Queue is only capable of providing fixed record
numbers. Also, Recno provides support for databases whose permanent storage is a flat
text file. This is useful for applications looking for fast, temporary storage while the data is
being read or modified.

6/18/2015

Getting Started with DB

Page 5

Introduction to Berkeley DB

Library Version 12.1.6.1

Opening Databases
To open a database, you must first use the db_create() function to initialize a DB handle.
Once you have initialized the DB handle, you use its open() method to open the database.
Note that by default, DB does not create databases if they do not already exist. To override
this behavior, specify the DB_CREATE flag on the open() method.
The following code fragment illustrates a database open:
#include <db.h>
...
DB *dbp;
u_int32_t flags;
int ret;

/* DB structure handle */
/* database open flags */
/* function return value */

Removes the specified database. If no value is given for the database parameter, then the
entire file referenced by this method is removed.
Never remove a database that has handles opened for it. Never remove a file that contains
databases with opened handles.
#include <db.h>
...
DB *dbp;
/* Database handle creation omitted for clarity */
dbp->remove(dbp,
"mydb.db",
NULL,
0);

/*
/*
/*
*
*
/*

Database pointer */
Database file to remove */
Database to remove. This is
NULL so the entire file is
removed. */
Flags. None used. */

DB->rename()
Renames the specified database. If no value is given for the database parameter, then the
entire file referenced by this method is renamed.
Never rename a database that has handles opened for it. Never rename a file that contains
databases with opened handles.
#include <db.h>
...
DB *dbp;
/* Database handle creation omitted for clarity */
dbp->rename(dbp,
"mydb.db",
NULL,
"newdb.db",
0);

6/18/2015

Getting Started with DB

/*
/*
/*
*
*
/*
/*

Database pointer */
Database file to rename */
Database to rename. This is
NULL so the entire file is
renamed. */
New database file name */
Flags. None used. */

DB_INSTALL/examples/c/getting_started
where DB_INSTALL is the location where you placed your DB distribution.

Example2.1.The stock_db Structure

To begin, we create a structure that we will use to hold all our database pointers and
database names:
/* File: gettingstarted_common.h */
#include <db.h>
typedef struct stock_dbs {
DB *inventory_dbp; /* Database containing inventory information */
DB *vendor_dbp;
/* Database containing vendor information */
char *db_home_dir;
/* Directory containing the database files */
char *inventory_db_name; /* Name of the inventory database */
char *vendor_db_name;
/* Name of the vendor database */
} STOCK_DBS;
/* Function prototypes */
int databases_setup(STOCK_DBS *, const char *, FILE *);
int databases_close(STOCK_DBS *);
void initialize_stockdbs(STOCK_DBS *);
int open_database(DB **, const char *, const char *,
FILE *);
void set_db_filenames(STOCK_DBS *my_stock);

Example2.2.The stock_db Utility Functions

Before continuing, we want some utility functions that we use to make sure the stock_db
structure is in a sane state before using it. One is a simple function that initializes all the
structure's pointers to a useful default.The second is more interesting in that it is used to
place a common path on all our database names so that we can explicitly identify where all
the database files should reside.
/* File: gettingstarted_common.c */
#include "gettingstarted_common.h"
/* Initializes the STOCK_DBS struct.*/
void
initialize_stockdbs(STOCK_DBS *my_stock)
{
my_stock->db_home_dir = DEFAULT_HOMEDIR;
my_stock->inventory_dbp = NULL;
my_stock->vendor_dbp = NULL;
my_stock->inventory_db_name = NULL;
my_stock->vendor_db_name = NULL;

6/18/2015

Getting Started with DB

Page 17

Databases

Library Version 12.1.6.1

}
/* Identify all the files that will hold our databases. */
void
set_db_filenames(STOCK_DBS *my_stock)
{
size_t size;
/* Create the Inventory DB file name */
size = strlen(my_stock->db_home_dir) + strlen(INVENTORYDB) + 1;
my_stock->inventory_db_name = malloc(size);
snprintf(my_stock->inventory_db_name, size, "%s%s",
my_stock->db_home_dir, INVENTORYDB);
/* Create the Vendor DB file name */
size = strlen(my_stock->db_home_dir) + strlen(VENDORDB) + 1;
my_stock->vendor_db_name = malloc(size);
snprintf(my_stock->vendor_db_name, size, "%s%s",
my_stock->db_home_dir, VENDORDB);
}

Example2.3.open_database() Function
We are opening multiple databases, and we are opening those databases using identical flags
and error reporting settings. It is therefore worthwhile to create a function that performs this
operation for us:
/* File: gettingstarted_common.c */
/* Opens a database */
int
open_database(DB **dbpp,
const char *file_name,
const char *program_name,
FILE *error_file_pointer)

/*
/*
/*
*
/*

The DB handle that we are opening */

The file in which the db lives */
Name of the program calling this
function */
File where we want error messages
sent */

6/18/2015

Getting Started with DB

Page 18

Databases

Library Version 12.1.6.1

/* Point to the memory malloc'd by db_create() */

*dbpp = dbp;
/* Set up error handling for this database */
dbp->set_errfile(dbp, error_file_pointer);
dbp->set_errpfx(dbp, program_name);
/* Set the open flags */
open_flags = DB_CREATE;
/* Now open the database */
ret = dbp->open(dbp,
/* Pointer to the database */
NULL,
/* Txn pointer */
file_name, /* File name */
NULL,
/* Logical db name (unneeded) */
DB_BTREE,
/* Database type (using btree) */
open_flags, /* Open flags */
0);
/* File mode. Using defaults */
if (ret != 0) {
dbp->err(dbp, ret, "Database '%s' open failed.", file_name);
return(ret);
}
return (0);
}

Example2.4.The databases_setup() Function

Now that we have our open_database() function, we can use it to open a database. We now
create a simple function that will open all our databases for us.
/* opens all databases */
int
databases_setup(STOCK_DBS *my_stock, const char *program_name,
FILE *error_file_pointer)
{
int ret;
/* Open the vendor database */
ret = open_database(&(my_stock->vendor_dbp),
my_stock->vendor_db_name,
program_name, error_file_pointer);
if (ret != 0)
/*
* Error reporting is handled in open_database() so just return
* the return code here.
*/
return (ret);
/* Open the inventory database */

6/18/2015

Getting Started with DB

Page 19

Databases

Library Version 12.1.6.1

ret = open_database(&(my_stock->inventory_dbp),
my_stock->inventory_db_name,
program_name, error_file_pointer);
if (ret != 0)
/*
* Error reporting is handled in open_database() so just return
* the return code here.
*/
return (ret);
printf("databases opened successfully\n");
return (0);
}

Example2.5.The databases_close() Function

Finally, it is useful to have a function that can close all our databases for us:
/* Closes all the databases. */
int
databases_close(STOCK_DBS *my_stock)
{
int ret;
/*
* Note that closing a database automatically flushes its cached data
* to disk, so no sync is required here.
*/
if (my_stock->inventory_dbp != NULL) {
ret = my_stock->inventory_dbp->close(my_stock->inventory_dbp, 0);
if (ret != 0)
fprintf(stderr, "Inventory database close failed: %s\n",
db_strerror(ret));
}
if (my_stock->vendor_dbp != NULL) {
ret = my_stock->vendor_dbp->close(my_stock->vendor_dbp, 0);
if (ret != 0)
fprintf(stderr, "Vendor database close failed: %s\n",
db_strerror(ret));
}
printf("databases closed.\n");
return (0);
}

6/18/2015

Getting Started with DB

Page 20

Chapter 3. Database Records

DB records contain two parts a key and some data. Both the key and its corresponding data
are encapsulated in DBT structures. Therefore, to access a DB record, you need two such
structures, one for the key and one for the data.
DBT structures provide a void * field that you use to point to your data, and another field
that identifies the data length. They can therefore be used to store anything from simple
primitive data to complex structures so long as the information you want to store resides in a
single contiguous block of memory.
This chapter describes DBT usage. It also introduces storing and retrieving key/value pairs
from a database.

Using Database Records

Each database record is comprised of two DBT structures one for the key and another for
the data.
To store a database record where the key and/or the data are primitive data (int, float,
and so forth), or where the key and/or the data contain an array, we need only to point to the
memory location where that data resides and identify its length. For example:
#include <db.h>
#include <string.h>
...
DBT key, data;
float money = 122.45;
char *description = "Grocery bill.";
/* Zero out the DBTs before using them. */
memset(&key, 0, sizeof(DBT));
memset(&data, 0, sizeof(DBT));
key.data = &money;
key.size = sizeof(float);
data.data = description;
data.size = strlen(description) + 1;
To retrieve the record, simply assign the void * returned in the DBT to the appropriate
variable.
Note that in the following example we do not allow DB to assign the memory for the retrieval
of the money value. The reason why is that some systems may require float values to have a
specific alignment, and the memory as returned by DB may not be properly aligned (the same
problem may exist for structures on some systems). We tell DB to use our memory instead of
its own by specifying the DB_DBT_USERMEM flag. Be aware that when we do this, we must also
identify how much user memory is available through the use of the ulen field.

6/18/2015

Getting Started with DB

Page 21

Database Records

Library Version 12.1.6.1

#include <db.h>
#include <string.h>
...
float money;
DBT key, data;
char *description;
/* Initialize the DBTs */
memset(&key, 0, sizeof(DBT));
memset(&data, 0, sizeof(DBT));
key.data = &money;
key.ulen = sizeof(float);
key.flags = DB_DBT_USERMEM;
/* Database retrieval code goes here */
/*
* Money is set into the memory that we supplied.
*/
description = data.data;

Reading and Writing Database Records

When reading and writing database records, be aware that there are some slight differences
in behavior depending on whether your database supports duplicate records. Two or more
database records are considered to be duplicates of one another if they share the same key.
The collection of records sharing the same key are called a duplicates set. In DB, a given key
is stored only once for a single duplicates set.
By default, DB databases do not support duplicate records. Where duplicate records are
supported, cursors (see below) are typically used to access all of the records in the duplicates
set.
DB provides two basic mechanisms for the storage and retrieval of database key/data pairs:
The DBT->put() and DBT->get() methods provide the easiest access for all non-duplicate
records in the database. These methods are described in this section.
Cursors provide several methods for putting and getting database records. Cursors and their
database access methods are described in Using Cursors (page 39).

Writing Records to the Database

Records are stored in the database using whatever organization is required by the access
method that you have selected. In some cases (such as BTree), records are stored in a sort
order that you may want to define (see Setting Comparison Functions (page 85) for more
information).

6/18/2015

Getting Started with DB

Page 22

Database Records

Library Version 12.1.6.1

In any case, the mechanics of putting and getting database records do not change once you
have selected your access method, configured your sorting routines (if any), and opened your
database. From your code's perspective, a simple database put and get is largely the same no
matter what access method you are using.
You use DB->put() to put, or write, a database record. This method requires you to provide
the record's key and data in the form of a pair of DBT structures. You can also provide one or
more flags that control DB's behavior for the database write.
Of the flags available to this method, DB_NOOVERWRITE may be interesting to you. This flag
disallows overwriting (replacing) an existing record in the database. If the provided key
already exists in the database, then this method returns DB_KEYEXIST even if the database
supports duplicates.
For example:
#include <db.h>
#include <string.h>
...
char *description = "Grocery bill.";
DBT key, data;
DB *my_database;
int ret;
float money;
/* Database open omitted for clarity */
money = 122.45;
/* Zero out the DBTs before using them. */
memset(&key, 0, sizeof(DBT));
memset(&data, 0, sizeof(DBT));
key.data = &money;
key.size = sizeof(float);
data.data = description;
data.size = strlen(description) +1;
ret = my_database->put(my_database, NULL, &key, &data, DB_NOOVERWRITE);
if (ret == DB_KEYEXIST) {
my_database->err(my_database, ret,
"Put failed because key %f already exists", money);
}

Getting Records from the Database

You can use the DB->get() method to retrieve database records. Note that if your database
supports duplicate records, then by default this method will only return the first record in a

6/18/2015

Getting Started with DB

Page 23

Database Records

Library Version 12.1.6.1

duplicate set. For this reason, if your database supports duplicates, the common solution is to
use a cursor to retrieve records from it. Cursors are described in Using Cursors (page 39).
(You can also retrieve a set of duplicate records using a bulk get. To do this, you use the
DB_MULTIPLE flag on the call to DB->get(). For more information, see the DB Programmer's
Reference Guide).
By default, DB->get() returns the first record found whose key matches the key provide
on the call to this method. If your database supports duplicate records, you can change this
behavior slightly by supplying the DB_GET_BOTH flag. This flag causes DB->get() to return the
first record that matches the provided key and data.
If the specified key and/or data does not exist in the database, this method returns
DB_NOTFOUND.
#include <db.h>
#include <string.h>
...
#define DESCRIPTION_SIZE 199
DBT key, data;
DB *my_database;
float money;
char description[DESCRIPTION_SIZE + 1];
/* Database open omitted for clarity */
money = 122.45;
/* Zero out the DBTs before using them. */
memset(&key, 0, sizeof(DBT));
memset(&data, 0, sizeof(DBT));
key.data = &money;
key.size = sizeof(float);
data.data = description;
data.ulen = DESCRIPTION_SIZE + 1;
data.flags = DB_DBT_USERMEM;
my_database->get(my_database, NULL, &key, &data, 0);
/*
* Description is set into the memory that we supplied.
*/
Note that in this example, the data.size field would be automatically set to the size of the
retrieved data.

6/18/2015

Getting Started with DB

Page 24

Database Records

Library Version 12.1.6.1

Deleting Records
You can use the DB->del() method to delete a record from the database. If your database
supports duplicate records, then all records associated with the provided key are deleted. To
delete just one record from a list of duplicates, use a cursor. Cursors are described in Using
Cursors (page 39).
You can also delete every record in the database by using DB->truncate().
For example:
#include <db.h>
#include <string.h>
...
DBT key;
DB *my_database;
float money = 122.45;
/* Database open omitted for clarity */
/* Zero out the DBTs before using them. */
memset(&key, 0, sizeof(DBT));
key.data = &money;
key.size = sizeof(float);
my_database->del(my_database, NULL, &key, 0);

Data Persistence
When you perform a database modification, your modification is made in the in-memory
cache. This means that your data modifications are not necessarily flushed to disk, and so
your data may not appear in the database after an application restart.
Note that as a normal part of closing a database, its cache is written to disk. However, in the
event of an application or system failure, there is no guarantee that your databases will close
cleanly. In this event, it is possible for you to lose data. Under extremely rare circumstances,
it is also possible for you to experience database corruption.
Therefore, if you care if your data is durable across system failures, and to guard against the
rare possibility of database corruption, you should use transactions to protect your database
modifications. Every time you commit a transaction, DB ensures that the data will not be lost
due to application or system failure. Transaction usage is described in the Berkeley DB Getting
Started with Transaction Processing guide.
If you do not want to use transactions, then the assumption is that your data is of a nature
that it need not exist the next time your application starts. You may want this if, for example,
you are using DB to cache data relevant only to the current application runtime.

6/18/2015

Getting Started with DB

Page 25

Database Records

Library Version 12.1.6.1

If, however, you are not using transactions for some reason and you still want some guarantee
that your database modifications are persistent, then you should periodically call DB>sync(). Syncs cause any dirty entries in the in-memory cache and the operating system's
file cache to be written to disk. As such, they are quite expensive and you should use them
sparingly.
Remember that by default a sync is performed any time a non-transactional database is closed
cleanly. (You can override this behavior by specifying DB_NOSYNC on the call to DB->close().)
That said, you can manually run a sync by calling DB->sync().

Note
If your application or system crashes and you are not using transactions, then you
should either discard and recreate your databases, or verify them. You can verify a
database using DB->verify(). If your databases do not verify cleanly, use the db_dump
command to salvage as much of the database as is possible. Use either the -R or -r
command line options to control how aggressive db_dump should be when salvaging
your databases.

Using C Structures with DB

Storing data in structures is a handy way to pack varied types of information into each
database record. DB databases are sometimes thought of as a two column table where column
1 is the key and column 2 is the data. By using structures, you can effectively turn this table
into n columns where n-1 columns are contained in the structure.
So long as a C structure contains fields that are not pointers, you can safely store and retrieve
them in the same way as you would any primitive datatype. The following code fragment
illustrates this:
#include <db.h>
#include <string.h>
typedef struct my_struct {
int id;
char familiar_name[MAXLINE]; /* Some suitably large value */
char surname[MAXLINE];
} MY_STRUCT;
...
DBT key, data;
DB *my_database;
MY_STRUCT user;
char *fname = "David";
char *sname = "Rider";
/* Database open omitted for clarity */
user.id = 1;
strncpy(user.familiar_name, fname, strlen(fname)+1);

6/18/2015

Getting Started with DB

Page 26

Database Records

Library Version 12.1.6.1

strncpy(user.surname, sname, strlen(sname)+1);

/* Zero out the DBTs before using them. */
memset(&key, 0, sizeof(DBT));
memset(&data, 0, sizeof(DBT));
key.data = &(user.id);
key.size = sizeof(int);
data.data = &user;
data.size = sizeof(MY_STRUCT);
my_database->put(my_database, NULL, &key, &data, DB_NOOVERWRITE);
To retrieve the structure, make sure you supply your own memory. The reason why is that like
real numbers, some systems require structures to be aligned in a specific way. Because it is
possible that the memory DB provides is not aligned properly, for safest result simply use your
own memory:
#include <db.h>
#include <string.h>
...
DBT key, data;
DB *my_database;
MY_STRUCT user;
/* Database open omitted for clarity */
/* Zero out the DBTs before using them. */
memset(&key, 0, sizeof(DBT));
memset(&data, 0, sizeof(DBT));
/* Initialize the structure */
memset(&user, 0, sizeof(MY_STRUCT));
user.id = 1;
key.data = &user.id;
key.size = sizeof(int);
/* Use our memory to retrieve the structure */
data.data = &user;
data.ulen = sizeof(MY_STRUCT);
data.flags = DB_DBT_USERMEM;
my_database->get(my_database, NULL, &key, &data, 0);
printf("Familiar name: %s\n", user.familiar_name);
printf("Surname: %s\n", user.surname);

6/18/2015

Getting Started with DB

Page 27

Database Records

Library Version 12.1.6.1

Be aware that while this is the easiest way to manage structures stored in DB databases, this
approach does suffer from causing your database to be larger than is strictly necessary. Each
structure stored in the database is of a fixed size, and you do not see any space savings from
storing a (for example) 5 character surname versus a 20 character surname.
For a simple example such as this, the padding stored with each record is probably not
critical. However, if you are storing structures that contain a very large number of character
arrays, or if you are simply storing millions of records, then you may want to avoid this
approach. The wasted space in each record will only serve to make your databases larger than
need be, which will in turn require a larger cache and more disk I/O than you would ordinarily
need.
An alternative approach is described next.

C Structures with Pointers

It is often necessary in C structures to use fields that are pointers to dynamically allocated
memory. This is particularly true if you want to store character strings (or any kind of an array
for that matter), and you want to avoid any overhead caused by pre-designating the size of
the array.
When storing structures like these you need to make sure that all of the data pointed to and
contained by the structure is lined up in a single contiguous block of memory. Remember that
DB stores data located at a specific address and of a particular size. If your structure includes
fields that are pointing to dynamically allocated memory, then the data that you want to store
can be located in different, not necessarily contiguous, locations on the heap.
The easiest way to solve this problem is to pack your data into a single memory location and
then store the data in that location. (This process is sometimes called marshalling the data.)
For example:
#include <db.h>
#include <string.h>
#include <stdlib.h>
typedef struct my_struct {
int id;
char *familiar_name;
char *surname;
} MY_STRUCT;
...
DBT key, data;
DB *my_database;
MY_STRUCT user;
int buffsize, bufflen;
char fname[ ] = "Pete";
char sname[10];
char *databuff;
strncpy(sname, "Oar", strlen("Oar")+1);

6/18/2015

Getting Started with DB

Page 28

Database Records

Library Version 12.1.6.1

/* Database open omitted for clarity */

user.id = 1;
user.familiar_name = fname;
user.surname = sname;
/* Some of the structure's data is on the stack, and
* some is on the heap. To store this structure's data, we
* need to marshall it -- pack it all into a single location
* in memory.
*/
/* Get the buffer */
buffsize = sizeof(int) +
(strlen(user.familiar_name) + strlen(user.surname) + 2);
databuff = malloc(buffsize);
memset(databuff, 0, buffsize);
/* copy everything to the buffer */
memcpy(databuff, &(user.id), sizeof(int));
bufflen = sizeof(int);
memcpy(databuff + bufflen, user.familiar_name,
strlen(user.familiar_name) + 1);
bufflen += strlen(user.familiar_name) + 1;
memcpy(databuff + bufflen, user.surname,
strlen(user.surname) + 1);
bufflen += strlen(user.surname) + 1;
/* Now store it */
/* Zero out the DBTs before using them. */
memset(&key, 0, sizeof(DBT));
memset(&data, 0, sizeof(DBT));
key.data = &(user.id);
key.size = sizeof(int);
data.data = databuff;
data.size = bufflen;
my_database->put(my_database, NULL, &key, &data, DB_NOOVERWRITE);
free(sname);
free(databuff);
To retrieve the stored structure:
#include <db.h>

6/18/2015

Getting Started with DB

Page 29

Database Records

Library Version 12.1.6.1

ifp = fopen(vendor_file, "r");
if (ifp == NULL) {
fprintf(stderr, "Error opening file '%s'\n", vendor_file);
return(-1);
}
/* Iterate over the vendor file */
while(fgets(buf, MAXLINE, ifp) != NULL) {
/* zero out the structure */
memset(&my_vendor, 0, sizeof(VENDOR));
/* Zero out the DBTs */
memset(&key, 0, sizeof(DBT));
memset(&data, 0, sizeof(DBT));
/*
* Scan the line into the structure.
* Convenient, but not particularly safe.
* In a real program, there would be a lot more
* defensive code here.
*/
sscanf(buf,
"%20[^#]#%20[^#]#%20[^#]#%3[^#]#%6[^#]#%13[^#]#%20[^#]#%20[^\n]",
my_vendor.name, my_vendor.street,
my_vendor.city, my_vendor.state,
my_vendor.zipcode, my_vendor.phone_number,
my_vendor.sales_rep, my_vendor.sales_rep_phone);
/*
* Now that we have our structure we can load it
* into the database.
*/
/* Set up the database record's key */
key.data = my_vendor.name;
key.size = (u_int32_t)strlen(my_vendor.name) + 1;
/* Set up the database record's data */
data.data = &my_vendor;
data.size = sizeof(VENDOR);
/*
* Note that given the way we built our struct, there are extra
* bytes in it. Essentially we're using fixed-width fields with
* the unused portion of some fields padded with zeros. This
* is the easiest thing to do, but it does result in a bloated
* database. Look at load_inventory_data() for an example of how
* to avoid this.
*/

6/18/2015

Getting Started with DB

Page 34

Database Records

Library Version 12.1.6.1

/* Put the data into the database.

* Omitting error handling for clarity.
*/
my_stock.vendor_dbp->put(my_stock.vendor_dbp, 0,
&key, &data, 0);
} /* end vendors database while loop */
/* Close the vendor.txt file */
fclose(ifp);
return(0);
}
Finally, we need to write the load_inventory_database() function. We made this function a
bit more complicated than is necessary by avoiding the use of a structure to manage the data.
Instead, we manually pack all our inventory data into a single block of memory, and store that
data in the database.
While this complicates our code somewhat, this approach allows us to use the smallest amount
of space possible for the data that we want to store. The result is that our cache can be
smaller than it might otherwise be and our database will take less space on disk than if we
used a structure with fixed-length fields.
For a trivial dataset such as what we use for these examples, these resource savings are
negligible. But if we were storing hundreds of millions of records, then the cost savings may
become significant.
Before we actually implement our inventory loading function, it is useful to create a simple
utility function that copies a character array into a buffer at a designated offset:
/*
* Simple little convenience function that takes a buffer, a string,
* and an offset and copies that string into the buffer at the
* appropriate location. Used to ensure that all our strings
* are contained in a single contiguous chunk of memory.
*/
size_t
pack_string(char *buffer, char *string, size_t start_pos)
{
size_t string_size;
string_size = strlen(string) + 1;
memcpy(buffer+start_pos, string, string_size);
return(start_pos + string_size);
}
That done, we can now load the inventory database:
/*
* Loads the contents of the inventory.txt file into
* a database. Note that because the itemname

6/18/2015

Getting Started with DB

Page 35

Database Records

Library Version 12.1.6.1

* secondary database is associated to the inventorydb

Using Cursors

Library Version 12.1.6.1

DBT key, data;

int ret;
/* Database open omitted for clarity */
/* Get a cursor */
my_database->cursor(my_database, NULL, &cursorp, 0);
/* Initialize our DBTs. */
memset(&key, 0, sizeof(DBT));
memset(&data, 0, sizeof(DBT));
/* Iterate over the database, retrieving each record in turn. */
while ((ret = cursorp->get(cursorp, &key,
&data, DB_PREV)) == 0) {
/* Do interesting things with the DBTs here. */
}
if (ret != DB_NOTFOUND) {
/* Error handling goes here */
}
// Cursors must be closed
if (cursorp != NULL)
cursorp->close(cursorp);
if (my_database != NULL)
my_database->close(my_database, 0);

Searching for Records

You can use cursors to search for database records. You can search based on just a key, or you
can search based on both the key and the data. You can also perform partial matches if your
database supports sorted duplicate sets. In all cases, the key and data parameters of these
methods are filled with the key and data values of the database record to which the cursor is
positioned as a result of the search.
Also, if the search fails, then cursor's state is left unchanged and DB_NOTFOUND is returned.
To use a cursor to search for a record, use DBT->get(). When you use this method, you can
provide the following flags:

Note
Notice in the following list that the cursor flags use the keyword SET when the cursor
examines just the key portion of the records (in this case, the cursor is set to the
record whose key matches the value provided to the cursor). Moreover, when the
cursor uses the keyword GET, then the cursor is positioned to both the key and the
data values provided to the cursor.

6/18/2015

Getting Started with DB

Page 41

Using Cursors

Library Version 12.1.6.1

Regardless of the keyword you use to get a record with a cursor, the cursor's key and
data DBTs are filled with the data retrieved from the record to which the cursor is
positioned.
DB_SET
Moves the cursor to the first record in the database with the specified key.
DB_SET_RANGE
Identical to DB_SET unless you are using the BTree access. In this case, the cursor moves to
the first record in the database whose key is greater than or equal to the specified key. This
comparison is determined by the comparison function that you provide for the database. If
no comparison function is provided, then the default lexicographical sorting is used.
For example, suppose you have database records that use the following strings as keys:
Alabama
Alaska
Arizona
Then providing a search key of Alaska moves the cursor to the second key noted above.
Providing a key of Al moves the cursor to the first key (Alabama), providing a search key
of Alas moves the cursor to the second key (Alaska), and providing a key of Ar moves the
cursor to the last key (Arizona).
DB_GET_BOTH
Moves the cursor to the first record in the database that uses the specified key and data.
DB_GET_BOTH_RANGE
Moves the cursor to the first record in the database whose key matches the specified key
and whose data is greater than or equal to the specified data. If the database supports
duplicate records, then on matching the key, the cursor is moved to the duplicate record
with the smallest data that is greater than or equal to the specified data.
For example, suppose your database uses BTree and it has database records that use the
following key/data pairs:
Alabama/Athens
Alabama/Florence
Alaska/Anchorage
Alaska/Fairbanks
Arizona/Avondale
Arizona/Florence
then providing:

6/18/2015

a search key of ...

and a search data of ...

moves the cursor to ...

Alaska

Alaska/Fairbanks

Getting Started with DB

Page 42

Using Cursors

Library Version 12.1.6.1

a search key of ...

and a search data of ...

moves the cursor to ...

Arizona

Arizona/Florence

Alaska

Alaska/Anchorage

For example, assuming a database containing sorted duplicate records of U.S. States/U.S
Cities key/data pairs (both as strings), then the following code fragment can be used to
position the cursor to any record in the database and print its key/data values:
#include <db.h>
#include <string.h>
...
DBC *cursorp;
DBT key, data;
DB *dbp;
int ret;
char *search_data = "Fa";
char *search_key = "Alaska";
/* database open omitted for clarity */
/* Get a cursor */
dbp->cursor(dbp, NULL, &cursorp, 0);
/* Set up our DBTs */
key.data = search_key;
key.size = strlen(search_key) + 1;
data.data = search_data;
data.size = strlen(search_data) + 1;
/*
* Position the cursor to the first record in the database whose
* key matches the search key and whose data begins with the
* search data.
*/
ret = cursorp->get(cursorp, &key, &data, DB_GET_BOTH_RANGE);
if (!ret) {
/* Do something with the data */
} else {
/* Error handling goes here */
}
/* Close the cursor */
if (cursorp != NULL)
cursorp->close(cursorp);
/* Close the database */
if (dbp != NULL)

6/18/2015

Getting Started with DB

Page 43

Using Cursors

Library Version 12.1.6.1

dbp->close(dbp, 0);

Working with Duplicate Records

A record is a duplicate of another record if the two records share the same key. For duplicate
records, only the data portion of the record is unique.
Duplicate records are supported only for the BTree or Hash access methods. For information
on configuring your database to use duplicate records, see Allowing Duplicate Records (page
82).
If your database supports duplicate records, then it can potentially contain multiple records
that share the same key. By default, normal database get operations will only return the first
such record in a set of duplicate records. Typically, subsequent duplicate records are accessed
using a cursor. The following DBC->get() flags are interesting when working with databases
that support duplicate records:
DB_NEXT, DB_PREV
Shows the next/previous record in the database, regardless of whether it is a duplicate of
the current record. For an example of using these methods, see Getting Records Using the
Cursor (page 40).
DB_GET_BOTH_RANGE
Useful for seeking the cursor to a specific record, regardless of whether it is a duplicate
record. See Searching for Records (page 41) for more information.
DB_NEXT_NODUP, DB_PREV_NODUP
Gets the next/previous non-duplicate record in the database. This allows you to skip over
all the duplicates in a set of duplicate records. If you call DBC->get() with DB_PREV_NODUP,
then the cursor is positioned to the last record for the previous key in the database. For
example, if you have the following records in your database:
Alabama/Athens
Alabama/Florence
Alaska/Anchorage
Alaska/Fairbanks
Arizona/Avondale
Arizona/Florence
and your cursor is positioned to Alaska/Fairbanks, and you then call DBC->get() with
DB_PREV_NODUP, then the cursor is positioned to Alabama/Florence. Similarly, if you
call DBC->get() with DB_NEXT_NODUP, then the cursor is positioned to the first record
corresponding to the next key in the database.
If there is no next/previous key in the database, then DB_NOTFOUND is returned, and the
cursor is left unchanged.
DB_NEXT_DUP

6/18/2015

Getting Started with DB

Getting Started with DB

Page 47

Using Cursors

Library Version 12.1.6.1

*
* If duplicates are allowed, then "My third data" is placed in the
* duplicates list according to how it sorts against "My second data".
*/
ret = cursorp->put(cursorp, &key2,
&data3, DB_KEYFIRST); /* If duplicates are not allowed, record
* is overwritten with new data. Otherwise,
* the record is added to the beginning of
* the duplicates list.
*/

Deleting Records Using Cursors

To delete a record using a cursor, simply position the cursor to the record that you want to
delete and then call DBC->del().
For example:
#include <db.h>
#include <string.h>
...
DB *dbp;
DBC *cursorp;
DBT key, data;
char *key1str = "My first string";
int ret;
/* Database open omitted */
/* Initialize our DBTs. */
memset(&key, 0, sizeof(DBT));
memset(&data, 0, sizeof(DBT));
/* Set up our DBTs */
key.data = key1str;
key.size = strlen(key1str) + 1;
/* Get the cursor */
dbp->cursor(dbp, NULL, &cursorp, 0);
/* Iterate over the database, deleting each record in turn. */
while ((ret = cursorp->get(cursorp, &key,
&data, DB_SET)) == 0) {
cursorp->del(cursorp, 0);
}
/* Cursors must be closed */
if (cursorp != NULL)

6/18/2015

Getting Started with DB

Page 48

Using Cursors

Library Version 12.1.6.1

cursorp->close(cursorp);
if (dbp != NULL)
dbp->close(dbp, 0);

Replacing Records Using Cursors

You replace the data for a database record by using DBC->put() with the DB_CURRENT flag.
#include <db.h>
#include <string.h>
...
DB *dbp;
DBC *cursorp;
DBT key, data;
char *key1str = "My first string";
char *replacement_data = "replace me";
int ret;
/* Initialize our DBTs. */
memset(&key, 0, sizeof(DBT));
memset(&data, 0, sizeof(DBT));
/* Set up our DBTs */
key.data = key1str;
key.size = strlen(key1str) + 1;
/* Database open omitted */
/* Get the cursor */
dbp->cursor(dbp, NULL, &cursorp, 0);
/* Position the cursor */
ret = cursorp->get(cursorp, &key, &data, DB_SET);
if (ret == 0) {
data.data = replacement_data;
data.size = strlen(replacement_data) + 1;
cursorp->put(cursorp, &key, &data, DB_CURRENT);
}
/* Cursors must be closed */
if (cursorp != NULL)
cursorp->close(cursorp);
if (dbp != NULL)
dbp->close(dbp, 0);

6/18/2015

Getting Started with DB

Page 49

Using Cursors

Library Version 12.1.6.1

Note that you cannot change a record's key using this method; the key parameter is always
ignored when you replace a record.
When replacing the data portion of a record, if you are replacing a record that is a member
of a sorted duplicates set, then the replacement will be successful only if the new record
sorts identically to the old record. This means that if you are replacing a record that is
a member of a sorted duplicates set, and if you are using the default lexicographic sort,
then the replacement will fail due to violating the sort order. However, if you provide a
custom sort routine that, for example, sorts based on just a few bytes out of the data item,
then potentially you can perform a direct replacement and still not violate the restrictions
described here.
Under these circumstances, if you want to replace the data contained by a duplicate record,
and you are not using a custom sort routine, then delete the record and create a new record
with the desired key and data.

Cursor Example
In Database Usage Example (page 30) we wrote an application that loaded two databases with
vendor and inventory information. In this example, we will write an application to display all
of the items in the inventory database. As a part of showing any given inventory item, we will
look up the vendor who can provide the item and show the vendor's contact information.
Specifically, the example_database_read application does the following:
1.

Opens the the inventory and vendor databases that were created by our
example_database_load application. See example_database_load (page 31) for
information on how that application creates the databases and writes data to them.

Obtains a cursor from the inventory database.

On-disk file that holds the database. */

Optional logical database name */
Database access method */
Open flags */
File mode (using defaults) */

if (ret != 0) {
/* Error handling goes here */
}
/* open the secondary database */
ret = sdbp->open(sdbp,
/* DB structure pointer */
NULL,
/* Transaction pointer */
"my_secdb.db", /* On-disk file that holds the
database. */
NULL,
/* Optional logical database name */
DB_BTREE,
/* Database access method */
flags,
/* Open flags */
0);
/* File mode (using defaults) */
if (ret != 0) {
/* Error handling goes here */
}
/* Now associate the secondary
dbp->associate(dbp,
NULL,
sdbp,
get_sales_rep,
0);

to the primary */
/* Primary database */
/* TXN id */
/* Secondary database */
/* Callback used for key creation. Not
* defined in this example. See the next
* section. */
/* Flags */

Closing the primary and secondary databases is accomplished exactly as you would for any
database:
/* Close the secondary before the primary */
if (sdbp != NULL)
sdbp->close(sdbp, 0);
if (dbp != NULL)
dbp->close(dbp, 0);

Implementing Key Extractors

You must provide every secondary database with a callback that creates keys from primary
records. You identify this callback when you associate your secondary database to your
primary.
You can create keys using whatever data you want. Typically you will base your key on some
information found in a record's data, but you can also use information found in the primary
record's key. How you build your keys is entirely dependent upon the nature of the index that
you want to maintain.

6/18/2015

Getting Started with DB

Page 58

Secondary Databases

Library Version 12.1.6.1

You implement a key extractor by writing a function that extracts the necessary information
from a primary record's key or data. This function must conform to a specific prototype, and it
must be provided as a callback to the associate() method.
For example, suppose your primary database
structure:
typedef struct vendor {
char name[MAXFIELD];
char street[MAXFIELD];
char city[MAXFIELD];
char state[3];
char zipcode[6];
char phone_number[13];
char sales_rep[MAXFIELD];
char sales_rep_phone[MAXFIELD];
} VENDOR;

records contain data that uses the following

/*
/*
/*
/*
/*
/*
/*
/*

Vendor name */
Street name and number */
City */
Two-digit US state code */
US zipcode */
Vendor phone number */
Name of sales representative */
Sales rep's phone number */

Further suppose that you want to be able to query your primary database based on the name
of a sales representative. Then you would write a function that looks like this:
#include <db.h>
...
int
get_sales_rep(DB *sdbp,
const DBT *pkey,
const DBT *pdata,
DBT *skey)
{
VENDOR *vendor;

/*
/*
/*
/*

secondary db handle */
primary db record's key */
primary db record's data */
secondary db record's key */

/* First, extract the structure contained in the primary's data */

vendor = pdata->data;
/* Now set the secondary key's data to be the representative's name */
memset(skey, 0, sizeof(DBT));
skey->data = vendor->sales_rep;
skey->size = strlen(vendor->sales_rep) + 1;
/* Return 0 to indicate that the record can be created/updated. */
return (0);
}
In order to use this function, you provide it on the associate() method after the primary and
secondary databases have been created and opened:
dbp->associate(dbp,
/* Primary database */
NULL,
/* TXN id */
sdbp,
/* Secondary database */
get_sales_rep, /* Callback used for key creation. */
0);
/* Flags */

6/18/2015

Getting Started with DB

Page 59

Secondary Databases

Library Version 12.1.6.1

Working with Multiple Keys

Until now we have only discussed indexes as if there is a one-to-one relationship between the
secondary key and the primary database record. In fact, it is possible to generate multiple
keys for any given record, provided that you take appropriate steps in your key creator to do
so.
For example, suppose you had a database that contained information about books. Suppose
further that you sometimes want to look up books by author. Because sometimes books have
multiple authors, you may want to return multiple secondary keys for every book that you
index.
To do this, you write a key extractor that returns a DBT whose data member points to an
array of DBTs. Each such member of this array contains a single secondary key. In addition, the
DBT returned by your key extractor must have a size field equal to the number of elements
contained in the DBT array. Also, the flag field for the DBT returned by the callback must
include DB_DBT_MULTIPLE. For example:

Note
It is important that the array of secondary keys created by your callback not contain
repeats. That is, every element in the array must be unique. If the array does not
contain a unique set, then the secondary can get out of sync with the primary.
int
my_callback(DB *dbp, const DBT *pkey, const DBT *pdata, DBT *skey)
{
DBT *tmpdbt;
char *tmpdata1, tmpdata2;
/*
* This example skips the step of extracting the data you
* want to use for building your secondary keys from the
* pkey or pdata DBT.
*
* Assume for the purpose of this example that the data
* is temporarily stored in two variables,
* tmpdata1 and tmpdata2.
*/
/*
* Create an array of DBTs that is large enough for the
* number of keys that you want to return. In this case,
* we go with an array of size two.
*/
tmpdbt = malloc(sizeof(DBT) * 2);
memset(tmpdbt, 0, sizeof(DBT) * 2);
/* Now assign secondary keys to each element of the array. */
tmpdbt[0].data = tmpdata1;

6/18/2015

Getting Started with DB

Page 60

Secondary Databases

Library Version 12.1.6.1

tmpdbt[0].size = (u_int32_t)strlen(tmpdbt[0].data) + 1;
tmpdbt[1].data = tmpdata2;
tmpdbt[1].size = (u_int32_t)strlen(tmpdbt[1].data) + 1;
/*
* Now we set flags for the returned DBT. DB_DBT_MULTIPLE is
* required in order for DB to know that the DBT references an
* array. In addition, we set DB_DBT_APPMALLOC because we
* dynamically allocated memory for the DBT's data field.
* DB_DBT_APPMALLOC causes DB to release that memory once it
* is done with the returned DBT.
*/
skey->flags = DB_DBT_MULTIPLE | DB_DBT_APPMALLOC;
/* Point the results data field to the arrays of DBTs */
skey->data = tmpdbt;
/* Indicate the returned array is of size 2 */
skey->size = 2;
return (0);
}

Reading Secondary Databases

Using Cursors with Secondary Databases

Just like cursors on a primary database, you can use cursors on secondary databases to iterate
over the records in a secondary database. Like cursors used with primary databases, you can
also use cursors with secondary databases to search for specific records in a database, to seek
to the first or last record in the database, to get the next duplicate record, and so forth. For a
complete description on cursors and their capabilities, see Using Cursors (page 39).
However, when you use cursors with secondary databases:
Any data returned is the data contained on the primary database record referenced by the
secondary record.
You cannot use DB_GET_BOTH and related flags with DB->get() and a secondary database.
Instead, you must use DB->pget(). Also, in that case the primary and secondary key given
on the call to DB->pget() must match the secondary key and associated primary record key
in order for that primary record to be returned as a result of the call.
For example, suppose you are using the databases, classes, and key extractors described in
Implementing Key Extractors (page 58). Then the following searches for a person's name in
the secondary database, and deletes all secondary and primary records that use that name.
#include <db.h>
#include <string.h>
...
DB *sdbp;
/* Secondary DB handle */
DBC *cursorp;
/* Cursor */
DBT key, data;
/* DBTs used for the delete */
char *search_name = "John Doe"; /* Name to delete */
/* Primary and secondary database opens omitted for brevity. */

6/18/2015

Getting Started with DB

Page 64

Secondary Databases

Library Version 12.1.6.1

/* Get a cursor on the secondary database */

sdbp->cursor(sdbp, NULL, &cursorp, 0);
/*
* Zero out the DBT before using it.
*/
memset(&key, 0, sizeof(DBT));
memset(&data, 0, sizeof(DBT));
key.data = search_name;
key.size = strlen(search_name) + 1;
/* Position the cursor */
while (cursorp->get(cursorp, &key, &data, DB_SET) == 0)
cursorp->del(cursorp, 0);

Database Joins
If you have two or more secondary databases associated with a primary database, then you
can retrieve primary records based on the intersection of multiple secondary entries. You do
this using a join cursor.
Throughout this document we have presented a structure that stores information on grocery
vendors. That structure is fairly simple with a limited number of data members, few of which
would be interesting from a query perspective. But suppose, instead, that we were storing
information on something with many more characteristics that can be queried, such as an
automobile. In that case, you may be storing information such as color, number of doors, fuel
mileage, automobile type, number of passengers, make, model, and year, to name just a few.
In this case, you would still likely be using some unique value to key your primary entries
(in the United States, the automobile's VIN would be ideal for this purpose). You would then
create a structure that identifies all the characteristics of the automobiles in your inventory.
To query this data, you might then create multiple secondary databases, one for each of the
characteristics that you want to query. For example, you might create a secondary for color,
another for number of doors, another for number of passengers, and so forth. Of course, you
will need a unique key extractor function for each such secondary database. You do all of this
using the concepts and techniques described throughout this chapter.
Once you have created this primary database and all interesting secondaries, what you have
is the ability to retrieve automobile records based on a single characteristic. You can, for
example, find all the automobiles that are red. Or you can find all the automobiles that have
four doors. Or all the automobiles that are minivans.
The next most natural step, then, is to form compound queries, or joins. For example, you
might want to find all the automobiles that are red, and that were built by Toyota, and that
are minivans. You can do this using a join cursor.

6/18/2015

Getting Started with DB

Page 65

Secondary Databases

Library Version 12.1.6.1

Using Join Cursors

To use a join cursor:
Open two or more cursors for secondary databases that are associated with the same
primary database.
Position each such cursor to the secondary key value in which you are interested. For
example, to build on the previous description, the cursor for the color database is
positioned to the red records while the cursor for the model database is positioned to the
minivan records, and the cursor for the make database is positioned to Toyota.
Create an array of cursors, and place in it each of the cursors that are participating in your
join query. Note that this array must be null terminated.
Obtain a join cursor. You do this using the DB->join() method. You must pass this method
the array of secondary cursors that you opened and positioned in the previous steps.
Iterate over the set of matching records until the return code is not 0.
Close your cursor.
If you are done with them, close all your cursors.
For example:
#include <db.h>
#include <string.h>
...
DB *automotiveDB;
DB *automotiveColorDB;
DB *automotiveMakeDB;
DB *automotiveTypeDB;
DBC *color_curs, *make_curs, *type_curs, *join_curs;
DBC *carray[4];
DBT key, data;
int ret;
char *the_color = "red";
char *the_type = "minivan";
char *the_make = "Toyota";
/* Database and secondary database opens omitted for brevity.
* Assume a primary database handle:
*
automotiveDB
* Assume 3 secondary database handles:
*
automotiveColorDB -- secondary database based on automobile color
*
automotiveMakeDB -- secondary database based on the manufacturer
*
automotiveTypeDB -- secondary database based on automobile type
*/

6/18/2015

Getting Started with DB

Page 66

Secondary Databases

Library Version 12.1.6.1

/* initialize pointers and structures */

color_curs = NULL;
make_curs = NULL;
type_curs = NULL;
join_curs = NULL;
memset(&key, 0, sizeof(DBT));
memset(&data, 0, sizeof(DBT));
/* open the cursors */
if (( ret =
automotiveColorDB->cursor(automotiveColorDB, NULL,
&color_curs, 0)) != 0) {
/* Error handling goes here */
}
if (( ret =
automotiveMakeDB->cursor(automotiveMakeDB, NULL,
&make_curs, 0)) != 0) {
/* Error handling goes here */
}
if (( ret =
automotiveTypeDB->cursor(automotiveTypeDB, NULL,
&type_curs, 0)) != 0) {
/* Error handling goes here */
}
/* Position the cursors */
key.data = the_color;
key.size = strlen(the_color) + 1;
if ((ret = color_curs->get(color_curs, &key, &data, DB_SET)) != 0)
/* Error handling goes here */
key.data = the_make;
key.size = strlen(the_make) + 1;
if ((ret = make_curs->get(make_curs, &key, &data, DB_SET)) != 0)
/* Error handling goes here */
key.data = the_type;
key.size = strlen(the_type) + 1;
if ((ret = type_curs->get(type_curs, &key, &data, DB_SET)) != 0)
/* Error handling goes here */
/* Set up
carray[0]
carray[1]
carray[2]

6/18/2015

the cursor array */

= color_curs;
= make_curs;
= type_curs;

Getting Started with DB

Page 67

Secondary Databases

Library Version 12.1.6.1

carray[3] = NULL;
/* Create the join */
if ((ret = automotiveDB->join(automotiveDB, carray, &join_curs, 0)) != 0)
/* Error handling goes here */
/* Iterate using the join cursor */
while ((ret = join_curs->get(join_curs, &key, &data, 0)) == 0) {
/* Do interesting things with the key and data */
}
/*
* If we exited the loop because we ran out of records,
* then it has completed successfully.
*/
if (ret == DB_NOTFOUND) {
/*
* Close all our cursors and databases as is appropriate,
* then exit with a normal exit status (0).
*/
}

and

Secondary Database Example

In previous chapters in this book, we built applications that load and display several DB
databases. In this example, we will extend those examples to use secondary databases.
Specifically:
In Database Usage Example (page 30) we built an application that can open and load data
into several databases. In Secondary Databases with example_database_load (page 68) we
will extend that application to also open a secondary database for the purpose of indexing
inventory item names.
In Cursor Example (page 50) we built an application to display our inventory database (and
related vendor information). In Secondary Databases with example_database_read (page
75) we will extend that application to show inventory records based on the index we
cause to be loaded using example_database_load.

Secondary Databases with example_database_load

example_database_load uses several utility functions to open and close its databases. In
order to cause example_database_load to maintain an index of inventory item names, all we
really need to do is update the utility functions to:
1.

Create a new database to be used as a secondary database.

Associate our new database to the inventory primary database.

Close the secondary database when we close the rest of our databases.

We also need a function that can create our secondary keys for us.

6/18/2015

my_stock->vendor_db_name = NULL;
my_stock->itemname_db_name = NULL;
}
/* Identify all the files that will hold our databases. */
void
set_db_filenames(STOCK_DBS *my_stock)
{
size_t size;
/* Create the Inventory DB file name */
size = strlen(my_stock->db_home_dir) + strlen(INVENTORYDB) + 1;
my_stock->inventory_db_name = malloc(size);
snprintf(my_stock->inventory_db_name, size, "%s%s",
my_stock->db_home_dir, INVENTORYDB);
/* Create the Vendor DB file name */
size = strlen(my_stock->db_home_dir) + strlen(VENDORDB) + 1;
my_stock->vendor_db_name = malloc(size);
snprintf(my_stock->vendor_db_name, size, "%s%s",
my_stock->db_home_dir, VENDORDB);
/* Create the itemname DB file name */
size = strlen(my_stock->db_home_dir) + strlen(ITEMNAMEDB) + 1;
my_stock->itemname_db_name = malloc(size);
snprintf(my_stock->itemname_db_name, size, "%s%s",
my_stock->db_home_dir, ITEMNAMEDB);
}
We also need to update the open_database() (as described in open_database()
Function (page 18)) to take special actions if we are opening a secondary database. Unlike
our primary databases, we want to support sorted duplicates for our secondary database. This
is because we are indexing based on an item's name, and item names are shared by multiple
inventory records. As a result every key the secondary database (an item name) will be used
by multiple records (pointers to records in our primary database). We allow this by configuring
our secondary database to support duplicate records. Further, because BTrees perform best
when their records are sorted, we go ahead and configure our secondary database for sorted
duplicates.
To do this, we add a parameter to the function that indicates whether we are opening
a secondary database, and we add in the few lines of code necessary to set the sorted
duplicates flags.
/* Opens a database */
int
open_database(DB **dbpp,
const char *file_name,
const char *program_name,
FILE *error_file_pointer,
int is_secondary)

6/18/2015

db_strerror(ret));
}
if (my_stock->vendor_dbp != NULL) {
ret = my_stock->vendor_dbp->close(my_stock->vendor_dbp, 0);
if (ret != 0)
fprintf(stderr, "Vendor database close failed: %s\n",
db_strerror(ret));
}
printf("databases closed.\n");
return (0);
}
And the implementation changes slightly to take advantage of the new boolean. Note that to
save space, we just show the constructor where the code actually changes:
That completes our update to example_database_load. Now when this program is called, it
will automatically index inventory items based on their names. We can then query for those
items using the new index. We show how to do that in the next section.

* database that has the appropriate key.

*/
exit_value = 0;
ret = itemname_cursorp->get(itemname_cursorp, &key, &data, DB_SET);
if (!ret) {
do {
/*
* Show the inventory record and the vendor responsible
* for this inventory item.
*/
the_vendor = show_inventory_item(data.data);
ret = show_vendor_record(the_vendor, my_stock->vendor_dbp);
if (ret) {
exit_value = ret;
break;
}
/*
* Our secondary allows duplicates, so we need to loop over
* the next duplicate records and show them all. This is done
* because an inventory item's name is not a unique value.
*/
} while(itemname_cursorp->get(itemname_cursorp, &key, &data,
DB_NEXT_DUP) == 0);
} else {
printf("No records found for '%s'\n", itemname);
}
/* Close the cursor */
itemname_cursorp->close(itemname_cursorp);
return (exit_value);
}
This completes our update to example_inventory_read. Using this update, you can now
search for and show all inventory items that match a particular name. For example:
example_inventory_read -i "Zulu Nut"

6/18/2015

Getting Started with DB

Page 78

Chapter 6. Database Configuration

This chapter describes some of the database and cache configuration issues that you need
to consider when building your DB database. In most cases, there is very little that you need
to do in terms of managing your databases. However, there are configuration issues that you
need to be concerned with, and these are largely dependent on the access method that you
are choosing for your database.
The examples and descriptions throughout this document have mostly focused on the BTree
access method. This is because the majority of DB applications use BTree. For this reason,
where configuration issues are dependent on the type of access method in use, this chapter
will focus on BTree only. For configuration descriptions surrounding the other access methods,
see the Berkeley DB Programmer's Reference Guide.

Setting the Page Size

Internally, DB stores database entries on pages. Page sizes are important because they can
affect your application's performance.
DB pages can be between 512 bytes and 64K bytes in size. The size that you select must be a
power of 2. You set your database's page size using DB->set_pagesize().
Note that a database's page size can only be selected at database creation time.
When selecting a page size, you should consider the following issues:
Overflow pages.
Locking
Disk I/O.
These topics are discussed next.

Overflow Pages
Overflow pages are used to hold a key or data item that cannot fit on a single page. You do
not have to do anything to cause overflow pages to be created, other than to store data
that is too large for your database's page size. Also, the only way you can prevent overflow
pages from being created is to be sure to select a page size that is large enough to hold your
database entries.
Because overflow pages exist outside of the normal database structure, their use is expensive
from a performance perspective. If you select too small of a page size, then your database
will be forced to use an excessive number of overflow pages. This will significantly harm your
application's performance.
For this reason, you want to select a page size that is at least large enough to hold multiple
entries given the expected average size of your database entries. In BTree's case, for best
results select a page size that can hold at least 4 such entries.

6/18/2015

Getting Started with DB

Page 79

Database Configuration

Library Version 12.1.6.1

You can see how many overflow pages your database is using by using the DB->stat()
method, or by examining your database using the db_stat command line utility.

Locking
Locking and multi-threaded access to DB databases is built into the product. However, in
order to enable the locking subsystem and in order to provide efficient sharing of the cache
between databases, you must use an environment. Environments and multi-threaded access
are not fully described in this manual (see the Berkeley DB Programmer's Reference Manual for
information), however, we provide some information on sizing your pages in a multi-threaded/
multi-process environment in the interest of providing a complete discussion on the topic.
If your application is multi-threaded, or if your databases are accessed by more than one
process at a time, then page size can influence your application's performance. The reason
why is that for most access methods (Queue is the exception), DB implements page-level
locking. This means that the finest locking granularity is at the page, not at the record.
In most cases, database pages contain multiple database records. Further, in order to provide
safe access to multiple threads or processes, DB performs locking on pages as entries on those
pages are read or written.
As the size of your page increases relative to the size of your database entries, the number of
entries that are held on any given page also increase. The result is that the chances of two or
more readers and/or writers wanting to access entries on any given page also increases.
When two or more threads and/or processes want to manage data on a page, lock contention
occurs. Lock contention is resolved by one thread (or process) waiting for another thread to
give up its lock. It is this waiting activity that is harmful to your application's performance.
It is possible to select a page size that is so large that your application will spend excessive,
and noticeable, amounts of time resolving lock contention. Note that this scenario is
particularly likely to occur as the amount of concurrency built into your application increases.
Oh the other hand, if you select too small of a page size, then that that will only make your
tree deeper, which can also cause performance penalties. The trick, therefore, is to select a
reasonable page size (one that will hold a sizeable number of records) and then reduce the
page size if you notice lock contention.
You can examine the number of lock conflicts and deadlocks occurring in your application by
examining your database environment lock statistics. Either use the DB_ENV->lock_stat()
method, or use the db_stat command line utility. The number of unavailable locks that your
application waited for is held in the lock statistic's st_lock_wait field.

IO Efficiency
Page size can affect how efficient DB is at moving data to and from disk. For some
applications, especially those for which the in-memory cache can not be large enough to hold
the entire working dataset, IO efficiency can significantly impact application performance.
Most operating systems use an internal block size to determine how much data to move to and
from disk for a single I/O operation. This block size is usually equal to the filesystem's block

6/18/2015

Getting Started with DB

Page 80

Database Configuration

Library Version 12.1.6.1

size. For optimal disk I/O efficiency, you should select a database page size that is equal to
the operating system's I/O block size.
Essentially, DB performs data transfers based on the database page size. That is, it moves data
to and from disk a page at a time. For this reason, if the page size does not match the I/O
block size, then the operating system can introduce inefficiencies in how it responds to DB's I/
O requests.
For example, suppose your page size is smaller than your operating system block size. In this
case, when DB writes a page to disk it is writing just a portion of a logical filesystem page.
Any time any application writes just a portion of a logical filesystem page, the operating
system brings in the real filesystem page, over writes the portion of the page not written by
the application, then writes the filesystem page back to disk. The net result is significantly
more disk I/O than if the application had simply selected a page size that was equal to the
underlying filesystem block size.
Alternatively, if you select a page size that is larger than the underlying filesystem block size,
then the operating system may have to read more data than is necessary to fulfill a read
request. Further, on some operating systems, requesting a single database page may result
in the operating system reading enough filesystem blocks to satisfy the operating system's
criteria for read-ahead. In this case, the operating system will be reading significantly more
data from disk than is actually required to fulfill DB's read request.

Note
While transactions are not discussed in this manual, a page size other than your
filesystem's block size can affect transactional guarantees. The reason why is that
page sizes larger than the filesystem's block size causes DB to write pages in block
size increments. As a result, it is possible for a partial page to be written as the result
of a transactional commit. For more information, see http://docs.oracle.com/cd/
E17076_02/html/programmer_reference/transapp_reclimit.html.

Page Sizing Advice

Page sizing can be confusing at first, so here are some general guidelines that you can use to
select your page size.
In general, and given no other considerations, a page size that is equal to your filesystem
block size is the ideal situation.
If your data is designed such that 4 database entries cannot fit on a single page (assuming
BTree), then grow your page size to accommodate your data. Once you've abandoned
matching your filesystem's block size, the general rule is that larger page sizes are better.
The exception to this rule is if you have a great deal of concurrency occurring in your
application. In this case, the closer you can match your page size to the ideal size needed for
your application's data, the better. Doing so will allow you to avoid unnecessary contention for
page locks.

6/18/2015

Getting Started with DB

Page 81

Sarah B Pomeroy - Ancient Greece
91% (22)
Sarah B Pomeroy - Ancient Greece
491 pages
Psycho Cybernetics MAxwell Maltz PDF
100% (5)
Psycho Cybernetics MAxwell Maltz PDF
10 pages
Chapter 8 SQL Semester II 2023 For Students Final
No ratings yet
Chapter 8 SQL Semester II 2023 For Students Final
239 pages
Oracle
No ratings yet
Oracle
46 pages
Tesla, .. ? / Cold Fusion, Tesla, Zeropoint Energy Utilization.. Pseudoscience?// ( ) ! / Analysis of New Energy Paradigm: Including Controversial & Questionable Claims
100% (1)
Tesla, .. ? / Cold Fusion, Tesla, Zeropoint Energy Utilization.. Pseudoscience?// ( ) ! / Analysis of New Energy Paradigm: Including Controversial & Questionable Claims
498 pages
Latest Software Collection TERABYTE Package Links
No ratings yet
Latest Software Collection TERABYTE Package Links
32 pages
Oracle DBA Lab Report2
No ratings yet
Oracle DBA Lab Report2
19 pages
RDBMS
100% (1)
RDBMS
568 pages
BerkeleyDB Core CXX GSG
No ratings yet
BerkeleyDB Core CXX GSG
81 pages
Build Your Own Database From Scratch 1n
No ratings yet
Build Your Own Database From Scratch 1n
120 pages
DataScienceVSEM NoSQL DataBases
No ratings yet
DataScienceVSEM NoSQL DataBases
74 pages
OCA Oracle Database 11g Database Administration I: A Real-World Certification Guide
From Everand
OCA Oracle Database 11g Database Administration I: A Real-World Certification Guide
Steve Ries
4/5 (1)
Build Your Own Database From Scratch 1nbsped 9798391723394
100% (1)
Build Your Own Database From Scratch 1nbsped 9798391723394
120 pages
Replication JAVA GSG
No ratings yet
Replication JAVA GSG
61 pages
Unit V
No ratings yet
Unit V
35 pages
Advanced SQL I
No ratings yet
Advanced SQL I
49 pages
BDB Prog Reference
No ratings yet
BDB Prog Reference
344 pages
Postgresql 95231693412781986
No ratings yet
Postgresql 95231693412781986
218 pages
Database Management System (DBMS)
No ratings yet
Database Management System (DBMS)
41 pages
Bdbjavaparking 2541909
No ratings yet
Bdbjavaparking 2541909
20 pages
SQL Cheat Sheet-WPS Office
No ratings yet
SQL Cheat Sheet-WPS Office
22 pages
BDB Prog Reference
No ratings yet
BDB Prog Reference
517 pages
Oracle Database PDF
No ratings yet
Oracle Database PDF
104 pages
Build Your Own Database From Scratch-2023-英文版
No ratings yet
Build Your Own Database From Scratch-2023-英文版
120 pages
Lecture15 Fall
No ratings yet
Lecture15 Fall
102 pages
RDB Ms Concepts and Oracle 8 I
No ratings yet
RDB Ms Concepts and Oracle 8 I
568 pages
Installing A Dbms (Postgresql) : João R. Campos
No ratings yet
Installing A Dbms (Postgresql) : João R. Campos
13 pages
Lab1: Accessing The Database: Objectives
No ratings yet
Lab1: Accessing The Database: Objectives
22 pages
BDB Installation
No ratings yet
BDB Installation
189 pages
CS232L Lab#01
No ratings yet
CS232L Lab#01
50 pages
PostgreSQL For Ruby Developers - Jesus Castello
No ratings yet
PostgreSQL For Ruby Developers - Jesus Castello
119 pages
Postgresql PDF
No ratings yet
Postgresql PDF
93 pages
Oracle Berkeley DB Data Store: A Use-Case Based Tutorial
No ratings yet
Oracle Berkeley DB Data Store: A Use-Case Based Tutorial
68 pages
PY Mod 4
No ratings yet
PY Mod 4
20 pages
Abap Oops
No ratings yet
Abap Oops
117 pages
(D&D 4.0) Dungeon Tiles Master Set - The Wilderness
100% (8)
(D&D 4.0) Dungeon Tiles Master Set - The Wilderness
21 pages
Sanet - ST - MariaDB STARTER - Your Easiest First Step
No ratings yet
Sanet - ST - MariaDB STARTER - Your Easiest First Step
131 pages
Interbase 6 - Embedded SQL Guide
No ratings yet
Interbase 6 - Embedded SQL Guide
314 pages
Spark: Big Data Cluster Computing in Production
From Everand
Spark: Big Data Cluster Computing in Production
Ilya Ganelin
No ratings yet
XProc 3.0 Programmer Reference
From Everand
XProc 3.0 Programmer Reference
Erik Siegel
No ratings yet
Oracle DBA Classroom Training
No ratings yet
Oracle DBA Classroom Training
12 pages
Azure For Starters
From Everand
Azure For Starters
Chinmoy Mukherjee
No ratings yet
Azure Functions
No ratings yet
Azure Functions
146 pages
Trends
No ratings yet
Trends
13 pages
What IS Odbc ?
No ratings yet
What IS Odbc ?
57 pages
02 Core SQL 4
No ratings yet
02 Core SQL 4
27 pages
What Is Postgresql?
No ratings yet
What Is Postgresql?
12 pages
Database Programming
No ratings yet
Database Programming
16 pages
PostgreSQL Cookbook Sample Chapter
No ratings yet
PostgreSQL Cookbook Sample Chapter
24 pages
Chapter 5
No ratings yet
Chapter 5
14 pages
0292 Introduction Postgresql
No ratings yet
0292 Introduction Postgresql
91 pages
BerkeleyDB Core C GSG
No ratings yet
BerkeleyDB Core C GSG
96 pages
Azure Commercial - Pen Test Report 2018 PDF
No ratings yet
Azure Commercial - Pen Test Report 2018 PDF
78 pages
HH C5 C0
No ratings yet
HH C5 C0
114 pages
Setting Up Databases With Postgresql, Psequel, and Python
No ratings yet
Setting Up Databases With Postgresql, Psequel, and Python
54 pages
WP OGG Best Practices Parameter Files
No ratings yet
WP OGG Best Practices Parameter Files
7 pages
DB2 LUW Training
No ratings yet
DB2 LUW Training
20 pages
Oracle
No ratings yet
Oracle
24 pages
Dbms Chapter1
No ratings yet
Dbms Chapter1
29 pages
Oracle Architecture
No ratings yet
Oracle Architecture
55 pages
Using Basic Structured Query Language: What Is SQL?
No ratings yet
Using Basic Structured Query Language: What Is SQL?
49 pages
Performance Tuning PostgreSQL
No ratings yet
Performance Tuning PostgreSQL
25 pages
Agri
No ratings yet
Agri
106 pages
5database Library@
No ratings yet
5database Library@
9 pages
My SQL
No ratings yet
My SQL
6 pages
Extending Docker
From Everand
Extending Docker
Russ McKendrick
5/5 (1)
DWPD GTU Study Material E-Notes Unit-5 22092020071825AM
No ratings yet
DWPD GTU Study Material E-Notes Unit-5 22092020071825AM
16 pages
Selecting and Navigating Nodes Using Xpath
No ratings yet
Selecting and Navigating Nodes Using Xpath
28 pages
Research Project Proposal
No ratings yet
Research Project Proposal
2 pages
Optimization of Transportation Costs in Supply Cha PDF
No ratings yet
Optimization of Transportation Costs in Supply Cha PDF
83 pages
Developing A Mapreduce Application: by Dr. K. Venkateswara Rao Professor Department of Cse
No ratings yet
Developing A Mapreduce Application: by Dr. K. Venkateswara Rao Professor Department of Cse
83 pages
Berkeley DB: Proceedings of The FREENIX Track
No ratings yet
Berkeley DB: Proceedings of The FREENIX Track
10 pages
NCO Tutorial
100% (1)
NCO Tutorial
3 pages
Oceanic Feeling PDF
No ratings yet
Oceanic Feeling PDF
20 pages
Container Service PDF
No ratings yet
Container Service PDF
84 pages
Artifact #9: Integrated Math and Science Lesson Plan
No ratings yet
Artifact #9: Integrated Math and Science Lesson Plan
12 pages
Solutions-Grand Marks Booster Challenege#1
No ratings yet
Solutions-Grand Marks Booster Challenege#1
66 pages
Chapter 5 Gastrointestinal Agents Reviewer PDF
No ratings yet
Chapter 5 Gastrointestinal Agents Reviewer PDF
6 pages
Ai 2023
No ratings yet
Ai 2023
29 pages
How To Manage PostgreSQL Databases From The Command Line With PSQL
No ratings yet
How To Manage PostgreSQL Databases From The Command Line With PSQL
1 page
Semantics Term Paper
No ratings yet
Semantics Term Paper
14 pages
Oracle: Goldengate 12C: Conflict Detection and Resolution
No ratings yet
Oracle: Goldengate 12C: Conflict Detection and Resolution
31 pages
Drilling Engineering 30 Days Program
No ratings yet
Drilling Engineering 30 Days Program
2 pages
IKS MOD-3 QB Sol
No ratings yet
IKS MOD-3 QB Sol
26 pages
1 ML Introduction
No ratings yet
1 ML Introduction
36 pages
FSM 4 Basic Baking Report
No ratings yet
FSM 4 Basic Baking Report
12 pages
21 Masks Ego EN PDF
No ratings yet
21 Masks Ego EN PDF
6 pages
De Cuong On Thi Tieng Anh Hoc Ky II Lop 11 Nang Cao
No ratings yet
De Cuong On Thi Tieng Anh Hoc Ky II Lop 11 Nang Cao
13 pages
Abdullah Dawoud - SCMA - Volume 21 - Issue 1 - Pages 173-188
No ratings yet
Abdullah Dawoud - SCMA - Volume 21 - Issue 1 - Pages 173-188
17 pages
Module 1: Overview of XML and XSLT
No ratings yet
Module 1: Overview of XML and XSLT
20 pages
Rubric For Oral Presentation
100% (1)
Rubric For Oral Presentation
1 page
CommonMark Ready Reference
From Everand
CommonMark Ready Reference
V. Subhash
No ratings yet
Line Sizing Calculation - Pump Discharge
No ratings yet
Line Sizing Calculation - Pump Discharge
2 pages
00.01 Heko Chain Conveyors 2007
No ratings yet
00.01 Heko Chain Conveyors 2007
7 pages
BDB SQL Guide
No ratings yet
BDB SQL Guide
48 pages
D70064GC10 Toc
No ratings yet
D70064GC10 Toc
14 pages
Jama Caricchio 2021 Oi 210064 1626283669.23567
No ratings yet
Jama Caricchio 2021 Oi 210064 1626283669.23567
10 pages
Guidelines On OECD Code 2
No ratings yet
Guidelines On OECD Code 2
45 pages
A Short Introduction To Serverless Architecture
No ratings yet
A Short Introduction To Serverless Architecture
3 pages