01 MaxDB Overview

SAP MaxDB Overview

In this section we cover a lot of ground detailing SAP MaxDB architecture. You will also learn about themost critical database parameters which are useful for the day to day administration of MaxDB

Please note that this section covers the following versions

SAPDB versions 7.4MaxDB 7.5, 7.6, 7.7

OLTP and OLAP

OLT P (Online T ransactional Processing) systems are the preferred databases to be used in processingdaily activities and are consequently optimized for fast processing, they handle large number ofconcurrent users and very large volumes of data, as the name suggests it is mainly used fortransaction applications.

OLAP (Online Analytical Processing) is an analysis technology that provides information for efficiententerprise planning in an intuitive way. T his concept was first introduced by the inventor of therelational data model Dr. Edgar F. Cobb and describes a multidimensional view of the data. OLAPsystems are supported by "integrated, time-dependent and non-volatile data" from a data warehouse.After the data has been obtained and formatted it can be evaluated in a multidimensional analysis.During this process the data is loaded from OLAP systems into the data warehouse at regular times.

A star schema is used as the database schema for data warehouse applications, it consists of a facttable and multiple (n) dimension tables. Cubes (OLAP cubes) are usually used to map thesemultidimensional business key figures. Data can be aggregated or mapped in detail at differentaggregation levels for example drill down, roll up, or the dimensionality can be reduced usingconditions (slice and dice). T he snowflake schema extends the star schema by classifying andnormalizing the dimension tables. T his way, an explicit hierarchy is setup, which results in structureddata but may also lead to increased query times.

MaxDB uses a relational database to physically store the OLAP data, this is called Relation OLAP(ROLAP), this process is very efficient at handling very large volumes of data.

SAP liveCache

SAP liveCache technology stores essential portions of data in the cache and hard disk space is usedonly for security-relevant operations. T he liveCache architecture is divided into a hard disk space area,a main memory area and a finally a process area.

MaxDB - Overview http://www.datadisk.co.uk/html_docs/maxdb/over...

1 of 14 03/13/2012 12:47 PM

T he table below provides the individual memory areas and the special features used

I/O Buffer cache

The I/O buffer is largest area in m em ory, i t is divided into the fol lowing areas

SQL data that ABAP program s can be accessed through the provided SQL inter faceOMS (Object management System ) data, see belowA conver ter that assigns logical page num bers to physical page num bers on the hard diskHistory m anagem entLog Queues

OMS data This area occupies the largest area in the I/O buffer cache, ideal ly al l data is stored in m ain m em ory

Pages

The I/O buffer cache is divided up into pages (by defaul t 8K in siz e), that are connected via pointers. Each page m ay containm ul tiple objects of the sam e class and several pages m ay contain objects of the sam e class. The latter grouped using page chainsand are assigned to a container (see below picture)

Object identifierThe system accesses the object data via an object identifier (OID), this identi fier includes the logical page num ber for thelocal iz ation in m em ory, a posi tion index (slot) for the local iz ation wi thin the page, and a version indicator for reusing the objectidenti fier .

OMS heap

this also occupies a por tion of m ain m em ory, the OMS heap includes local copies of the OMS data and thus can be considered thepr ivate cache of the OMS. You can control the heap using the fol lowing param eters

OMS_HEAP_LIMIT - l im i t the growth of the OMS heapOMS_HEAP_COUNT - defines i f the heap is divided into segm ents

If the OMS heap is not divided then the enti re heap is locked when a database procedure requests or releases m em ory.

Garbage co llecto rs

these are par t of the user kernel thread and delete no longer needed undo log fi les as wel l as the corresponding database objects.The are enable dur ing the fol lowing

The data area is greater than 90%, history data older than MinRetentionTime (MIN_RETENTION_TIME) param eterThe data area is less than 90%, al l pages in the indo log fi les that are younger than MaxRetentionTime(MAX_RETENTION_TIME) param eter are deleted.

The released pages are reassigned to the I/O buffer cache via free m em ory m anagem ent.

SAP MaxDB tools

SAP MaxDB primary consist of the database manager server (DBM server), the database server and thedatabase instance needs to be installed on the same host. T here are tools which allow you to accessthe database server remotely, these are known as the client tools.


2 of 14 03/13/2012 12:47 PM

T he database manager receives commands from clients and instructs the database kernel to executethese commands, if the client and server are on the same host then they can directly communicate;otherwise the client connects to the XServer via the standard port 7210, the XServer then forwardsthe commands onto the DBM server.

