Relational database ..

444 views
379 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
444
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Learning aims Attendees will gain insight into a practical application of relational database techniques studied during the semester. Learning objectives By the end of this lecture, students will be able to: Give a real-world example of potential concurrency conflict. Explain why different members of an organisation have different data requirements. Explain why continuous availability is expected in current UK banking practice (Customer expectation/ BACS & CHAPS service levels/ international banking/ profit). Name 3 mechanisms for achieving continuous availability (RAID, locking, switch location for disaster recovery). Specify elements of a recovery strategy (switch device, switch location, recover tablespaces – must be for entire tablespace set.)
  • Relational database ..

    1. 1. Databases in Context Wendy Moncur Department of Computing Science, University of Aberdeen
    2. 2. Databases in Context <ul><li>Database design in a major bank </li></ul><ul><li>Database management </li></ul><ul><li>6000-table Personnel database </li></ul>
    3. 3. Who am I ? <ul><li>Wendy Moncur </li></ul><ul><li>DataBase Administrator (DBA) at one of UK’s largest banks. </li></ul><ul><li>Designed databases for high performance & availability. </li></ul><ul><li>19 years industry experience. </li></ul><ul><li>Platform: DB2 & SQL </li></ul><ul><li>Largest database: 6000 tables </li></ul>
    4. 4. Why listen? <ul><li>DBA Average Minimum Salary £41,896 </li></ul><ul><li>DBA Average Maximum Salary £47,147 </li></ul><ul><li>Source: http://www.itjobswatch.co.uk </li></ul>
    5. 5. What does a DBA do? <ul><li>Development </li></ul><ul><ul><li>Database design & optimisation </li></ul></ul><ul><ul><li>Quality assurance of SQL </li></ul></ul><ul><li>Production </li></ul><ul><ul><li>Performance management </li></ul></ul><ul><ul><li>Database administration </li></ul></ul>
    6. 6. Case study: the monster database
    7. 7. Case study: the monster database <ul><li>6000+ tables </li></ul><ul><li>18000+ indexes </li></ul>
    8. 8. Part1: Challenges <ul><li>“ One size fits all” </li></ul><ul><li>External supplier </li></ul><ul><li>6000+ tables </li></ul><ul><li>18000+ indexes </li></ul><ul><li>1 tablespace </li></ul><ul><li>Short timescale </li></ul>
    9. 9. Challenges: “one size fits all”? <ul><li>One size does not fit all. </li></ul><ul><li>Performance of SQL statements dependent on: </li></ul><ul><ul><li>Database design </li></ul></ul><ul><ul><li>Index design </li></ul></ul><ul><ul><li>The DATA </li></ul></ul>
    10. 10. Challenges: “one size fits all”? <ul><li>Every company has different requirements. </li></ul><ul><li>Customers demand high performance... and control the budget. </li></ul><ul><li>Service Level Agreements ( SLAs ) dictate … </li></ul><ul><ul><li>Minimum transaction speed </li></ul></ul><ul><ul><li>Number of concurrent users </li></ul></ul><ul><ul><li>Number of remote locations </li></ul></ul><ul><ul><li>Daily system availability </li></ul></ul><ul><li>Database must be tailored to achieve site-specific SLAs. </li></ul>
    11. 11. Challenges: external supplier <ul><li>Software package & database from external supplier. </li></ul><ul><li>Cannot change this. </li></ul>
    12. 12. Challenges: 6,000+ tables <ul><li>Cannot change tables: no denormalisation allowed. </li></ul><ul><li>Supplied program code demands these tables exist. </li></ul><ul><li>Cannot change supplied program code unless essential . </li></ul>
    13. 13. Challenges: 18,000+ indexes <ul><li>Can change indexes: </li></ul><ul><ul><li>Unique indexes </li></ul></ul><ul><ul><li>Clustering indexes </li></ul></ul><ul><ul><li>Secondary indexes </li></ul></ul>
    14. 14. Unique index <ul><li>Defines what makes a row unique. </li></ul><ul><li>Components of the index cannot be changed. </li></ul><ul><li>Order of components can be changed. </li></ul>
    15. 15. Unique index <ul><li>E.g. – for Table “ EMPLOYEE ” </li></ul><ul><li>Unique index = DateOfBirth, Firstname, Surname. </li></ul><ul><li>Most queries ask for data where only Surname, Firstname are known. </li></ul><ul><ul><ul><ul><li>SELECT Surname, Firstname, DateOfBirth </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>From Employee </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Where Surname = “Jenkins” And Firstname = “Malcolm” ; </li></ul></ul></ul></ul></ul><ul><li>Recommendation: Change order of unique index to </li></ul><ul><li>Surname, Firstname, DateOfBirth. </li></ul>
    16. 16. Clustering indexes <ul><li>Defines the physical order in which rows of data should be stored. </li></ul><ul><li>Components of the index can be changed. </li></ul><ul><li>Order of components can be changed. </li></ul>
    17. 17. Clustering indexes <ul><li>E.g. – Table “EMPLOYEE” </li></ul><ul><li>Clustering index = DateOfBirth </li></ul><ul><li>Yet most queries order by EmploymentStartDate </li></ul><ul><ul><ul><ul><li>SELECT EmploymentStartDate, Surname, Firstname </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>From Employee </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Where Surname = “Jenkins” And Firstname = “Malcolm” ; </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Order by EmploymentStartDate; </li></ul></ul></ul></ul></ul><ul><li>Recommendation: Change clustering index to use </li></ul><ul><li>EmploymentStartDate. </li></ul>
    18. 18. Secondary indexes <ul><li>Not unique. </li></ul><ul><li>Do not dictate how the data is to be held. </li></ul><ul><li>Created to improve performance of queries and updates. </li></ul><ul><li>Increases cost of insert and update, as must be created and maintained along with the table. </li></ul><ul><li>Recommendation: Drop superfluous secondary indexes. </li></ul>
    19. 19. Challenges: One tablespace
    20. 20. Tablespace design <ul><li>DB2 data is stored in table spaces. </li></ul><ul><li>>= 1 table per tablespace </li></ul><ul><li>Tablespace design affects: </li></ul><ul><ul><li>Fragmentation </li></ul></ul><ul><ul><li>Availability </li></ul></ul><ul><ul><li>Performance </li></ul></ul>Database Tablespace Tablespace Tablespace Table Table Table
    21. 21. Tablespace design <ul><li>One tablespace, many tables. </li></ul><ul><li>Results in: </li></ul>A B C D E F G H I J Free space
    22. 22. Tablespace design <ul><li>One tablespace, many tables. </li></ul><ul><li>Results in: </li></ul><ul><ul><li>Fragmentation, leading to poor performance. </li></ul></ul><ul><ul><li>Seldom-used tables held with frequently used ones. </li></ul></ul><ul><ul><li>Maintenance work affects all tables, giving poor availability. </li></ul></ul>A B C D E F G H J Free space I
    23. 23. Many tablespaces <ul><li>Create many new tablespaces. </li></ul><ul><li>Split the tables between them, according to table function. </li></ul>
    24. 24. <ul><li>At least 4 test environments: </li></ul><ul><li>96,000 objects! </li></ul><ul><ul><li>((6,000 tables + 18,000 indexes) * 4 environments) </li></ul></ul><ul><li>3 months </li></ul>Challenge: Short timescale Vanilla Unit test System test <ul><ul><li>Pre-live </li></ul></ul>
    25. 25. Tools <ul><li>Use tools to… </li></ul><ul><ul><li>Check performance of each SQL statement </li></ul></ul><ul><ul><li>Manage change process </li></ul></ul>
    26. 26. Check performance <ul><li>“ EXPLAIN” </li></ul><ul><ul><li>Evaluates route to data for every SQL statement. </li></ul></ul><ul><ul><li>Identifies what indexes are used </li></ul></ul><ul><ul><li>Doesn’t identify redundant indexes </li></ul></ul><ul><ul><li>Doesn’t identify indexes that need to be changed. </li></ul></ul>
    27. 27. Manage change process <ul><li>Rigorous control needed </li></ul><ul><li>Achieved through… </li></ul><ul><ul><li>Consistent naming standards </li></ul></ul><ul><ul><li>Detailed record of every change </li></ul></ul><ul><ul><li>Consistent route through environments, no short cuts </li></ul></ul><ul><ul><li>DBA tools </li></ul></ul>
    28. 28. Part1: Recap of challenges <ul><li>Can’t change: </li></ul><ul><ul><li>“ One size fits all” </li></ul></ul><ul><ul><li>External supplier </li></ul></ul><ul><ul><li>6000+ tables </li></ul></ul><ul><li>Can change: </li></ul><ul><ul><li>18000+ indexes </li></ul></ul><ul><ul><li>1 tablespace </li></ul></ul><ul><ul><li>Short timescale </li></ul></ul>
    29. 29. Part2: The Production Database <ul><li>Does it perform? </li></ul><ul><li>Can the right people use it? </li></ul><ul><li>If disaster strikes, can the data be recovered? </li></ul>
    30. 30. Does the database perform? <ul><li>Database performance monitored against Service Level Agreements (SLAs). </li></ul><ul><li>Regular health checks carried out: </li></ul><ul><ul><li>Data stored in sequence? </li></ul></ul><ul><ul><li>Enough space? </li></ul></ul><ul><li>If sub-standard performance, further database design work done. </li></ul>
    31. 31. Can the right people access the data? PERSONNEL database
    32. 32. Can the right people access the data? Personnel team Query & update data at individual or regional level PERSONNEL database
    33. 33. Can the right people access the data? Personnel team Query & update data at individual or regional level PERSONNEL database DBA Backup/ restore data Reorganise data Change database definitions Update statistics on data
    34. 34. Can the right people access the data? Personnel team Query & update data at individual or regional level PERSONNEL database DBA Backup/ restore data Reorganise data Change database definitions Update statistics on data Chief executive Employee statistics
    35. 35. Can the right people access the data? Personnel team Query & update data at individual or regional level PERSONNEL database DBA Backup/ restore data Reorganise data Change database definitions Update statistics on data Chief executive Employee statistics Staff member Their own data
    36. 36. Can the right people use the database? <ul><li>Different people, different information needs. </li></ul><ul><li>Sensitive data – salary, health, discipline… </li></ul><ul><li>Solution </li></ul><ul><ul><li>VIEWS </li></ul></ul><ul><ul><li>Transaction Management </li></ul></ul>
    37. 37. If disaster strikes, can the data be recovered? <ul><li>Robust backup & recovery strategies for: </li></ul><ul><ul><li>Hardware failure </li></ul></ul><ul><ul><li>Software failure </li></ul></ul>
    38. 39. Part2: Recap of Production Database issues <ul><li>Database must perform to acceptable level. </li></ul><ul><li>Only the right people should have access to any data item. </li></ul><ul><li>No matter what, the data must be recoverable. </li></ul>
    39. 40. Questions?

    ×