• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Relational database ..
 

Relational database ..

on

  • 471 views

 

Statistics

Views

Total Views
471
Views on SlideShare
471
Embed Views
0

Actions

Likes
0
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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 .. Relational database .. Presentation Transcript

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