You can use a SAP router to access a XServer, the router can use either a non-secured or a securedprotocol to access the XServer, see the diagram below for an example on how this is setup

T here are two GUI tools that allow you to administer the database, it depends on what version of SAPMaxDB you are using

=> 7.7 - Database Studio< 7.7 - Database Manager GUI

T he Database Studio is the newer version and provides the same function as the DBMGUI but with lotsof additional functionality. It uses a JDBC connection to the X Server even if on the same host.

T he new DB Studio is based on the eclipse framework, so if you have used Eclipse before it will be veryfamiliar.


3 of 14 03/13/2012 12:47 PM

You can also use a commandline interface called dbmcli to access the database

Lastly there is a tool that allows you to run SQL commands against your data, this is called the SQLStudio, there is also a commandline version called sqlcli.

As you can see above SAP have created some great tools to administer and maintain your database,here is a quick recap

Administering

There are 2 ways to adm inister the DBM

Database Studio or DBMGUIdbm cl i com m andl ine

SQL access

There are three ways to access the database

Database Studio or SQL StudioWeb SQL (browser SQL access tool )sqlcl i com m andl ine

SAP have also a number of tools that allow you check, monitor, collect statistics, etc. I have detailed


4 of 14 03/13/2012 12:47 PM

them below and we will be covering them in greater detail in later sections.

/o pt/sdb/pro grams/bin/x_co ns

this uti l i ty is used to obtain detai led inform ation on the database. It can also be cal led rem otely using the dbm cl icom m and.

this tools can obtain inform ation and per form cer tain tasks

Cancel com m andsDiagnose/Release cache m em ory pagesKi l l sessionsDisplay inform ation on IO, Storage, tasks, active tasks, queues, statistics versions, runtim e, connections, etc

/o pt/sdb/pro grams/bin/xuserYou can store logon inform ation into a fi le that al lows a sim pl i fied logon process (does not ask a password). Think of i t asa kind of ssh where you can set i t up so that you don't need to supply a password.

dbanalyser

This tool is bui l t into the database m anager GUI, i t is used for per form ance tuning and is a great tool , setup i t up tocol lect inform ation for a interval per iod and then i t wi l l log what i t thinks are per form ance problem s wi th the database,for an exam ple scan tables problem s, I/O problem s, etc

This is a great tool and a m ust for al l DBA's, I wi l l be going into greater detai l in another section on per form ance tuning.

/o pt/sdb/pro grams/bin/xinstinfo

This tool outputs the di rectory structure of the speci fied instance that you give to i t. Use this tool i f you get path relatederrors to m ake sure that the setup is cor rect.

/o pt/sdb/pro grams/bin/x_ping This tool al lows you to check rem ote database connections and to check response tim es as wel l .

/o pt/sdb/pro grams/bin/dbmgetdisplay fi les from the server on the cl ient, for exam ple you m ay what to display the kernel m essages fi le, this wi l lal low to to do that

/o pt/sdb/pro grams/bin/sdbregview

Display inform ation on the instal led packages

/o pt/sdb/pro grams/bin/getdbro o t

display the root path of a database instance on a host

MaxDB Users

T here are three types of users

SQL User These users can only access the data, basical ly norm al users.

Administrato r User

These users have cer tain adm inistration r ights to access, i t is created dur ing instal lation and is cal led "DBADMIN". It canper form the fol lowing

can change pr ivi leges of al l usershas al l pr ivi lege r ightshas several system s tables dedicated to i tsel f

SYSDBA User Is basical ly both a SQL User and a Adm inistrator User

Database operators can have a number of rights and privileges, all are accessible via the GUI.

T here are three different types of SQL users

DBA can create other SQL users, create SQL objects, assign pr ivi leges

RESOURCEcan create tables, views and database procedures. It can also create database objects and m anage the user r ights of the objects i tcreated.

ST ANDARD can o nly access data, which m eans i t can only access tables, views, stored procedures for which i t has access to.

SAP MaxDB also uses the concept of roles, you assign the rights to roles and then the roles to users.


5 of 14 03/13/2012 12:47 PM

When you install MaxDB a standard set of users are created for a SAP system

SUPERDBA - system administratorCONT ROL - database operator with all server rightsSAPR3, SAP<SID> - SQL user of the DBA typeSAP<SID>DB - Database administrator for SAP systems with a Java stack (J2EE)

Database Architecture

