Oracle Tips by Burleson Consulting
EnterpriseDB architecture is different from Oracle in specifics but is
conceptually very similar (Figure 2.35). The most important component
in the EnterpriseDB architecture is the edb-postmaster program. In the
simplest terms, the Postmaster is the server.
Here is a very
quick run down of the processes in figure 2.35.
manages server processes. The Postmaster is the traffic cop; while directing
traffic, it is also controlling and communicating with the user processes.
Several processes that are independent in Oracle are performed by the Postmaster
Checkpoint & DB
Writer: In EnterpriseDB, the Postmaster has a checkpoint and db writer
process very much like Oracle’s CKPT and DBW processes. These processes make
sure your data is written to the file system (in the form of the database data
files). This process is called “writing dirty buffers to disk”.
In EnterpriseDB, the recovery process (which runs in the Postmaster process)
performs much the same function as Oracle’s SMON process. Recovery is
responsible for crash recovery in the event EnterpriseDB was not properly
In EnterpriseDB, a user process runs under the moniker edb-postgres.exe in
MS-Windows or as postgres in Linux. This is a single user Postmaster process
and is an actual client connection. There is memory associated with the
The Shared Memory works much like the
of an Oracle instance. Shared memory is the workspace and contains both the
short-term and long-term memory of the EnterpriseDB brain, the Postmaster.
Almost any disk-based database will have some kind of a buffer cache. A buffer
cache is a memory area that holds recently accessed data blocks (recently used
rows of data). A database will keep the blocks in memory in case the same
records need to be accessed again. Keeping the blocks in memory theoretically
helps with performance.
Log: The Write Ahead Log performs much the same function as Oracle’s Log
Writer; it flushes data from an internal log buffer to the REDO log on disk.
The REDO logs in EnterpriseDB serve exactly the same function as the REDO logs
in Oracle. A REDO log holds a copy of every transaction run through the
database. We use the REDO log to recover a database in case we lose a data file
or have a hard disk crash.
In EnterpriseDB, there is no native Archiving process. The Administrator can
configure a third party tool (or even a tool provided by your OS) to archive
your log files. You should archive your log files using some methodology. You
should keep archives for a time span of at least a couple of full system
This is an excerpt
from the book "EnterpriseDB: The Definitive Reference" by Rampant TechPress.