Presentation is loading. Please wait.

Presentation is loading. Please wait.

© 2002 by Prentice Hall 1 David M. Kroenke Database Processing Eighth Edition Chapter 11 Managing Multi-User Databases.

Similar presentations


Presentation on theme: "© 2002 by Prentice Hall 1 David M. Kroenke Database Processing Eighth Edition Chapter 11 Managing Multi-User Databases."— Presentation transcript:

1 © 2002 by Prentice Hall 1 David M. Kroenke Database Processing Eighth Edition Chapter 11 Managing Multi-User Databases

2 © 2002 by Prentice Hall 2 Multi-User Databases Serving the needs of multiple users and multiple applications adds complexity in… –design, –development, and –migration (future updates)

3 © 2002 by Prentice Hall 3 Multi-User Database Issues Interdependency –Changes required by one user may impact others Concurrency –People or applications may try to update the same information at the same time

4 © 2002 by Prentice Hall 4 Multi-User Database Issues Record Retention –When information should be discarded Backup/Recovery –How to protect yourself from losing critical information

5 © 2002 by Prentice Hall 5 Common Multi-User DBMS Windows 2000 –Access 2000 –SQL Server –ORACLE UNIX –ORACLE –Sybase –Informix

6 © 2002 by Prentice Hall 6 Role of the Database Administrator Organizations typically hire a database administrator (DBA) to handle the issues and complexities associated with multi-user databases. A DBA facilitates the development and use of one or more databases.

7 © 2002 by Prentice Hall 7 Data Administrator versus Database Administrator Data Administrator –Handle the database functions and responsibilities for the entire organization. Database Administrator (DBA) –Handle the functions associated with a specific database, including those applications served by the database.

8 © 2002 by Prentice Hall 8 The Characteristics of a DBA Technical –The DBA is responsible for the performance and maintenance of one or more databases. Diplomatic –The DBA must coordinate the efforts, requirements, and sometimes conflicting goals of various user groups to develop community-wide solutions.

9 © 2002 by Prentice Hall 9 Technical Skills of the DBA Managing the database structure Controlling concurrent processing Managing processing rights and responsibilities Developing database security Providing database recovery Managing the database management system (DBMS) Maintaining the data repository

10 © 2002 by Prentice Hall 10 Managing the Database Structure Managing the database structure includes configuration control and documentation regarding: –The allocation of space –Table creation –Indices creation –Storage procedures –Trigger creation

11 © 2002 by Prentice Hall 11 Configuration Control Post-implementation changes Procedures & Policies Address unanticipated problems

12 © 2002 by Prentice Hall 12 The Need for Documentation Crucial when trying to understand problems Backups and Restores Documentation provides the “paper” trail for changes

13 © 2002 by Prentice Hall 13 Documentation All structural changes must be carefully documented with the following: –Reason for change –Who made the changes –Specifically what was changed –How and when the changes were implemented –How were the changes tested and what were the results

14 © 2002 by Prentice Hall 14 Documentation Aids Version Control and Computer Assisted Software Engineering (CASE) tools automate and/or manage many tedious documentation tasks. Printing the data dictionaries after structural changes also helps eliminate many tedious documentation tasks

15 © 2002 by Prentice Hall 15 Controlling Concurrency Processing Concurrency control ensures that one user’s actions do not adversely impact another user’s actions At the core of concurrency is accessibility.

16 © 2002 by Prentice Hall 16 Aspects of Concurrency Control Rollback/Commit: Ensuring all actions are successful before posting to the database Multitasking: Simultaneously serving multiple users Lost Updates: When one user’s action overwrites another user’s request

17 © 2002 by Prentice Hall 17 Rollback/Commit Involve logical units of work (LUW). Commit when entire LUW successful. Rollback if any part of LUW is unsuccessful

18 © 2002 by Prentice Hall 18 Lost Update Problem When two or more users are attempting to update the same piece of data at the same time. Resource locking scenarios are designed to address this problem

19 © 2002 by Prentice Hall 19 Resource Locking A resource lock prevents a user from reading and/or writing to a piece of data The size of the piece of data (e.g., database, table, field) is termed the lock granularity

20 © 2002 by Prentice Hall 20 Types of Resource Locks Implicit versus Explicit Exclusive versus Shared

21 © 2002 by Prentice Hall 21 Two-Phased Resource Locking Two-phased locking, whereby locks are obtained as they are needed –A growing phase, whereby the transaction continues to request additional locks –A shrinking phase, whereby the transaction begins to release the locks

22 © 2002 by Prentice Hall 22 Deadlocks When two transactions are waiting on one another to release resources.

23 © 2002 by Prentice Hall 23 Avoiding Deadlocks Strategy 1: –Wait until all resources are available, then lock them all before beginning Strategy 2: –Establish and use clear locking orders/sequences Strategy 3: –Once detected, the DBMS will rollback one transaction

24 © 2002 by Prentice Hall 24 Resource Locking Strategies Optimistic Locking –Read data –Process transaction –Issue update –Look for conflict –If conflict occurred, rollback and repeat or else commit Pessimistic Locking –Lock required resources –Read data –Process transaction –Issue update –Release locks