T he MaxDB database is divided into three area's

Kernelthis is m apped by a process that is divided into several threads. The kernel threads are divided into user kernel threads (UKTs)and special threads. The runtim e envi ronm ent relates to the structure of the threads.

Main Memo ry Data is tem porary stored in m ain m em ory via caches. This is because m em ory is faster than disk accesses to retr ieve data.

Hard Disks This is the physical storage uni ts which are divided into logical volum es cal led data volum es and log volum es.

T he kernel thread is divided into several threads which in turn are divided again. you can display thethreads using the dbmcli command or the x_cons command

/opt/sdb/programs/bin/dbmcli -U <user> -d <database> -c show rte

/opt/sdb/programs/bin/x_cons x_cons> show rte

Special T hreads

Co o rdinato r threadThis is the fi rst thread star ted, i t reads the m em ory and process configuration of the database instance and star ts thecorresponding threads basis of the im por ted param eters and m oni tors them , i f any er rors the coordinator thread can stop them

Requesto r thread this thread receives cl ient logons and assigns them to a UKT task

Co nso le thread enables you to m oni tor the kernel via the x_cons program . It stores cr i tical m essages in the KnlMsg (knldiag) fi le

T imer thread used for tim e-dependent control processes

Dev threads

the term com es from the old devspace concept, the new version uses volum es. They are responsible for reading and wr i ting to thedata and log volum es. The num ber of threads is determ ined by the num ber of volum es, each is two per volum e and one for thewr i ting of the kernel trace. dev 0 plays a cr i tical role as i t coordinates and m oni tors the other dev threads. If a volum e is nolonger avai lable then dev 0 wi l l stop the threads for that volum e, l ikewise i f addi tional volum es are added then dev 0 wi l l star tthe threads for that volum e.

Asdev threads these threads are used for backups and are star ted when requi red

I/O Wo rker threadsare used when you use the asynchronous I/O im plem entation of the operating system , because user kernel threads di rectly cal lthe operating system inter face, these threads wai t for and receive the response

Diagram

User Kernel T hreads (UKT s)


6 of 14 03/13/2012 12:47 PM

UKT

these threads coordinate the execution of tasks and assign CPU tim e to them or give them control to the process job

If you have a server wi th m ul tiple CPUS then the below form ulas should be used to set the param eter MAXCPU

MaxDB only

MAXCPU = # of CPU's

MaxDB and SAP appl ication server running on the sam e host

MAXCPU = # of CPU's / 2

Tasks

T here are a number of tasks the database will perform

User T asksWhen a user or appl ication requests a connection exactly one user task is assigned to i t. There is a l im i t to the num ber of tasksdefined by the param eter MAXUSER-TASKS, thus you can control the upper l im i t. You can l im i t individual user tasks and therestack siz e by using the param eter _MAXTASK_STACK

Server T asks

Server tasks are responsible for

Wr i ting data and log backupsDeleting tables (indexes) asynchronouslyIm por ting log entr ies sim ul taneously and executing database transactions after database restar ts

The param eter MAXSERVERTASKS is used to control the num ber of paral lel tasks running, the tasks can block each other butusing the param eter ALLOW_MULTIPLE_SERVERTASK_UKTS wi l l using m ul tiple CPUs i f the server has them

Additio nal T asks

There are a num ber of addi tional tasks

Pager (data writer) - wr i tes data from the I/O buffer cache to the data volum es, this i s done dur ing savepoints. A devthread is used to per form the actual wr i ting. The system wi l l autom atical ly determ ine the num ber of pager tasks by thesiz e of the I/O cache and the num ber of volum esT imer - responsible for m anaging tim eout si tuations of SQL lock requests and database sessions. It also checks whetherbackups of log entr ies can be generatedLo g Writer - wr i tes log entr ies from the log queue to the log volum es. There is one log wr i ter per log volum e, you can usethe param eter MAX_BACKUP_TASKS to restr ict this taskEvent - receives m essages from the kernel and subm i ts them to the outside wor ld. This observer pattern enables al istener to register i tsel f for the event task and stay inform ed about the events. When the event dispatcher is inform edabout an event i t star ts the event handler , which m anages the event, for an exam ple a requests for a new data volum e arehandled autom atical ly.T race Writer - wr i tes the data from the buffer to the knltrace fi le i f the kernel trace option has been enabledUtility - per form s var ious adm inistration tasks and only one is avai lable.

Load Balancing

