* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Materialy/32/Lectures Oracle
Survey
Document related concepts
Commitment ordering wikipedia , lookup
Entity–attribute–value model wikipedia , lookup
Microsoft Access wikipedia , lookup
Microsoft SQL Server wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Serializability wikipedia , lookup
Functional Database Model wikipedia , lookup
Ingres (database) wikipedia , lookup
Relational model wikipedia , lookup
Oracle Database wikipedia , lookup
Concurrency control wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Clusterpoint wikipedia , lookup
Versant Object Database wikipedia , lookup
ContactPoint wikipedia , lookup
Transcript
Slovak University of Technology Faculty of Material Science and Technology in Trnava Information Systems Development The DBMS Oracle structure Oracle software deveopment tools Oracle applications Oracle database system Oracle network technology Oracle end user tools The DBMS Oracle The DBMS Oracle ORACLE ARCHITECTURE I. database architecture II. software architecture III. database processes IV. data dictionary I. Database architecture physical structure: as many as you like DB files distributed to as many as you like disks; containing all database objects like data structures, procedural objects, access structures, data at least two redo log files; protocolling and storing all changes of data; serve for recovery of the database after system crash at least two control-files; containing the basic structures and basic information about an Oracle database (moment of creation, names of all DB files, names of all redo log files und the sequence number of this, moment of the last checkpoint and corresponding redo log files, ...) Database architecture F6 F1 F2 F4 F3 F5 database files online redo log files control files Database architecture logical structure of the database files: DB files are assigned to tablespaces for each database at least one tablespace exists (SYSTEM), created at the same time with database; further can be created all database objects will be assigned to a tablespace creation possible only with DBA grant Database architecture physical sight to database files F4 F5 F6 F3 F1 F2 logical sight tablespace SYSTEM tablespace A F2 tablespace B F6 F1 F4 F3 F5 Creating a database deletes all data in the specified DB files, preparing them for new use; loosing of data for an existing database creating only possible with DBA grant create database [database] [controlfile reuse] [logfile filespec [, filespec] ...] [maxlogfiles integer] [datafile filespec [, filespec] ...] [maxdatafiles integer] [maxinstances integer] [archivelog | noarchivelog] [exclusive] Creating a database database name of the database filespec specification of a db-file in the form of ‘filename’ [size integer [k|m]] [reuse] size integer [k|m]] size of the database in K- resp. MByte reuse controlfile reuse maxinstances specifies the reuse (overwriting) or not of existing files existing control-files will be overwritten number of instances, accessing at the same time to the database (1-255) only one instance can access exclusive changes of any settings possible with alter database Creating a tablespace create tablespace tablespace datafile filespec [, filespec] ... [default storage storage] [online | offline] Creating a tablespace tablespace name of the tablespace filespec specification of a file containing the tablespace in form of ‘filename’ [size integer [k|m]] [reuse] size integer [k|m]] size of the database in K- resp. MByte reuse storage specifies the reuse (overwriting) of existing files default parameter for all objects prepared in the tablespace, e.g. (initial 10k next 50k minextents 1 maxextents 999 pctincrease 10) online | offline makes the tablespace directly accessable changes are possible with alter tablespace, drop tablespace, ... Structure of a tablespace types of objects resp. kinds of segments in a tablespace: tables (data segments) indexes (index segments) rollback segments temporary segments each table, index, rollback segment is assigned to exactly one segment in the concerning tablespace; temporary segments will be created by Oracle assignment to a tablespace depends on tablespace of the objects owner owner options options in the create statement of the object Structure of a tablespace database files create table D create index create rollback segment created by Oracle if necessary (temporary) I R T Structure of segments segment is created by extents (= memory ranges of determinable size) differentiation between initial extents and next extents next extents can have an increasing factor additionally (pctincrease) extent contains Oracle datablocks of mostly 2 KByte specification of storing parameters in create / alter e.g.. for tablespace table index rollback segment Structure of segments example: storage ( initial next minextents maxextents pctincrease freelist 20 MB, 10 MB, 3, 80, 15, 3) supervision of tablespaces and tables by view on data dictionary: select * from user_tablespaces; select * from user_tables; Structure of database blocks smallest units of a database are blocks; are stored in the extents of segments configuration of datablocks by pctfree, pctused, initrans, maxtrans database blockheader free range for expanding records pctfree database block insert area (slip) minimal filling pctused Structure of database blocks database blockheader contains management information (row directory, transaction directory) data range is divided in pctfree und pctused; important for varchar2-data (pctfree) and balanced filling of all blocks if possible (pctused) Structure of records smallest logical units of the database; containing record header and record body record header: min. 3, max. 5 Bytes record body: data as specified by create table statement incl. column length, but not absolute in the defined order (LONG und LONG ROW always at the end) Structure of records column length 1 orr 3 Byte record header number of columns 1 Byte record header 2 Bytes cluster key (optional) 1 Byte data of column column lengt variable (VARCHAR2) 1 or 3 Byte fixed (CHAR) data of the columns linkaddress for records > blocksize (Byte) Database architecture tablespace ORACLEdatabase file segment data table index index rollback extent temporary db block Database architecture Database architecture views to the data dictionary: dba_data_files shows all DB files and there state dba_tablespaces shows all tablespaces and there state dba_freespaces shows the free memory within the tablespaces dba_quota shows the tablespace-quotas of all users user_extents (all_extents dba_extents) shows the extents of all tables and indexes of a user (resp. of all tables / indexes accessible by the user resp. of the whole database user_tables shows all tables of a user II. Software architecture application processes ORACLE DBMS ORACLE database DBWR DBC A C H E LGWR ARCH SMON PMON CHKP shared and dedicated ORACLE server processes ORACLE instance with DB cache (SGA) and background processes Software architecture Software architecture database system consists of ORACLE instance and several server processes being part of them ORACLE instance consists of database cache (Shared Global Area SGA) and several background processes ORACLE server processes (usually several activ at the same time) take it up to do e.g. parsing of SQL statements, executing of SQL statements, reading of DB blocks from DB files into the DB cache, ... III. Process structure ORACLE database server DB-Cache R E D O DB block buffer 1 4 DBWR 1 4 2 Shared SQL pool 3 LGWR 3 PMON 4 SMON 2 ARCH 4 5 5 4' database files redo log files into archives putted redo log files Oracle processes: database write process (DBWR) writes DB blocks changed in the DB cache back to the DB files is started when all DB blocks in the cache are covered and space in the memory is needed (blocks not used longest time are first restored) number of modified blocks in cache is too large not activated by an external event for a too long time (DBWR timeout ca. all 3 seconds) a checkpoint is reached (all changes will be restored, fileheader of DB files, control files and redo log files will be actualized; database is in a defined state) when activated synchronization with LGWR process necessary Redo log writer process (LGWR) restoring of changes in Oracle not synchroniously with commit, but "any time" asynchroniously DB changes are additionally protocolled in the redo log buffer (old + new value) LGWR writes redo log buffer to the redo log file when redo log buffer is filled up to 80 percent an user process signalizes an end of transaction the DBWR process signalizes a writing process (LGWR writes before) Redo log writer process (LGWR) at the end of a transaction (caused by commit) after the writing process the user process will receive the commit end message, ensuring that all finished transactions are made permanent in the redo log file (safety) all modified DB blocks will be kept as long as possible in the DB cache in the memory (performance) all transactions get very quickly the commit end acknowledgement (commit) when finished, because max. one redo log buffer has to be written to the disk (performance) Redo log writer process (LGWR) at a checkpoint the LGWR has additional tasks as follow: marking all modified DB blocks in the DB cache und so prepare them for restoring by the DBWR actualize all fileheaders relating to checkpoint write the actual redo log buffer to redo log file signalize the checkpoint to the DBWR process; DBWR then writes all marked DB blocks to the DB files for highly stressed DB systems checkpointing is optional a separate process (CHKP) Processing a transaction process insert into <table> update <table> delete from <table> commit ORACLE DB cache LGWR DBB L O C K B U F F E R R E D O DBWR writes asynchroniously modified DB blocks preceeded and possible actual transactions back to the DB files After commit the redo log buffer will be restored to the redo log file if ok then go on redo log files time DB files Process monitor (PMON) checking in periodically user processes have to be stopped by the systemmanager programs not regularly finished due to crash and that have locked database ressources unlocking and rollback the changes of this transaction System monitor (SMON) checking for opened transactions resp. not restored changes when database is started reason is e.g. not regularly finished DB working if closing the database by the DB administrator with shutdown immediate or abort crash of the DBMS or of the operating system hardware error, power fall out starts the recovery automatically; all completed transactions will written with help of the redo log files to the DB files, all uncompleted transaction will be rollbacked Archieving process (ARCH) optional background process when DB is started in ARCHIVE LOG mode with the redo log files it can be reconstructed ARCH copies redo log files to another medium, actualizes the control files Database cache DB block buffer DB blocks requested by the application program will be read into the DB cache, there processed and available for the user process blocks in the DB cache can be used by several processes (good tuning means 9 logical reads related to one physical read from disk) DB blocks are subject of last recently used algorithm (LRU); blocks not used for the longest time will be first restored if possible Database cache shared pool contains parsed SQL statements, compiled functions, procedures, data dictionary information and DB trigger (shared SQL region for public use) private SQL region for session oriented private information are also subject of LRU-algorithm instance information registration of locked resources, order for processing a queue, active transactions with information about state, ... db cache parameters are defined in init.ora IV. Data dictionary contents oriented view of an Oracle database users D A T A D I C T I O N A R Y user 1 user 2 user 3 user n DB resources, tables, indexes, ... Data dictionary Oracle database consists of data dictionary, storing all data responsible for regular function of the database = database for the management of database objects as many as you like users with different privileges database objects like tables, views, indexes, procedures, DB triggers, ... Data dictionary data dictionary consists of system tables, accessible by SQL internal level = real tables; no accesss by normal users external level = views to system tables data dictionary tables when creating a database the users SYS, SYSTEM and PUBLIC will be created automatically SYS is owner of all data dictionary tables (internal level) and of all data dictionary views (external level) = highest privileged user SYSTEM is owner of DB tables for Oracle tools PUBLIC is a user, representing all users of an Oracle system; all users have privileges of PUBLIC Data dictionary data dictionary content users and their privileges tables and their column names and datatypes statistics about tables and indexes index information access privileges to tables profile information and allocation to the users free space management ... Data dictionary Using the data dictionary for processing a SQL statement Oracle data dictionary select * from employees where salary>4500; 1. checking ok ? - exists the table "employees" ? - does user have the privileg to access ? - exists a column "salary" ? - what means '*' ? - is there an index to "salary" ? - exists statistical information ? - ... Oracle user data 2. execution 3. result Data dictionary views each view exists in 3 groups, accessible with the assigned prefix in SQL: USER consists all DB objects, where the user is owner z.B.: select * from user_tables ALL consists all DB objects, where the access by the user is possible z.B.: select * from all_tables DBA consists all database objects, where DBA privileges are necessary = overall view to the database z.B.: select * from dba_table Database Management Tasks of database management and administration Database integrity Administration of database privileges Backup / Recovery Database tuning User groups and their tasks DBMS-designers / -implementors: Database designers: development of DBMS problem analysis establishing the schema Applications programmers: realization of the end-user demanded applications User groups and their tasks Database administrators: maintenance of data / of the system user support minimization of expense for database management End-users: predefined queries (parameterized user) ad hoc queries (occasional user Tasks in the management phase system maintenance and monitoring keep documentation of the DBS keep statistics (access behavior, memory requirements, ...) monitoring of security protocols management of authorizations / creating new users system changes actualization of system documentation coordination and planning of the hardware development Tasks in the management phase system changes – cont. coordination of software maintenance extensions of the conceptual schema changes of the internal schema (optimizations) database administration allocation of user-id's granting / revoking of access privileges Oracle database administration initialize the database start and stop the database structuring the database definition of tablespaces file allocation for tablespaces distribution of database files to disks definition of rollback segments (size, count, place, ...) development and implementation of strategies for backup / recovery of the database development and implementation of security concepts monitoring of the databse activities tuning the database Database integrity - transactions definition: A transaction is a sequence of operations, leading the database in no- interruptable way from one consistent state to (not necessarly different) consistent state. features of transactions (ACID): Atomicity (no-interruptability, indivisibility): A transaction is an atomar unit, will be processed as a whole or not. Consistency (preservation of consistency): The correct processing of a transaction leads the database from one consistent state into a consistent state again. Isolation (isolated processing): The transaction must be serializable. Durability (durability of results): After a transaction is successfully finished, the changes may not get lost. That is because this information is needed for recovery of the consistent state in case of an error. Database integrity lost update problem (lost changes): If the transaction T2 reads the value of X, before the transaction T1 has stored the changes, the result of T1 is lost. temporary update problem (temporary changes): If a transaction fails during the processing and the changes in the database are already stored, another transaction can read the changed date before the the old state was re-stored. incorrect summary problem (dirty read): Incorrect values can be caused by e.g. adding up data elements over several records while another transaction updates one of these data elements. Oracle processing integrity protection of integrity by lock mechanism update employees set salary = salary * 1.04 where name like 'A%' locking granulates DB table DB block record locking escalation Oracle processing integrity typical locking granulates locking of tables a transaction locks the whole table for access by other transactions locking db blocks locking the DB block for other transactions, not affected blocks of the same table are free locking records only the affected records are locked, all the others are free for access Oracle locking mechanisms locking modes operation locking mode record table select - - insert X RX update X RX delete X RX DDL / DML-Befehle - X legend: X RX - remarks reading access needs no locks All DML-operations lock on record level; other transaction can read the tables record is eXklusively locked table is in Row EXclusively mode; RX can keep by some transactions; no locking escalation Oracle locking mechanisms principles Oracle locking is based on transactions directory within each DB block system change / commit number (SCN) Oracle transaction table within the rollback segment header process 1 update employees set salary = salary * 1.04 where pnr > 7000 or depnr = 40 table 'employees' process 2 insert into employees values (2341, 'Maier', 4500.00) process 3 select * from employees Oracle locking mechanisms processing transactions (default, automatically) when started transaction gets a transaction number (SCN) managed within the transaction table all records changed by the transaction get the SCN; record accepts as locked if the record-SCN corresponds with the SCN of an active transaction in the transaction table unlocking by deleting the SCN from the transaction table after ending the transaction (commit or rollback) Oracle locking mechanisms processing transactions (default, automatically) transaction 1 transaction table update <tab> set ... where ... 3982 transaction 2 3999 4003 update ... 4007 db block header 2100 3999 3501 1001 3999 X X db block Oracle locking mechanisms explicite locks additionally explicite locks with SQL possible lock table <tab> in <mode> (nowait) possible modes: X exclusive mode table is exclusively locked; other processes can have only reading access S shared mode table is in READ-ONLY-mode locked; other processes can also in S-mode lock and read; no process can change RX row exclusive mode default locking of Oracle; as many as you like processes can access in RX-mode and at the same time DMLoperations realize RS row shared mode allows other processes RS- und RX-locking; other processes can read the table, but not lock in X-mode; update change RS-locks into RX-locks SRX shared row exclusive mode other processes can read the table and lock in RS-mode; X- and S-locks are not allowed Oracle locking mechanisms toleration of locking of two DB processes process 1 process 2 X S RX RS SRX X - - - - - S - + - + - RX - - + + - RS - + + + + SRX - - - + + Oracle transaction concept t0 t1 account 63427 10,000 $ subtotal account 63427 8,000 $ transaction opened t2 t3 total account 63427 8,000 $ transaction account 5546 2,000 $ update konto set saldo=saldo-2000 where knr=63427 update konto set saldo=saldo+2000 where knr=5546 commit subtotal account 5546 4,000 $ total account 5546 4,000 $ Oracle transaction concept commit statement results in a transaction transaction is successfully ended all changes carried out are saved by storing the redo-logblock into the redo-log-file all locked ressources are cleared rollback statement results transaction is successfully ended all changed data will be re-changed again to the old value with the help of rollback segment all locked resources are cleared rollback must not be complete; transaction can set a <savepoint> Oracle problem: consistent read time t1 process 1 table 'employees' process 2 time select * from employees 2000 update employees set salary=salary*1.1 where depnr=30 result: 2000 ... 3300 (instead of 3000) 2200 (instead of 2000) 3000 (3300) by the process 2 changed data are also in the result (dirty read) 2000 (2200) problems: locking of the whole table for changes during reading causes loss of performance approval of "dirty read" is not acceptable t2 Oracle problem: consistent read Read-Consistency-model for reading without locks time t1 process 1 table 'employees' select * from employees process 2 time Rollback segment 2000 update employees set salary=salary*1.1 where depnr=30 result: 2000 ... 3000 2000 consistent state at the time t1; consistent read without locks 3000 (3300) 3000 2000 (2200) 2000 access to several tables in analogue way possible (read-only-transaction) as a snapshot on start-time t2 Tasks of the DB administration allocation of user identification number registration in DB table inclusively password checking of access privileges at each login; makes together with the terminal identificator possible to identify the user trying access without privileges registration of the person responsible of write operations in the systems protocol (user-ID + terminal-ID) in case of illegal access the database audit following the system protocol determines cases of illegal access during a certain period of time (user-ID, ...) Access control access control saves that all information in the database only by authorized user is read or changed resp. in the authorized format and is transported and processed only on authorized ways Access control: functions identification means the registration of an user in the system with the specification of his user-ID authentification means the checking process by the system to save that the user logging in with a definite password is also in fact this user authorization is the act of allocation the grants for access to the user. Who is allocating grants must have the grants themselve with grant option. Requirements on access protection graded units of protection definition of several grades of protection and several granularity of protecting objects must be possible clear interfaces access to the database has to be possible only via this defined interfaces decentral authorization access grants to distinguished groups of data should be allocated and revoked dynamic authorization allocating and revoking of grants must be possible during running the database system Requirements on access protection Different criteria of decision for precise adjustment to objective, legal and other facts the access grants should depend on several criteria dataflow and inference control storing of protected data and so making them accessable for other users is not allowed even for authorized users; remaining and using must be controlled little influence on system performance integral access control in the DMBD access control must be considered from the beginning of implementation Concepts of protection isolation (no common use of data) data and programs are only available for the owner; but in contradiction to the target of large database systems unlimited access control as many as you like users use all data commonly and have determined grants to the objects (data, programs, terminals) principle of smallest as possible privileges users get access grants to smallest possible units (access keys, values of attributes, ...); but not to storage media, files, record types, ... Concepts of protection partial ordering of privileges of using e.g. hierarchical order of user groups and therefore of access grants (partial) ordering of access operations e.g. hierarchical order of access operations; who has determined access grants has these also for all subordinated operations (e.g. who is allowed to update is allowed to read too) order of objects needs of protection classification of information on needs of protection Allocating grants in SQL allocating grants in SQL: grant { all <list of grants> all but <list of grants> } on <table> to <list of users> [with grant option] } on <table> from <list of users> revoking grants in SQL: revoke { all <list of grants> all but <list of grants> Access grants object privileges define allowed operations on database objects like tables views PL/SQL programs sequences system privileges define operations being able to carry out on the database resp. within the database server like creating a table (‘create table’ privilege) alter a tablespace (‘alter tablespace' privilege) creating a roll back segment (‘create rollback segment’ privilege) Access grants users privileges database tab1 insert, select, update proc1 execute view1 select update (a,b) tab2 create tablespace alter rollback segment Object privileges can be defined by grant statement (Form III) grant obj_priv [, obj_priv] ... | all [privileges] on [user.]object to {user | public } [, user] ... [with grant option] obj_priv for tables one of the following: ALTER, DELETE, INDEX, INSERT, REFERENCES, SELECT, UPDATE for views one of the following: DELETE, INSERT, SELECT, UPDATE for sequences: ALTER, SELECT update and references privileges can explain constraint for determined columns: grant col_priv [, col_priv] (col , col ...) on [user.]table to {user | public} [, user] ... [with grant option] all [privileges] specifies all referred object privileges on [user.]object specifies the refered object public specifies all users, futural too with grant option specifies that the receiver of the grant can pass this grant on other users System privileges can be specified by grant statement (Form I); DBS privileges necessary grant db_priv [, db_priv] ... to user [, user] ... [identified by password [, password] ...] db_priv DBA: allows to avoid default privileges und to take over DBA functions like create tablespace, create rollback segment; allows select on any tables and views, create for DB objects of other users, drop for DB objects of other users, grant for different DB privileges, create for public synonyms and DB links, complete DB export and import CONNECT: allows the user to connect the DB and to process DB objects he ownes the grants for; can create views, synonyms and DB links RESOURCE: allows to create DB objects with unlimited resources on all tablespaces user specifies a new or existing DB user name; existing one gets the grants additionally, a new one will be created with the specified grants password specifies the password of each specified user Available system privileges analyze any audit any audit system create cluster create any cluster alter any cluster drop any cluster alter database create database link create any index alter any index drop any index grant any privilege create procedure create any procedure alter any procedure execute any procedure create profile alter profile drop profile alter resource cost create public database link drop public database link create snapshot create any snapshot alter any snapshot drop any snapshot create role alter any role grant any role create synonym create any synonym drop any synonym create rollback segment alter rollback segment drop rollback segment alter system create session alter session restricted session create sequence create any sequence alter any sequence drop any sequence select any sequence create table create any table alter any table backup any table drop any table lock any table comment any table select any table insert any table update any table delete any table create tablespace alter tablespace manage tablespace drop tablespace unlimited tablespace force transaction force any transaction create trigger create any trigger alter any trigger drop any trigger create user become user alter user drop user create view create any view drop any view Resource privileges can be defined by grant statement (Form II) DBA grant necessary grant resource [ (quota [k|m] ) ] on tablespace to { public | user [, user] ...} resource specifies that the user is allowed to create DB objects in the specified tablespace quota specifies the amount of memory in Kbyte or Mbyte allowed to be consumed by the user; specifying 0 revokes the grant tablespace name of an existing tablespace user specifies an existing username Concept of roles individual allocation of privileges causes high expenditure of management remedy: definition of roles / task profiles ('create role' privilege necessary) : create role rolename; with grant statements roles get privilegs several and as many as you like roles can be allocated to users Concept of roles create role in92; grant in92 to in95; grant in92 to benny; grant select,insert on tab1 to in92; grant create tablespace, create any view, manage tablespace to in92; grouped privileges individual privileges States of roles categories of roles: available roles: all roles allocated to a user by grant default roles: after Oracle logon already active roles; defined by alter user statement, must be allocated to a user by grant active roles: actually for a user activated roles; can be activated and deactivated during a session with set role ('set role' privileg necessary) deactivated roles: currently deactivated roles of the user States of roles available roles b d a shows all roles of the user e c default roles select * from user_role_privs; select * from user_role_privs; alter user benny default role b, d; d b 'DEF'-Column= YES (default) NO (no default) logon activated roles select * from session_roles; b c d deactivated roles b c d a e select granted_role from user_role_privs MINUS select role from session_role; Operations with roles create a role create role rolename; giving privileges to a role grant sys_privs, obj_privs to role; allocating roles to users / roles grant role1 to user / role2 revoking role from user / role revoke priv / rolle from user / role activate / deactivate roles set role role1, ... set role all; set role all except role1, ... set role role identified by pw; define role as default role alter user user default role role, ... drop a role drop role role; Backup - principles Backup – is a way how to save a data. The replicas of data include part of database - control files and data files. Backup is possible to use for: database, tablespace, tables, materialized views datafiles, control files or archived redo logs. Backup is possible to perform: • with Export utility • with Recovery Manager Backup - Export utility • EXP MSADMIN/msvp PARFILE= E:\oracle\exp\MSVP.EXP MSVP.EXP obsahuje: FILE=E:\oracle\exp\MSVPEXP.DMP LOG=E:\oracle\exp\INFOEXP.TXT OWNER=MSADMIN BUFFER=8192 • IMP Scott/Tiger PARFILE=E:\oracle\exp\MSVP.IMP MSVP.IMP obsahuje: FILE=E:\oracle\exp\MSVPEXP.DMP LOG=E:\oracle\exp\INFOIMP.TXT FROMUSER=MSADMIN TOUSER=Scott BUFFER=8192 Restore Restore – is a process that use backup for renew lost or damaged files. Using of restore: command cp – in Unix command restore – in RMAN (Recovery Manager). Backup and Restore Recovery - principles database as a whole must be consistent in the most varied error situations, competition control protects consistency in detail only target: no approval of data loss kinds of errors: abnormal end of a user program that carried out changes without reaching commit abnormal end of the database system (crash of the DB server) abnormal end of the operating system (crash of the operating system) loosing database files (disk error) Recovery - principles recovery procedures of Oracle: process recovery (if the user program was crashed) instance recovery (if the DB server or the operating system was crashed) medium recovery (in case of loss of database files) Recovery - run of a transaction process DB cache DB buffer update employees set salary=2000 where salary=1000; 1000 2 2000 commit; rollback segment buffer 1 1000 redo log buffer 3 1 RS 1000 4 1 DW 2000 5 1 commit 0 6 redo log files 1000 DB files 1 RS 1000 1 DW 2000 1 commit Recovery - run of a transaction 0. read the DB block into the DB cache (if not already available); lock the affected DB record 1. copy the actual value into the rollback segment buffer 2. changing within the DB block (1000 ---> 2000) 3. rollback segment changes will also be protocolled into the redo log buffer (neuer item in RS: 1000) 4. new value of data will be protocolled (DW 2000) 5. end of transaction by commit, item in redo log buffer 6. commit causes writing of the redo log buffer into the redo log file (LGWR process) 7. end of commit message to the user program after successful writing of the redo log file DB file remains unchanged; but all changes are permanent Process recovery example: value ‘salary‘ changed from 1000 to 2000; afterwards crash of the user program without commit result: record is changed in DB cache (new value 2000) record is exclusively locked by the crashed program entries in rollback segment and in redo log buffer are done Process recovery solution: PMON process checks (ca. all 20 sec) whether DB resources of no longer existing process are locked process number in DB cache available, process in operating system not active PMON initializes rollback of the opened transaction (old value from the rollback segment will be copied into the DB block, record will be unlocked) Process recovery process update employees set salary=2000 where salary=1000; DB cache DB buffer 1000 comment rollback segment buffer 1000 2000 crash of the user process 2000 1000 1000 PMON background process: recognizes that the user does not exist rollback: old value from RS will be restored; unlocking Instance recovery several transactions are affected situation at the time of system crash: process DB cache DB-Puffer update employees set salary=2000 where salary=1000; 1000 commit; rollback segment buffer 1000 2000 redo log buffer 1 RS 1000 1 DW 2000 1 commit update department set city='Leipzig' where city='Halle' Halle Halle Leipzig Halle 1 DW Leipzig redo log files 1000 DB files 1 RS Halle 1 RS Halle 1 RS 1 1000 DW Leipzig 1 DW 2000 1 commit Instance recovery SMON process: execute a roll forward for each closed transaction from the redo log file (commit exists), a rollback for each open transaction (commit doesn’t exist) start the recovery from the check point SMON background process DB files redo log files 1000 1000 2000 Halle Halle Leipzig 6 1 2 3 1 RS 1000 4 5 2 RS Halle 1 DW 2000 1 commit 2 DW Leipzig Instance recovery transaction 1: 1. RS item will be written from the redo log file to the DB into the RS (1000) 2. changed value will be written into the DB (2000) 3. commit record in the redo log file affects deletion of the RS item transaction 1 completely recreated transaction 2: 4. RS item will be written from the redo log file to the DB into the RS (Halle) 5. changed value will be written into the DB (Leipzig) 6. commit record in the redo log file is absent and will be recreated with help of the RS item transaction 2 is cancelled Medium recovery requirements: DB have to run in archive mode periodically backups have to be made redo log files have to be archived (ARCH process) in case of problems the DBA has to bring back the archived files manually in Oracle several backup / recovery methods (online/ offline) are available DB tuning - idea tuning process, to provide optimal performance on a given platform and in a determined application and datastructural profile DB tuning - tuning levels datastructure logical structure of DB objects index structure cluster (index / hash) sequences SQL operations SQL optimization (statistical / rule based method) determination of statistics of the DB objects application kind of configuration integrity constraints in the DB server / application (declarative / procedural method) stored PL/SQL programs discrete transactions DB server DB cache optimization (DB block buffer pool / shared pool for SQL objects / data dictionary) checkpointing database object distribution to different disks rollback segments (number / distribution / number of transactions per RS) redo log file (size / disk) DB tuning - datastructure level influences: logical structure of tables appropriate index structures primary key creates automatically an unique index for foreign key there should be non unique indexes (referencing creates then only an index entry lock) indexes to columns and combinations of columns only if necessary and selectivity is expected DB tuning - SQL statement level SQL optimizer: works with rules corresponding to evaluation of where clauses based on statistics created with the help of the analyze statement and stored in the data dictionary (Oracle default method), e.g.: for a table: number of records number of DB blocks of the table number of not used DB blocks averagely free space within the DB blocks number of chained records number of unique values per column DB tuning - SQL statement level for an index: minimal / maximal value of each column height of the index tree number of index blocks on sheet level number of unique values within the index minimal / maximal value of the index average number of index blocks per index value average number of DB blocks per index value additional possibility: information for faster access DB tuning - SQL statement level possibilty to trace: set Oracle session by alter session statement sql_trace=true and collect information in a trace file, e.g. schedule for access of each SQL statement CPU time for execution / parsing of a statement number of physical / logical I/O's number of executions of a statement number of parsing processes evaluation with utility tkprof DB-Tuning - application level server mode (multithreaded server mode: many applications served by few server processes / dedicated server mode: big DB loadings) use of declarative or procedural integrity constraints stored PL/SQL procedures (in the shared pool on the server; little net loadings) DB tuning - DB server level size and configuration of the DB cache size of the DB block buffer (should be so that for one physical read operation from disk there are 10 to 20 logical read operations from DB cache) number of DB block buffers size of the shared pool SQL statements, PL/SQL programs, DB trigger data dictionary information DB tuning - database level redo log files on the fastest disks tablespace SYSTEM only used for data dictionary information temporary segments in an extra tablespace rollback segments in an extra tablespace provides rollback segments always with storage parameters data segments and index segments of the same DB object in different tablespaces on different disks