25 © 2002 by Prentice Hall 25 Consistent Transactions Consistent transactions are often referred to by the acronym ACID –Atomic –Consistent –Isolated –Durable

26 © 2002 by Prentice Hall 26 ACID: Atomic A transaction consists of a series of steps. Each step must be successful for the transaction to be saved. This ensures that the transaction completes everything it intended to do before saving the changes.

27 © 2002 by Prentice Hall 27 ACID: Consistent No other transactions are permitted on the records until the current statement finishes This ensures that the transaction integrity has statement level consistence among all records

28 © 2002 by Prentice Hall 28 ACID: Isolation Within multi-user environments, different transactions may be operating on the same data. As such, the sequencing of uncommitted updates, rollbacks, and commits continuously change the data content. The 1992 ANSI SQL standards define four isolation levels and specify respective issues.

29 © 2002 by Prentice Hall 29 Summary of Isolation Levels

30 © 2002 by Prentice Hall 30 ACID: Durable Once committed, durable transactions are saved to the data permanently

31 © 2002 by Prentice Hall 31 Set-at-a-Time Versus Row-at-a-Time SQL statements act as filters for the entire data set. A cursor may be defined within a SQL statement to point to a particular record. Several types of cursors have been defined. The cursor type defines how the cursor behaves.

32 © 2002 by Prentice Hall 32 Types of Cursors

33 © 2002 by Prentice Hall 33 Database Security Database security strives to ensure… –Only authorized users perform authorized activities at authorized times

34 © 2002 by Prentice Hall 34 Managing Processing Rights and Responsibilities Processing rights define who is permitted to do what, when The individuals performing these activities have full responsibility for the implications of their actions Individuals are identified by a username and a password

35 © 2002 by Prentice Hall 35 Granting of Processing Rights Database users are known as an individual and as a member of one or more role Access and processing rights/privileges may be granted to an individual and/or a role Users possess the compilation of rights granted to the individual and all the roles for which they are members

36 © 2002 by Prentice Hall 36 Granting Privileges

37 © 2002 by Prentice Hall 37 Providing Database Recovery Common causes of database failures… –Hardware failures –Programming bugs –Human errors/mistakes –Malicious actions Since these issues are impossible to completely avoid, recovery procedures are essential

38 © 2002 by Prentice Hall 38 Database Recovery Characteristics Continuing business operations (Fall- back procedures/Continuity planning) Restore from backup Replay database activities since backup was originally made

39 © 2002 by Prentice Hall 39 Fall-back Procedures/ Continuity Planning The business will continue to operate even when the database is inaccessible The fall-back procedure defines how the organization will continue operations Careful attention must be paid to… –saving essential data –continuing to provide quality service

40 © 2002 by Prentice Hall 40 Restoring from Backup In the event that the system must be rebuilt or reloaded, the database is restored from the last full backup. Since it is inevitable that activities occurred since the last full backup was made, subsequent activities must be replayed/restored.

41 © 2002 by Prentice Hall 41 Recovery via Reprocessing This is a brunt-force technique. Simply re-type all activities since the backup was performed. This procedure is costly because of the effort involved in re-entering the data. This procedure is risky in that human error is likely and in that paper record-keeping may not be accurate.

42 © 2002 by Prentice Hall 42 Recovery via Rollback/Rollforward Most database management systems provide a mechanism to record activities into a log file.

43 © 2002 by Prentice Hall 43 Rollforward Activities recorded in the log files may be replayed. In doing so, all activities are re-applied to the database. This procedure is used to resynchronize restored database data. This procedure is termed a Rollforward.

44 © 2002 by Prentice Hall 44 Rollback Since log files save activities in sequence order, it is possible to undo activities in reserve order that they were originally executed. This is performed to correct/undo erroneous or malicious transaction(s). This procedure is known as a Rollback.

45 © 2002 by Prentice Hall 45 Managing the Database Management System (DBMS) In addition to controlling and maintaining the users and the data, the DBA must also maintain and monitor the DBMS itself. –Performance statistics (performance tuning/optimizing) –System and data integrity –Establishing, configuring, and maintaining database features and utilities

46 © 2002 by Prentice Hall 46 Maintaining the Data Repository The data repository contains metadata. Metadata is data about data. The data repository specifies the name, type, size, format, structure, definitions, and relationships among the data. They also contain the details about applications, users, add-on products, etc.

47 © 2002 by Prentice Hall 47 Types of Data Repositories Active data repository –The development and management tools automatically maintain and upkeep the metadata. Passive data repository –People manually maintain and upkeep the metadata

48 © 2002 by Prentice Hall 48 David M. Kroenke Database Processing Eighth Edition Chapter 11 Managing Multi-User Databases


Download ppt "© 2002 by Prentice Hall 1 David M. Kroenke Database Processing Eighth Edition Chapter 11 Managing Multi-User Databases."

Similar presentations


Ads by Google