T asks are bundled by user kernel threads and are managed via cooperative multitasking by default.T he operating system can't affect how the database tasks are distributed across user kernel threads(UKT s), which means that it is possible that one UKT may become 100% utilized while another CPU isidle. Also using cooperative multitasking can also result in one long task blocking all other tasks in thesame UKT .

T he timer thread implements load balancing and distributes the tasks across corresponding UKT s, thetimer thread checks the wait time of the individual tasks of a UKT and adds them to calculate theoverall UKT wait time. If there are considerable deviations in the individual UKT wait times, the timerthread moves the waiting task of a UKT with a high waiting time to a UKT with a lower waiting time.

T he parameter LOAD_BALANCING_CHK to activate or deactivate load balancing by default it is


7 of 14 03/13/2012 12:47 PM

deactivated

Main Caches

Caches are used to temporary store data retrieved from the data volumes (physical disks), this is toincrease performance memory is a lot fast than disk. T he objective of a DBA is to keep the most useddata in cache, thus keeping the user happy.

T he I/O buffer cache is divided into three areas: data cache, converter and file directory. MaxDB uses ashadow page mechanism ( or shadow page table). T he basic concept of shadow storage is to maintaintwo versions of each changed information, an old consistent version in the "shadow" and a newinconsistent version. In other words when you change data during a transaction the changed data iswritten to a new location.

Shadow copies are based on savepoint cycles, this maps the writ ing of changes that have been made byusers from data cache (main memory) to data volumes since the last savepoint was made. In thisprocess the data is not overwritten but copied into free memory areas. T his enables you to restore aconsistent status of the database using the last completely saved savepoint in the event that thesavepoint operation fails unexpectedly. Only at the end of a savepoint cycle, that is, when the lastsavepoint is completely saved in the data volume, does the system release the obsolete data of theprevious savepoint for overwriting.

Now back to the I/O buffer cache and the converter, which maps data pages to physical pages, thesystem imports the converter into the converter cache when the database starts. If the system fails tofind a page number in the data cache, it searches the converter cache to calculate the physical positionof the data page in the data volume. At each savepoint the system writes the content of the convertercache to the data volume and assigns a version number. Each converter version maps a consistentstatus of the database.

T he converter is implemented as a B*tree in the data storage and is distributed across all data volumes.It can be read from multiple devices at the same time and copied into the converter cache. T he B*treeconsists of three levels, root level, index level and the leaf levels. T he root level is stored in the firstdata volume (restart area) which stores the position of the converters root page (see below diagram).

T he size of the converter page is 8K and the page can manage 1,861 data pages of a data volume. Each


8 of 14 03/13/2012 12:47 PM

converter entry contains the assignment of a logical page number to a physical data page and the datapage type. T here are three different types

T ype Descriptio n

P Perm anent data page

T Tem porary data page

S Data page of an SAP l ivecache database

For an example "173921 P 2/0002683621",

173921 is the logical page number and its a permanent data page2/ means that it is stored in the second volume0002683621 is the position location in the second volume

As MaxDB uses the shadow page mechanism there is a possibility that there are two copies a currentversion an a old version of each data page. It is therefore possible that two converter entries exist foreach data page, the physical addresses of the old and the new version.

File Directory

When you start the database, the entire internal file directory is imported into the main memory, itcontains information on the logical access to database objects such as the root page of tables whoselogical structure is also stored as a B*Tree. T he parameter CACHE_SIZE, can influence the size ofconverter and data cache.

T he state of a table before and after a change has been implemented is also called the before image orafter image. When a transaction is active the before image is stored in the data storage and released foroverwriting after a COMMIT . T he after image is transferred to the log queue and physically stored inthe log volume after a COMMIT .

Log Queues

T he log queue contains the log entries of the current transactions (redo log entries) and writes themto the log volumes using the log writer. You can define the log queues and their size

LOG_QUEUE_COUNT - number of log queuesLOG_IO_QUEUE - size of the log queues

A normal transaction would go like this

once the transaction starts the database stores the undo log entries (before image) of the changeobjectswhile the transaction is making changes to the data on the data volume these changes are storedon the log queues (after images) in main memoryif the log queue memory fills up they are written out to the log volume , a sequential number isassigned to each page the log writer writes a timestamp is also written (used to restore at certainpoint in time)Once the transaction is COMMIT T ED, the database writes the remaining redo logs entries fromthe log queue to the log volume.


9 of 14 03/13/2012 12:47 PM

