Term
|
Definition
- series of database operations that are to be execute as one, unidividable.
- Users should never be able to see inconsistent data
- it should be impossible to complete a set of operations in such a way the database is left in an inconsistent state
|
|
|
Term
|
Definition
| Supervises all aspects of a transaction. Gives instructions to the recovery manager about changes/abortions/success of a current transaction. Gives instruction to the stored datamanger about what information and changes should be done on the physical file |
|
|
Term
|
Definition
| makes sure transaction has been commited. if transaction is rolled back it keeps track of all changes/cancelations |
|
|
Term
|
Definition
| interacts with physical files |
|
|
Term
|
Definition
| keep some data of DB in single memory. For easy access of data. DB will only be accecced if it is full |
|
|
Term
|
Definition
| the activity of ensuring that data can always be recuperated regardless of the kind of error |
|
|
Term
|
Definition
| physical file which is the diary of the RM, records before and after all operation so data base can correct if something went wrong. Has buffer which stores most recent image |
|
|
Term
|
Definition
| activity of coordinating operations of simultaneous transactions, which affect the same date, in such a way data cannot become inconsisten |
|
|
Term
|
Definition
| produces the same output of effects on the DB as a fully serial execution of the same transactions |
|
|
Term
|
Definition
| is an access privilege that can be granted over an object so that the object is manipulated by only one operation at a time |
|
|
Term
|
Definition
| specifies the rules that determine when transactions can obtain lock and release locks |
|
|
Term
|
Definition
| is a file with redundant information that is necessary to recuperate or restore thed ata after some data have been lost or damaged |
|
|
Term
|
Definition
- ID of the transaction
- ID of the record being used and the type of operation
- Before image
- After Image
- Current state of transaction
- checkpoint records
|
|
|
Term
|
Definition
| updates to the logfile should always precede the corresponding updates in the DB |
|
|
Term
| Force writing the logfile strategy |
|
Definition
| the logfile should be written to disk before a transaction can be commited |
|
|
Term
|
Definition
containts one row for each actie transactions
- contains: transaction indetifier, currrent state, and log sequence number of the most recent log record for this transaction
|
|
|
Term
|
Definition
- atomicity
- consistency
- isolation
- durability
|
|
|
Term
|
Definition
|
|
Term
|
Definition
| the content of the main memory is lost. Content of DB buffer is lost |
|
|
Term
|
Definition
| some data in the DB and/or the logife are damaged or destroyed |
|
|
Term
|
Definition
| data are written in real-time to two or more disks. Ubdates should be applied on every mirror disk in the same squence |
|
|
Term
|
Definition
| the database and the logfile are duplicated periodically |
|
|
Term
|
Definition
| Two updates happen close to each other and the update from the first transaction doesnt register |
|
|
Term
|
Definition
| two transactions happen and the second transaction is rolled back at the same time the other transaction does an operation on the account |
|
|
Term
|
Definition
| n transactions defined as a sequential odering of the operations of these n transactions, in such a way that for each transaction T in S the following holds: if operation i preceeds j in T , then operation i preceeds operation j in the schedule S. |
|
|
Term
|
Definition
| for transaction T of the schedule holds that all operations of the transaction are processed conseculatively. For a set of n transactions, there exist n! serial schedules |
|
|
Term
|
Definition
| no transaction starts until a running transaction has ended |
|
|
Term
|
Definition
| a schedule that is equivalent in its outcome to a serial schedule |
|
|
Term
|
Definition
| non-serial schedule that are equivalent to a serial schedule |
|
|
Term
|
Definition
| the actions belong to different transactions, at least one of the actions is a write operation,the actions access the same object |
|
|
Term
|
Definition
- assumes that conflicts between transactions occer rarely
- each operation is scheduled without delay
- at commit time the scheduler checks whether conflicts have occured between two transactions. If so all changes must be roled back
|
|
|
Term
|
Definition
- assumes that it is likely for conflict
- execution of the operation is delayed until schedular can overview the situation to enforce a schedule that minimises risk of conflict
|
|
|
Term
|
Definition
| two operations from different transactions conflict if one is a write and they are exectuted on the same object |
|
|
Term
|
Definition
| a set of rules enforcing that in case there where two conflicting operations trying to access the same object, the access to this object is granted to only a single operation at a time |
|
|
Term
|
Definition
| a variable associated with a DB object for which the value determines which operations are allowed at this time on the object |
|
|
Term
|
Definition
| locks are granted depending on the type of operations that are to be executed on the data |
|
|
Term
|
Definition
| existing locks are released |
|
|
Term
|
Definition
| grants and releases locks nased on lock table and a locking protocol |
|
|
Term
| exclusive lock(write lock) |
|
Definition
| transaction obtains the exlusive right to access an object no other transactions can read from or write to this object until the lock is released |
|
|
Term
|
Definition
| a transactions obtains the guarantee that as long as it holds the lock no transactions can write to that object |
|
|
Term
|
Definition
- determines which transactions get the exclusive lock when it is released
- when a shared lock is released it decides if another transaction can get a shared lock or it gradually removes locks in favor of an exclusive lock
|
|
|
Term
|
Definition
- when a transactions to read resp. write from/to an object it will first have to request and acquire a read lock resp. write lock with the lock manager
- lockmanager determines based on the compatibiliy matrix whether some operations are conlflicting or not and grants the lock right away or determines to postpone it
- requesting and releasing occers in growth phase and shrink phase
|
|
|
Term
|
Definition
| transactions acquires new locks without releasing any locks |
|
|
Term
|
Definition
| transaction releases locks without acquiring new ones |
|
|
Term
|
Definition
| the rollback of a transaction may cause a cascade of rollbacks of transactions that used the data that we uptaded by the intial transaction that was rolled back |
|
|
