File: td000008.htm

package info (click to toggle)
solid-doc 2.2-1
links: PTS
area: non-free
in suites: potato, slink
size: 3,436 kB
ctags: 11,371
sloc: makefile: 58; sh: 2
file content (484 lines) | stat: -rw-r--r-- 35,995 bytes
parent folder | download | duplicates (2)
<HTML>
<HEAD>
<TITLE></TITLE>
<LINK REL="ToC" HREF="httoc.htm">
<LINK REL="Index" HREF="htindex.htm">
<LINK REL="Next" HREF="td000009.htm">
<LINK REL="Previous" HREF="td000007.htm"></HEAD>
<BODY BGCOLOR="#FFFFFF">
<P ALIGN=CENTER>
<A HREF="td000007.htm" TARGET="_self"><IMG SRC="gtd/graprev.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Previous Page"></A>
<A HREF="httoc.htm" TARGET="_self"><IMG SRC="gtd/gratoc.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="TOC"></A>
<A HREF="htindex.htm" TARGET="_self"><IMG SRC="gtd/graindex.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Index"></A>
<A HREF="td000009.htm" TARGET="_self"><IMG SRC="gtd/granext.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Next Page"></A>

<A NAME="E9E6"></A>
<H1>
<FONT FACE="Arial"><B>DATABASE ENGINE</B></FONT></H1>
<BR>
<BLOCKQUOTE>
<P>The SOLID Database Engine has been designed and implemented to provide the best possible performance by utilizing the operating system services and resources efficiently. This lean and mean Database Engine is the core of SOLID <I>Server</I>. It serves the data requests coming through the SA Interface from the SQL Parser and Optimizer. The Database Engine stores the data into and retrieves it from the database files.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>The SOLID Database Engine provides:<A NAME="I2"></A>
</BLOCKQUOTE>
<UL>
<BLOCKQUOTE>
<LI>true multi-thread SMP architecture and parallel processing
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>intelligent row-level transaction management
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>unique combination of pessimistic and optimistic concurrency control
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>multiversioning to offer a consistent view of data with no locks
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>persistent identity for efficient post-relational object references
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>variable length columns and powerful BLOb support
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>reduced memory usage by prefix and suffix compressing of index leaves
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>intelligent transactions for mobile data synchronization
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>automatic roll-forward recovery
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>optional hot standby replication
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>scalability from small mobile devices to SMP RISC environments
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>small footprint starting from 300 kB RAM and disk space
</BLOCKQUOTE></UL>
<P><A NAME="I3"></A><A NAME="I4"></A><A NAME="I5"></A><A NAME="I6"></A><A NAME="I7"></A><A NAME="I8"></A><A NAME="I9"></A><A NAME="I10"></A><A NAME="I11"></A><A NAME="I12"></A><A NAME="I13"></A><A NAME="I14"></A><A NAME="I15"></A><A NAME="I16"></A><A NAME="I17"></A><A NAME="I18"></A><A NAME="I19"></A><A NAME="I20"></A><A NAME="I21"></A><A NAME="I22"></A><A NAME="I23"></A><A NAME="I24"></A><A NAME="I25"></A><A NAME="I26"></A><A NAME="I27"></A><A NAME="I28"></A><A NAME="I29"></A>
<IMG SRC="gtd/td000019.gif" WIDTH = 115 HEIGHT = 152 ALT="Undisplayed Graphic">
<BLOCKQUOTE>
<P><I>SOLID Database Engine offers scalability from small mobile devices to heavy-weight </I><I>multiprocessing environments. The unique Bonsai Tree technology offers care-free transaction </I><I>processing power and reliability within an exceptionally small footprint. These features allow </I><I>easy embedding and large scale deployment.</I>
</BLOCKQUOTE>
<A NAME="E10E17"></A>
<H2>
<FONT FACE="Arial"><B>Innovative Bonsai Technology</B><A NAME="I30"></A></FONT></H2>
<BLOCKQUOTE>
<P>In SOLID <I>Server</I>, the active new data is separated from older, more stable data. The data storage is implemented internally as two separate indexing systems: the Bonsai Tree and the storage server. 
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>The unique Bonsai Tree is the small active index efficiently storing new data in the central memory and maintaining multiversion information. The Bonsai Tree performs concurrency control, easily detecting if any operations conflict with each other. This minimizes the effort needed for validating transactions.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>More stable data is maintained in the storage server. Data is transferred to the storage server as a highly-optimized batch insert, thus minimizing the hard disk load.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>This division is invisible to the SOLID <I>SQL API</I> .
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>
<FONT FACE="Arial"><B>Storage Server</B><A NAME="I31"></A></FONT>
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>The storage server uses a B-tree variation to store all permanent indices in the database file. It is used to store both secondary keys and the primary keys. Also the data rows are stored as the primary key values actually containing all the columns of the rows. There is no separate storage method for data rows, except for BLObs and other long column values.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>Indices are separated from each other by a system-defined index-identification inserted in front of every key value. This mechanism divides the index tree into several logical index subtrees, where the key values of one index are clustered close to each other.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>Each key value in the index has a time stamp. The time stamp is the start number of the transaction that inserted the key value. 
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>
<FONT FACE="Arial"><A NAME="I32"></A><A NAME="I33"></A><A NAME="I34"></A><A NAME="I35"></A><A NAME="I36"></A><A NAME="I37"></A><A NAME="I38"></A><A NAME="I39"></A><A NAME="I40"></A><A NAME="I41"></A><A NAME="I42"></A><B>Main Memory Bonsai Tree</B><B> with a Consistent View of Data</B></FONT>
</BLOCKQUOTE>
<TABLE >
<TR>
<TD WIDTH=144 VALIGN=top >
<P><A NAME="I43"></A><A NAME="I44"></A><A NAME="I45"></A><A NAME="I46"></A><A NAME="I47"></A><A NAME="I48"></A><A NAME="I49"></A><A NAME="I50"></A><A NAME="I51"></A><A NAME="I52"></A><A NAME="I53"></A>
<IMG SRC="gtd/td000020.gif" WIDTH = 141 HEIGHT = 155 ALT="Undisplayed Graphic">
</TD><TD WIDTH=451 VALIGN=top >
<BLOCKQUOTE>
<P>The Bonsai Tree is a small index tree that is kept in the main memory. All delete, insert, and update operations are written into the Bonsai Tree. The key values in the Bonsai Tree nodes are both prefix and suffix compressed. 
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>The Bonsai Tree offers a full time dimension and multiversioning to all data and key values; thus the old versions of lately updated rows and related key values are available. This information is used for both concurrency control and ensuring consistent read levels for all transactions without any locking overhead. 
<BR></TD></TR></BLOCKQUOTE></TABLE>
<BLOCKQUOTE>
<P>When a transaction is started, it is given a transaction start number (TSN). The TSN is used as the read level of the transaction; all key values inserted later in the index are not visible to searches. This offers consistent index read levels. It looks as if the read operation was performed atomically at the time the transaction was started. This guarantees that the read operations always see a consistent view of the data and no locks are needed.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>
<FONT FACE="Arial"><B>Merging of Bonsai Tree to the Storage Server</B></FONT>
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>Later the new committed data is merged to the storage server in a batch operation and removed from the Bonsai Tree. The parameter MergeInterval can be used to control this operation. The presorted key values are merged as a background operation concurrently with normal database operations. This offers significant I/O optimization and load balancing. The deleted key values are physically removed during the merge.
</BLOCKQUOTE>
<P>
<IMG SRC="gtd/td000021.gif" WIDTH = 256 HEIGHT = 195 ALT="Undisplayed Graphic">
<BLOCKQUOTE>
<P><I>The Bonsai Tree is a small index tree that is kept in the main memory. All delete, insert, and </I><I>update operations are written into the Bonsai Tree. The Bonsai Tree offers a full time dimension </I><I>and multiversioning to all data and key values; thus the old versions of lately updated rows and </I><I>related key values are available. Later the new committed data is merged to the storage server in </I><I>a batch operation and removed from the Bonsai Tree.</I>
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>
<FONT FACE="Arial"><A NAME="I54"></A><A NAME="I55"></A><A NAME="I56"></A><A NAME="I57"></A><A NAME="I58"></A><A NAME="I59"></A><A NAME="I60"></A><A NAME="I61"></A><A NAME="I62"></A><A NAME="I63"></A><A NAME="I64"></A><A NAME="I65"></A><A NAME="I66"></A><A NAME="I67"></A><A NAME="I68"></A><A NAME="I69"></A><A NAME="I70"></A><A NAME="I71"></A><A NAME="I72"></A><A NAME="I73"></A><A NAME="I74"></A><A NAME="I75"></A><A NAME="I76"></A><A NAME="I77"></A><A NAME="I78"></A><A NAME="I79"></A><A NAME="I80"></A><A NAME="I81"></A><A NAME="I82"></A><A NAME="I83"></A><B>Bonsai Tree Benefits</B></FONT>
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>The Bonsai Tree offers the following benefits compared to traditional storage structures:
</BLOCKQUOTE>
<UL>
<BLOCKQUOTE>
<LI>All write (e.g., delete, insert, and update) operations are very fast and access only the small Bonsai Tree in the main memory. There is no need to access the massive disk based storage server at all.
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>All read operations have a consistent view of the data without any extra validation or locking.
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>All transaction concurrency control operations can be limited to the Bonsai Tree: conflicts between transactions can occur only with simultaneous write (e.g., delete, insert, and update) operations that are all stored in the small and efficient Bonsai Tree.
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>The time dimension within the Bonsai Tree offers simple and efficient tools for full optimistic predicate transaction validation. It means serializable transactions without locking, even avoiding the so-called phantom problem.
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>When the Bonsai Tree is merged to the larger storage tree, the key values can be inserted in a sorted order. When the storage tree is very large, this feature is especially important because it radically minimizes disk I/O.
</BLOCKQUOTE></UL>
<A NAME="E10E18"></A>
<H2>
<FONT FACE="Arial"><B>Data Clustering</B></FONT></H2>
<BLOCKQUOTE>
<P>SOLID <I>Server&#146;s</I> indexing system is used to store both secondary keys and primary keys containing also the actual data values. There is no separate storage method for data rows &#151; except for long columns, for example, binary large objects (BLObs).
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>SOLID <I>Server</I> is capable of clustering data easily, automatically, and efficiently. Clustering is determined by defining a primary key for a table. The primary key can also be called the clustering key because it physically clusters the data rows to the order given by the index.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>The set of columns used for clustering is called the row reference. The row reference uniquely identifies the data row. If the user-defined columns for the clustering key are not unique, the system ensures that the reference is unique by adding a unique row number to the reference columns. The row reference can also be called the row identifier.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>The row reference can be any combination of one or more columns. Each table has a different set of columns that are used for the unique row reference.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>Secondary key values refer to the data row using the row reference. This is also called primary key referencing. The data row is searched from the clustering key using the row reference as the search argument. However, if all the requested data is found from the secondary key, no search on the clustering key is performed.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>
<IMG SRC="gtd/td000022.gif" WIDTH = 239 HEIGHT = 185 ALT="Undisplayed Graphic">
</BLOCKQUOTE>
<BLOCKQUOTE>
<P><I>SOLID Server is capable of clustering data easily, automatically, and efficiently. Clustering is </I><I>determined by defining a primary key for a table.</I>
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>
<FONT FACE="Arial"><B>Index Compression Techniques</B><A NAME="I84"></A></FONT>
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>To save space in the index tree two methods are used when storing key values. First, only the information that differentiates the key value from the previous key value is saved. The key values are said to be prefix-compressed. Second, in the higher levels of the index tree, the key value borders are truncated from the end, i.e., they are suffix-compressed.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>
<IMG SRC="gtd/td000023.gif" WIDTH = 162 HEIGHT = 174 ALT="Undisplayed Graphic">
</BLOCKQUOTE>
<BLOCKQUOTE>
<P><I>All key values in the </I>SOLID<I> DBMS are prefix-compressed. Only the information that </I><I>differentiates the key value from the previous key value is saved.</I>
</BLOCKQUOTE>
<A NAME="E10E19"></A>
<H2>
<FONT FACE="Arial"><B>Unlimited Architecture</B></FONT></H2>
<BLOCKQUOTE>
<P>In designing SOLID Server, hard coded limits have been avoided right from the beginning. Thus the server can have any number of tables, rows, and indices.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>Character strings and binary data in SOLID <I>Server</I> are stored in variable length format. This feature saves disk space because no extra data is stored in the database. Variable length storage also eases the tasks of a program developer since the length of strings or binary fields need not be fixed. The maximum size for a single attribute is 2 GB and the maximum size of the database 32 TB.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>
<FONT FACE="Arial"><B>BLOb Support</B><A NAME="I85"></A><A NAME="I86"></A><A NAME="I87"></A><A NAME="I88"></A></FONT>
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>Images, video, voice, graphics, and intelligent documents test the capabilities of LANs for moving large data objects quickly. Client/server applications, as they increasingly become multimedia applications, will be called upon to move these BLObs over LANs. The clients will capture and display BLObs and then send them to the servers for storage. 
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>SOLID <I>Server</I> is capable of handling BLObs efficiently and automatically. BLObs, or binary fields larger than a configured limit, can be stored to special file areas that have optimized block sizes for large files. Large files are detected when they arrive to the server, and they are transferred directly to the file area allocated for BLOb storage. This is all done automatically and it does not require any action from the programmer or the administrator.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>
<IMG SRC="gtd/td000024.gif" WIDTH = 154 HEIGHT = 199 ALT="Undisplayed Graphic">
</BLOCKQUOTE>
<BLOCKQUOTE>
<P><I>Large files are detected when they arrive to the server, and they are transferred directly to the file </I><I>area allocated for BLOb storage. This is all done automatically, and it does not require any </I><I>action from the programmer or the administrator.</I>
</BLOCKQUOTE>
<A NAME="E10E20"></A>
<H2>
<FONT FACE="Arial"><B>Concurrency Control</B><A NAME="I89"></A><A NAME="I90"></A></FONT></H2>
<BLOCKQUOTE>
<P>The primary concurrency model of SOLID <I>Server</I> is a multiversioning and optimistic concurrency control method. In a multiversioning scenario, each transaction has a consistent, unchanging view of the database precisely as it was when the transaction began. If any data in that view is updated by another transaction, a new version of the row is generated while the old version of the data is visible to the older transactions.
</BLOCKQUOTE>
<H3>
<FONT FACE="Arial"><B>Optimistic Method</B><A NAME="I91"></A></FONT></H3>
<BLOCKQUOTE>
<P>The general advantage of the multiversioning model is that read transactions never need to restrict other transactions&#146; access to the data. This radically improves parallelism in typical mixed-load application environments.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>The optimistic concurrency control method provides the following benefits, especially in modern interactive GUI-based application environments:
</BLOCKQUOTE>
<UL>
<BLOCKQUOTE>
<LI>Data is always available to the users because locking is not used.
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>Users can browse through the data displayed in various lists and menus and choose to update any row at will. When the updating transaction is committed, the system checks whether someone else has already changed that row. SOLID <I>Server</I> does this automatically; no extra checking code is needed in the application.
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>The database access is improved since deadlocks are not possible.
</BLOCKQUOTE></UL>
<BLOCKQUOTE>
<P>SOLID <I>Server</I> offers fully serializable transactions. Serializability is achieved through a read-set validation scheme that prevents lost updates and phantom rows, for example.
</BLOCKQUOTE>
<TABLE >
<TR>
<TD WIDTH=240 VALIGN=top >
<P>
<IMG SRC="gtd/td000025.gif" WIDTH = 239 HEIGHT = 261 ALT="Undisplayed Graphic">
</TD><TD WIDTH=240 VALIGN=top >
<BLOCKQUOTE>
<P><I>Because of the time dimension of the Bonsai </I><I>Tree, each transaction has its own consistent </I><I>view of the database &#151; this makes locking </I><I>unnecessary. When the transaction commits, </I>SOLID<I> Server checks that no conflicting </I><I>operations were made to the small and efficient </I><I>main memory Bonsai Tree by simultaneous </I><I>transactions. Optimistic multiversion </I><I>concurrency control never causes operations </I><I>to wait for locks to be released. It offers better </I><I>performance for the majority of applications. </I><I>No effort is wasted in maintaining locks and </I><I>deadlock resolution algorithms.</I></TD></TR></BLOCKQUOTE></TABLE>
<H3>
<FONT FACE="Arial"><A NAME="I92"></A><A NAME="I93"></A><A NAME="I94"></A><A NAME="I95"></A><A NAME="I96"></A><A NAME="I97"></A><A NAME="I98"></A><A NAME="I99"></A><A NAME="I100"></A><A NAME="I101"></A><A NAME="I102"></A><A NAME="I103"></A><A NAME="I104"></A><A NAME="I105"></A><A NAME="I106"></A><A NAME="I107"></A><A NAME="I108"></A><A NAME="I109"></A><A NAME="I110"></A><A NAME="I111"></A><A NAME="I112"></A><A NAME="I113"></A><A NAME="I114"></A><A NAME="I115"></A><A NAME="I116"></A><A NAME="I117"></A><A NAME="I118"></A><A NAME="I119"></A><A NAME="I120"></A><A NAME="I121"></A><B>Locking</B><A NAME="I122"></A><A NAME="I123"></A></FONT></H3>
<BLOCKQUOTE>
<P>When necessary, SOLID <I>Server</I> can also use pessimistic (row-level locking) or mixed concurrency control methods.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>Individual tables can be set as optimistic or pessimistic with the SQL command
</BLOCKQUOTE>
<UL>
<P>
<FONT FACE="Courier New">ALTER TABLE <I>base-table-name</I> SET {OPTIMISTIC | PESSIMISTIC}</FONT>
</UL>
<BLOCKQUOTE>
<P>By default, optimistic concurrency control is used for all tables. 
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>Programmers can use the following locks: SHARED, INTENT, and EXCLUSIVE.
</BLOCKQUOTE>
<A NAME="E10E21"></A>
<H2>
<FONT FACE="Arial"><B>Transaction Isolation Levels</B><A NAME="I124"></A><A NAME="I125"></A></FONT></H2>
<BLOCKQUOTE>
<P>Applications have different requirements when it comes to concurrency control: some need to execute as if they had the database all to themselves, others can tolerate some degree of interference from other applications running simultaneously. To meet the needs of different applications, the SQL2 standard defines the following four alternative isolation levels:
</BLOCKQUOTE>
<UL>
<BLOCKQUOTE>
<LI>Read Uncommitted:
<BR>Allows read-only transactions to read data modified by transactions that have not yet committed. This &#145;dirty read&#146; mode of operation is not supported by SOLID <I>Server</I>. Its purpose has been to enhance concurrency in DBMSs that use locking, but it sacrifices the consistent view and potentially also database integrity.
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>Read Committed:
<BR>Allows a transaction to read only committed data. Still, the view of the database may change in the middle of a transaction when other transactions commit their changes. Also the phantom problem may occur. However, SOLID <I>Server</I> ensures that the results set returned by a single query is consistent by setting the read level to the latest committed transaction when the query is started.
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>Repeatable Read:
<BR>Allows a transaction to read only committed data and guarantees that read data will not change until the transaction terminates. SOLID <I>Server</I> additionally ensures that the transaction sees a consistent view of the database. This is the default isolation level provided by SOLID <I>Server</I>. Conflicts between transactions are detected by using transaction write-set validation. Still, the phantom problem may occur.
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>Serializable:
<BR>Allows a transaction to read only committed data with a consistent view of the database. Additionally, no other transaction may change the values read by the transaction before it is committed because otherwise the execution of transactions cannot be serialized in the general case. SOLID <I>Server</I> can provide serializable transactions by detecting conflicts between transactions. It does this by using both write-set and read-set validations. This way, SOLID <I>Server</I> avoids all concurrency control anomalies, including the phantom problem, without any locks!
</BLOCKQUOTE></UL>
<BLOCKQUOTE>
<P>The isolation level can be set to Serializable, for example, with the SQL2 command that affects all subsequent transactions:
</BLOCKQUOTE>
<UL>
<P>
<FONT FACE="Courier New">SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;</FONT>
</UL>
<A NAME="E10E22"></A>
<H2>
<FONT FACE="Arial"><B>Processes and Threads</B><A NAME="I126"></A><A NAME="I127"></A><A NAME="I128"></A><A NAME="I129"></A></FONT></H2>
<BLOCKQUOTE>
<P>A process is a program that has been loaded into memory and prepared for execution. A process consists of code, data, and other resources such as open files and open queues. Creating a new process is relatively slow and causes a substantial amount of overhead since the program must be read from a disk and loaded into memory. Communication between processes is done through protocols such as Named Pipes and Shared Memory. Many conventional DBMSs are using multi-process architecture.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>SOLID <I>Server</I> is designed to take full advantage of multi-thread architecture. It provides an efficient way of sharing the processor within an application, as opposed to between applications. A thread is a dispatchable piece of code that merely owns a stack, registers, and its priority. It shares everything else with all the other active threads in a process. Creating a thread requires much less system overhead than creating a process. Threads are loaded into memory as part of the calling program; no disk access is therefore necessary when a thread is invoked by another thread. Threads can communicate using global variables, events, and semaphores.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>If the operating system supports symmetric multi-threading between different processors, SOLID <I>Server</I> can automatically take advantage of multiple processors.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>When different threads are executing simultaneously in the server, they interact with each other using shared server objects. These shared objects are the most critical for the proper synchronization between different threads. Conflicts between different threads can exist only when they are using shared objects. 
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>The threading system of SOLID <I>Server</I> can be divided into two separate classes: 
</BLOCKQUOTE>
<UL>
<BLOCKQUOTE>
<LI>general purpose threads 
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>dedicated threads
</BLOCKQUOTE></UL>
<BLOCKQUOTE>
<P>The number of SOLID <I>Server</I> threads can be set in the configuration file.
</BLOCKQUOTE>
<H3>
<FONT FACE="Arial"><A NAME="I130"></A><A NAME="I131"></A><A NAME="I132"></A><A NAME="I133"></A><A NAME="I134"></A><A NAME="I135"></A><A NAME="I136"></A><A NAME="I137"></A><A NAME="I138"></A><A NAME="I139"></A><A NAME="I140"></A><A NAME="I141"></A><A NAME="I142"></A><A NAME="I143"></A><A NAME="I144"></A><A NAME="I145"></A><A NAME="I146"></A><A NAME="I147"></A><A NAME="I148"></A><A NAME="I149"></A><A NAME="I150"></A><A NAME="I151"></A><A NAME="I152"></A><A NAME="I153"></A><A NAME="I154"></A><B>General Purpose Threads</B></FONT></H3>
<BLOCKQUOTE>
<P>General purpose threads execute tasks from the server's tasking system. They can execute any of the following tasks:
</BLOCKQUOTE>
<UL>
<BLOCKQUOTE>
<LI>serving user requests
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>making backups
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>making checkpoints
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>making timed commands
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>index merging 
</BLOCKQUOTE></UL>
<BLOCKQUOTE>
<P>The most effective number of threads depends on the number of processors the system has installed. Usually it is most efficient to have between two and eight threads per processor. If there was a thread for every user, the performance of the system would actually degrade when hundreds of users are connected to the system.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>General purpose threads take a task from the tasking system, execute the task step to completion and then switch to another task from the tasking system. The task steps are designed to be small because they are used to simulate multi-threading in non-multi-threaded environments. The tasking system works in a round-robin fashion distributing the client operations evenly between different threads.
</BLOCKQUOTE>
<H3>
<FONT FACE="Arial"><A NAME="I155"></A><A NAME="I156"></A><A NAME="I157"></A><A NAME="I158"></A><A NAME="I159"></A><A NAME="I160"></A><A NAME="I161"></A><A NAME="I162"></A><A NAME="I163"></A><A NAME="I164"></A><A NAME="I165"></A><A NAME="I166"></A><A NAME="I167"></A><A NAME="I168"></A><A NAME="I169"></A><A NAME="I170"></A><A NAME="I171"></A><A NAME="I172"></A><A NAME="I173"></A><A NAME="I174"></A><A NAME="I175"></A><A NAME="I176"></A><A NAME="I177"></A><A NAME="I178"></A><A NAME="I179"></A><B>Dedicated Threads</B></FONT></H3>
<BLOCKQUOTE>
<P>Dedicated threads are dedicated to a specific operation. The following dedicated threads may exist in the server:
</BLOCKQUOTE>
<UL>
<BLOCKQUOTE>
<LI>I/O manager thread
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>communication read threads 
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>one communication select thread per protocol, i.e., selector thread
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI><A NAME="I180"></A><A NAME="I181"></A><A NAME="I182"></A><A NAME="I183"></A><A NAME="I184"></A><A NAME="I185"></A><A NAME="I186"></A><A NAME="I187"></A><A NAME="I188"></A><A NAME="I189"></A><A NAME="I190"></A><A NAME="I191"></A><A NAME="I192"></A><A NAME="I193"></A><A NAME="I194"></A><A NAME="I195"></A><A NAME="I196"></A><A NAME="I197"></A><A NAME="I198"></A><A NAME="I199"></A><A NAME="I200"></A><A NAME="I201"></A><A NAME="I202"></A><A NAME="I203"></A><A NAME="I204"></A>communication server thread, i.e., RPC server main thread
</BLOCKQUOTE></UL>
<BLOCKQUOTE>
<P>The communication threads are described in the chapter <I>Network Services</I>.
</BLOCKQUOTE>
<H3>
<FONT FACE="Arial"><B>I/O Manager Thread</B></FONT></H3>
<BLOCKQUOTE>
<P>The I/O manager thread is used for intelligent disk I/O optimization and load balancing. All I/O requests go through the I/O manager. Depending on the mode it is run in, it may pass the I/O request directly to the cache, or it may try to schedule it among other I/O requests. 
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>The I/O manager has three basic functions:
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>
<FONT FACE="Arial"><B>Prefetching</B></FONT>
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>When the I/O manager is handling a long sequential search, it enters a read-ahead operation mode. This happens in order to ensure that the next file blocks of the search in question will be read in the cache in advance. This naturally improves the overall performance of sequential searches.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>
<FONT FACE="Arial"><B>Preflushing</B></FONT>
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>The preflush operations prepare the cache for the allocation of new blocks. The blocks are written onto the disk from the tail of the cache based on a Least Recently Used (LRU) algorithm. Therefore, when new cache blocks are needed, they can be taken immediately without writing the old contents onto the disk.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>
<FONT FACE="Arial"><B>I/O ordering</B></FONT>
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>This function orders I/O requests by their logical file address. The ordering optimizes the file I/O since the file addresses accessed on the disk are in close range. This improves performance by minimizing the disk read head movement. 
</BLOCKQUOTE>
<H3>
<FONT FACE="Arial"><B>Buffer Management</B></FONT></H3>
<BLOCKQUOTE>
<P>SOLID Database Engine is designed to:
</BLOCKQUOTE>
<UL>
<BLOCKQUOTE>
<LI>minimize mass storage I/O operations by keeping as much information as possible resident in the central memory.
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>provide dynamically extendible and shrinkable work areas for variable and unlimited size of column values and BLObs.
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>provide a practical way of handling the Bonsai technology.
</BLOCKQUOTE></UL>
<BLOCKQUOTE>
<P>The basic element of the memory management system is a pool of central memory buffers of equal size. The amount and size of memory buffers can be configured to meet the demands of different application environments.
</BLOCKQUOTE>
<H3>
<FONT FACE="Arial"><B>Log Manager</B></FONT></H3>
<BLOCKQUOTE>
<P>The task of a log manager is to ensure that the effects of a transaction are written to permanent storage immediately at commit time. The SOLID log manager has been designed to ensure robustness with optimal performance. 
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>The log manager of SOLID <I>Server</I> can run in three different operation modes. The choice of logging method depends on the log file media and the level of security needed. All pending transactions are written to the log file as a single unit of work (i.e., the group commit method is used automatically).
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>
<FONT FACE="Arial"><B>Ping-pong Method</B></FONT>
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>This default method uses two separate disk blocks at the end of the log file to write the transaction commit records. The ping-pong method toggles between these two blocks until one block becomes full. This double block method offers practical combination of high performance and security. It ensures that no previously written data is lost even if the server loses power in the most critical section of the log write process.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>
<FONT FACE="Arial"><B>Write-once Method</B></FONT>
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>This method will write all pending log records immediately to the disk. An incomplete disk block is always padded with blanks. 
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>This is the method of choice when the log file storage media is, for example, a magnetic tape drive or a WORM. If the server runs on a single thread, this method of logging is not recommended.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>
<FONT FACE="Arial"><B>Overwriting Method</B></FONT>
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>This method rewrites incomplete blocks at each commit until the blocks become full. It may be used when data loss from the last log-file disk block is affordable.
</BLOCKQUOTE>
<H3>
<FONT FACE="Arial"><A NAME="I205"></A><A NAME="I206"></A><A NAME="I207"></A><A NAME="I208"></A><A NAME="I209"></A><A NAME="I210"></A><A NAME="I211"></A><A NAME="I212"></A><A NAME="I213"></A><A NAME="I214"></A><A NAME="I215"></A><A NAME="I216"></A><A NAME="I217"></A><A NAME="I218"></A><A NAME="I219"></A><A NAME="I220"></A><A NAME="I221"></A><A NAME="I222"></A><A NAME="I223"></A><A NAME="I224"></A><A NAME="I225"></A><A NAME="I226"></A><A NAME="I227"></A><A NAME="I228"></A><A NAME="I229"></A><A NAME="I230"></A><B>Hot Standby Replication</B><A NAME="I231"></A><A NAME="I232"></A><B> </B></FONT></H3>
<BLOCKQUOTE>
<P>In the &#145;hot standby&#146; option, SOLID <I>Servers</I> can have two different roles: either the primary role or the backup role. The different roles can be changed dynamically after a failure. Typically, after a failure in the primary server, the backup server becomes the new primary server, and the old primary server becomes the new backup server. This change is automatic and dynamic. Only the initial roles of servers at start-up have to be configured manually.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>There can be only one primary server, but there may be multiple backup servers. All update transactions are executed on the primary server and copied to the backup server. Logically, copying transactions means that the transaction log writes from the primary server are copied to the backup server. The backup server runs a continuous roll-forward process updating the database.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>There are three alternative approaches for copying the log:
</BLOCKQUOTE>
<UL>
<BLOCKQUOTE>
<LI><B>1-safe.</B> In a 1-safe design, the primary transaction manager goes through the standard commit logic and declares completion when the commit record is written to the local log. In this design, throughput and response time are the same as in a single-system design. The log is synchronously spooled to the backup system. This design risks lost transactions in the case of primary system failure immediately after transaction commit. This alternative can also be called an asynchronous replication configuration.
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI><B>2-safe.</B> When possible, the 2-safe design involves the backup system in commit. If the backup system is up, it receives the transaction log at the end of commit phase 1. The primary transaction manager will not commit until the backup responds &#151; or until it is declared down. The backup transaction manager has the option of responding immediately after the log arrives or responding after the log has been forced into durable storage. The 2-safe design avoids lost transactions if there is only a single failure, but adds some delay to the transaction commit and consequently to the response time. This alternative can also be referred to as a hot backup configuration.
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI><B>Very-safe.</B> The very-safe design takes an even more conservative approach: it commits transactions only if both the primary and the backup agree to commit. If one of the two nodes is down, no transaction can commit. The availability of such a system is not as good as the availability of a single system. However, the very-safe approach avoids lost transactions unless there are two simultaneous site disasters.
</BLOCKQUOTE></UL>
<BLOCKQUOTE>
<P>The SOLID <I>Server</I> &#145;hot standby&#146; option uses the 2-safe replication design.
</BLOCKQUOTE>
<A NAME="E7E8"></A>
<P ALIGN=CENTER>
<A HREF="td000007.htm" TARGET="_self"><IMG SRC="gtd/graprev.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Previous Page"></A>
<A HREF="httoc.htm" TARGET="_self"><IMG SRC="gtd/gratoc.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="TOC"></A>
<A HREF="htindex.htm" TARGET="_self"><IMG SRC="gtd/graindex.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Index"></A>
<A HREF="td000009.htm" TARGET="_self"><IMG SRC="gtd/granext.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Next Page"></A>

<center><p><font SIZE=-2>Copyright &copy; 1992-1997 Solid Information Technology Ltd All rights reserved.</font></p></center>
</BODY></HTML>