if a ROLLBACK is performed the entries in the undo log are used to rollback the changes

Catalog Cache, Shared SQL Cache, Sequence Cache

In addition to the user data of a table, the catalog cache contains structure information (the databasecatalog). T he system assigns an area of the catalog cache to each user table, when the databasesession have finished, the system releases this area. If the catalog cache is full the system stores theinformation in the data cache. T he parameter CAT _CACHE_SIZE controls the size of the catalog cache.

T he shared SQL caches holds already executed SQL queries, thus memory is kept to a minimum. twoparameters are used to control the shared SQL cache SHARED_COMMANDCACHESIZE andSHAREDSQL.

T he sequence cache stores current values of database sequences, use the parameterSEQUENCE_CACHE to control its size.

One note to remember is that a page is 8K in size not 8192, so for example

Lo g Queue

Setting the param eter LOG_IO_QUEUE

50 pages x 8K ------------------ = 0.39MB 1024

Here is a display of my current caches

Data Volumes

Data volumes mainly store user data for tables, indexes, catalog data, converter data and beforeimages (history pages), T he parameter MAXDAT AVOLUMES define the maximum number of volumesthat can be used, you must restart the database in order to change this value.

T wo events will trigger writing to the data volumes

Data cache is too full or has been changed considerably so that too much data had to be written tothe data volume for the next savepointA savepoint was triggered

SAP uses the below formula

Data vo lume sizingdata volum e siz e = √total siz e

A 50GB would resul t in eight volum es, because the square root of 50 is eight rounded up.

SAP balance the I/O of a table because data is striped across all data volumes


10 of 14 03/13/2012 12:47 PM

Log Volumes

Log volumes contain the after images (redo log entries), the parameter MAXLOGVOLUMES definesthe maximum number of log volumes.

Writing to the log volumes is triggered by the following events

T he log queue is fullA transaction has successfully completed (committed)A savepoint is written

T here is one log writer for each log partition, however you can have a number of log volumes to onelog partition. Log partitions are written cyclically and can only be written over if it has already beensaved via a backup, however there is an option that will allow you to overwrite the log entries even ifthey have no been backed up but never use this is a Production environment.

You can set the system up so that a automatic backup will kick in at a specific threshold, thus you canmake sure the logs are backed up ahead of time, there are two strategies that can be used

T ime periodBased on division of the log area into segments, when a segment is full it is backed up thenreleased

Segments can cover upto 50% of the entire log area, by default the log area is divided into three equalsegments but this can be changed using the LOG_SEGMENT _SIZE parameter to configure thesegment size, try to size it so that you get at least one backup per day. Note that the database willfreeze if a a log becomes full and it requires a backup before it is released.

When a new database is created you need at least one data volumes and one log volume, you cannotchange the size of these, but you can add more data and log volumes at runtime. When you addadditional data and log volumes there might be a slight degradation in performance as the data isrewritten across all the volumes.

Savepoints and Snapshots

At savepoints, the database writes data changes that have been made from the data caches to the dataarea (storage) since the last savepoint. Savepoints are automatically write during any of the followingtriggers


11 of 14 03/13/2012 12:47 PM

Since the last savepoint, the system has filled 2/3 of the database log area with redo log entriesT he amount of time defined in the REST ART _T IME parameter has elapsedCreating any indexesPerform a backup

A savepoint always maps a consistent database status, this is due to the shadow storage mechanismand the version numbers, which are assigned successively and thus identify incomplete savepoints.Savepoints have three phases

Savepo int T hree Phases

First Phase Al l m odi fied perm anent data pages from the data cache to the data area

Seco nd Phase

The system wai ts for al l cur rent operations to end that need to be synchroniz ed for exam ple balancing operations inB*trees, then the system no longer perm i ts these operations

1.

no transactions are perm i tted2.for a restar t in the onl ine operational state, the system wr i tes a log entry. This indicates from which point in tim e thesystem has to im por t log entr ies. If i t is a restar t savepoint, the system determ ines the current posi tion of the log readerand stores i t as restar t inform ation

3.

the system stores transactions that are not yet com plete in data pages so that they can be im por ted4.the system m arks al l perm anent data pages as savepoint-relevant, the system releases al l blocked areas5.

T hird Phase

Al l m arks data pages are wr i tten to the data volum es, this includes undo log fi les of transaction that are not com pletebecause they are need after a restar t

1.

