Beginning SQL

In spite of all of these performance issues, there are very real and powerful benefits that result from having
a transaction log. Usually a machine failure, power outage, or other catastrophe has little or no effect on the
database since the transaction logs record modifications. If you need to roll back changes, everything
required to perform this function is available in the transaction log. Oftentimes the DBMS automatically
recognizes a failure and looks at the transaction logs to figure out what needs to be done to restore the
database to a consistent state. Sometimes you must use a special recovery utility to perform this function.
Remember that this discussion is just conceptual. The exact implementation details will vary dramatically
from DBMS to DBMS, and in fact you do not need to be concerned with these details. Turning on
and off transaction logs, tuning their size, and so forth are the domain of the database administrator
(DBA). If you have such a person, you are not normally allowed to even touch these database properties
yourself, and you need to go through the DBA if you need them changed for some reason. What you
should take away from this discussion is the concept of automatically recording every change in the
transaction log and then using these log files to roll back a transaction when required.
And finally, realize that the smaller database products, such as Microsoft Access, do not use transaction
logs, even though they do implement transactions. If you have a catastrophic failure in the middle of a
transaction, you have nothing to fall back on to help you out.
Locks
Locks are the key to implementing transactions in all DBMSs, and as such, the following sections spend
considerable time discussing locks, how they function, how they can help ensure consistency, and especially
how they can affect performance. The term lock means much the same thing in a database that it
does in life, to make some thing unavailable to some people at some times. In the case of a database, it
specifically means to make some data or data structure unavailable to other valid users of that data or
structure for some period of time. Perhaps you need to make the entire MemberDetails table unavailable
to every other user because you need to add or drop a field. Or perhaps you need to lock the data in the
Inventory table so that you can select and update specific records without other users seeing inconsistent
data as you do so.
Locks have nothing to do with user-level security, specifically, preventing a specific user or group of
users from accessing data. Their function is simply to prevent other users from momentarily accessing
data while an update or other critical usage of data is under way. Furthermore, in general you don’t
apply locks yourself; the DBMS applies the locks as it sees fit, although there is a LOCK TABLE syntax for
acquiring a lock of an entire table. Even though you don’t generally apply locks yourself, you still need
an understanding of how they operate so that you can understand how transactions impact system performance
because of the locks the system applies.
Locking Granularity
Transactions
The term granularity refers to the level or size of the structure to which a lock is applied. Most DBMSs
have the ability to apply locks at many different levels within the database, and it is useful to understand
what these levels are. Every lock has the potential to inconvenience other users, so you really want
to apply locks to the smallest unit possible so that you minimize the inconvenience. The following sections
examine granularity from the largest data unit (the entire database) down to the smallest common
unit (the record).
313