al l conver ter pages are wr i tten to the data area2.the restar t inform ation is updated, this contains conver ter version which is increased by one3.al l data pages that are no longer requi red are released4.

T o increase I/O operations all system resources are dedicated to phases 1 and 3.

A snapshot maps the current state of the data area, once a snapshot has been obtained you can returnto the state of the snapshot at any time or copy all the changes since the saved image.

Locking

Data is protected by a lock in case two users change the data at the same time, a lock can be eitherrequested implicitly by the database or by the application, there are three types of locks

Lo ck T ype Po ssible Objects Descriptio n

Shared Lo ckTablesData RecordsDatabase Catalog

Other transaction retain read access to the database object

Exclusive Lo ckTablesData RecordsDatabase Catalog

Other transactions can nei ther read/wr i te access to the database object, the lock is retained unti lthe transaction is com plete (com m itted or rol led back)

Optimistic Lo ck Data RecordsAn optim istic lock ensures only that the transaction that set the lock is inform ed i f anothertransaction has set an addi tional lock in the m eantim e. the system uses version num bers for thedata records

By default when the database is started the isolation level is set to 1, which means for read access todata records, the system ensures that no other transaction is holding an exclusive lock. For writeaccess a exclusive lock is implicitly set which is not released until the end of the transaction(committed or rolled back). A lock list is maintained by the system and the size of this list is set by theparameter MAXLOCKS. If a transaction requests too many locks this may result in lock escalation, yocan define a threshold value using the MAXSQLOCKS, this parameter identifies the percentage ofmaximum number of locks, after the threshold is hit the system triggers a lock escalation and convertsthe data records locks into table locks, the locks are only removed when the number of locks is below20%, it avoid lock escalations increase the size of the lock list.


12 of 14 03/13/2012 12:47 PM

Directory Structure

T he directory structure is in three parts

Independent Program Path - there is only one independent program path per systemIndependent Data Path - data, configurations and the run directories of database instancesDependent Program Path - there can be any number of database instances thus any number ofdependent program paths

Below contains critical directory paths that you need to know

<independent_pro gram_path> shared program s and l ibrar ies

<independent_pro gram_path>\runtime runtim e envi ronm ent of the cl ients i .e. JDBC

<dependent _data_path> instal lation di rectory of the version-dependent database software

<independent _data_path> data and configuration fi les of the database instances and appl ications

<independent _data_path>\co nfig configuration fi les for the database param eters and data for user author iz ation

<independent _data_path>\wrk\<database_name> run di rectory of the database (configuration and log fi les of the instances)

<independent _data_path>\wrk\<database_name>\data Data volum es

<independent _data_path>\wrk\<database_name>\lo g Log volum es

<independent _data_path>\wrk\<database_name>\DIAGHIST ORY

diagnosis fi les that save database errors, this can be changes using theDIAG_HISTORY_PATH param eter

Operational States

T here are four possible states

offline - the database kernel is not running, but you can send admin commands to the DBM serveradmin - database kernel is running but not connected to the data and log volumes, use this modefor recovery or restoringonline - the database instance is fully functionalstandby - only used with hot-standby databases

You can use either of the following to change the database state: DBMGUI, Database Studio orDBMCLI

T here is also three variants a kernel can run it

fast - standard variant with minimum logging activity for fast kernel in live modeslow - extensive logging activities and runtime checkstest - specific kernel variants for database tests

Database Parameters

T he database parameters are split into three groups

General database parametersSpecial database parametersSupport database parameters

All parameters can be changed when the database is running, but most of them will not come intoaffect until the database has been restarted. When you change a parameter the parameterconfiguration file is backed up with a version number you can restore this file using the param_restore


13 of 14 03/13/2012 12:47 PM

command. T he configuration file is in binary format, the text file <dependent_program_path>/env/cserv.pcf contains the default values.

the table lists the most important configuration files

File Name Path Descriptio n

<database> <indep_data_path>/config binary fi le that contains the star tup param eters on the instance in question

cserv.pcf <dep_program _path>/env test fi le contain the defaul t values

dbm.cfg <indep_program _path> configuration fi le for the database m anager

sdb /etc/opt configuration fi le of the SAP MaxDB software

lo ader.cfg <loader_app_data>/config Configuration fi le of the loader

dbanalyzer.cfg <indep_program _path>/env configuration fi le of the database analyz er

Previous Menu Next


14 of 14 03/13/2012 12:47 PM

01 MaxDB Overview

Documents

Transcript of 01 MaxDB Overview