Week11.ppt
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Week11.ppt

on

  • 598 views

 

Statistics

Views

Total Views
598
Views on SlideShare
598
Embed Views
0

Actions

Likes
1
Downloads
6
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

Week11.ppt Presentation Transcript

  • 1. Improving Database Performance
    • So far, we have looked at many aspects of designing, creating, populating and querying a database. We have (briefly) explored ‘optimisation’ which is used to ensure that query execution time is minimised
    • In this lecture we are going to look at some techniques which are used to improve performance and availability
    • WHY ?
    • Because databases are required to be available, in many installations and applications, 24 hours a day, 7 days a week, 52 weeks every year - think of the ‘user’ demands in e-business
  • 2. Improving Database Performance
    • There are many ‘solutions’ - including
    • parallel processors
    • faster processors
    • higher speed communications
    • more memory
    • faster disks
    • more disk units on line
    • higher capacity disks
    • any others ?
  • 3. Improving Database Performance
    • We are going to look at a technique called ‘clustering’ - an architecture for improving ‘power’ and availability
    • What are the ‘dangers’ to non-stop availability
    • Try these :-
          • System outages (planned)
            • Maintenance, tuning
          • System outages (unplanned)
            • hardware failure, bugs, virus attacks
  • 4. Improving Database Performance
    • E-business is not the only focus
    • Businesses are tending to be ‘global organisations’ - remember one of the early lectures ?
    • So what is one of the solutions’ ?
    • In a single word - clustering
    • Clustering is based on the premise that multiple processors can provide better, faster and more reliable processing than a single computer
  • 5. Improving Database Performance
    • However, as in most ‘simple’ solutions in Information Technology, the problem is in the details
    • How can clustering be achieved ?
    • Which technologies and architectures off the best approach to clustering ?
      • and, what is the measure, or metric, of ‘best’ ?
  • 6. Improving Database Performance
    • What are some of the advantages of clustering ?
      • Improved availability of services
      • Scalability
    • Clustering involves multiple and independent computing systems which work together as one
    • When one of the independent systems fails, the cluster software can distribute work from the failing system to the remaining systems in the cluster
  • 7. Improving Database Performance
    • ‘Users’ normally would not notice the difference
      • They interact with a cluster as if it were a single server - and importantly the resources they require will still be available
    • Clustering can provide high levels of availability
  • 8. Improving Database Performance
    • What about ‘scalability’ ?
    • Loads will (sometimes) exceed the capabilities which make up the cluster.
    • Additional facilities can be incrementally added to increase
    • the cluster’s computing power and ensure processing requirements are met
    • As transaction and processing loads become established, the cluster (or parts of it) can be increased in size or number
  • 9. Improving Database Performance
    • Clustering is NOT a ‘new’ concept
    • A company named DEC introduced them for VMS systems in the early 1980’s - about 20 years ago
    • Which firms offer clustering packages now ?
    • IBM, Microsoft and Sun Microsystems
  • 10. Improving Database Performance
    • What are the different types of Clustering ?
    • There are 2 architectures;
      • Shared nothing and
      • Shared disk
      • In a shared nothing architecture, each system has its own private memory and one or more disks
      • And each server in the cluster has its own independent subset of the data it can work on independently without meeting resource contention from other servers
  • 11. Improving Database Performance
    • This might explain better:-
    • CPU 1 CPU 2 CPU 3
    • Memory 1 Memory 2 Memory ..n
    • A Shared Nothing Architecture
    Interconnection network
  • 12. Improving Database Performance
    • As you saw on the previous overhead, a shared nothing environment, each system has its own ‘private memory’ and one or more disks
    • And each server in the cluster has its own independent subset of the data it can work on without meeting resource conflicts from other servers
    • The clustered processors communicate by passing messages through a network which interconnects the computers
  • 13. Improving Database Performance
    • Client requests are automatically directed to the system which owns the particular resource
    • Only one of the clustered systems can ‘own’ and access a particular resource at a time.
    • When a failure occurs, resource ownership can be dynamically transferred to another system in the cluster
    • Theoretically, a shared nothing multiprocessor could scale up to thousands of processors - the processors don’t interfere with one another - no resources are shared
  • 14. Improving Database Performance
    • CPU 1 CPU 2 CPU …n
    • Memory 1 Memory 2 Memory ..n
    • A Shared All Environment
    Interconnecting Network
  • 15. Improving Database Performance
    • In a ‘shared all’ environment, you noticed that all of the connected systems shared the same disk devices
    • Each processor has its own private memory, but all the processors can directly access all the disks
    • In addition, each server has access to all the data
  • 16. Improving Database Performance
    • In this arrangement, ‘shared all’ clustering doesn’t scale as effectively as shared-nothing clustering for small machines. All the nodes have access to the same data, so a controlling facility must be used to direct processing to make sure that all nodes have a consistent view of the data as it changes
    • Attempts by more than one nodes to update the same data need to be prohibited. This can cause performance and scalability problems
    • (similar to the concurrency aspect)
  • 17. Improving Database Performance
    • Shared-all architectures are well suited to the large scale processing found in main frame environments
    • Main frames are large processors capable of high work loads. The number of clustered PC’s and midrange processors, even with the newer, faster processors, which would equal the computing power from a few clustered mainframes, would be high - about 250 nodes.
  • 18. Improving Database Performance
    • This chart might help :
    • Shared Disk Shared Nothing Quick adaptability to High possibility of
    • changing workloads simpler, cheaper hardware
    • High availability Almost unlimited scalability
    • Data need not be Data may need to be partitioned partitioned across the cluster
  • 19. Improving Database Performance
    • There is another technique - InfiniBand architecture which can reduce bottlenecks in the Input/Output level, and which has a further appeal of reducing the cabling, connector and administrative overheads of the database infrastructure
    • It is an ‘intelligent’ agent - meaning software.
    • Its main attraction is that it can change the way information is exchanged in applications. It removes unnecessary overheads from a system
  • 20. Improving Database Performance
    • Peripheral Interconnect (PCI) remains a bus-based system - this allows the transfer of data between 2 (yes, 2!) of the members at a time
    • Many PCI buses cause bottlenecks in the bridge to the memory subsystems. Newer versions of PCI allowed only a minor improvement - only 2 64 bit 66MKz adapters on the bus
    • A bus allows only a small number of devices to be interconnected, is limited in its electrical paths, and cannot adapt to meet high availability demands
  • 21. Improving Database Performance
    • A newer device, called a fabric, can scale to thousands of devices with parallel communications between each node
    • A group formed in 1999 (Intel/Microsoft, IBM, Compaq and Sun Future IO) to form the InfiniBand Trade Association
    • Their objective was to develop and ensure one standard for communication interconnects and system I/O.
    • One of their early findings was that replacing a bus architecture by fabric was not the full story - or solution
  • 22. Improving Database Performance
    • Their early solution needed to be synchronised with software changes. If not, a very high speed network could be developed, but actual application demands would not be met
    • InfinBand is comprised of
    • 1 Host Channel Adapters (HCA)
    • 2. Target Channel Adapters (TCA)
    • 3. Switches
    • 4. Routers
    • 1 and 2 define end nodes in the fabric, 3 and 4 are interconnecting devices
  • 23. Improving Database Performance
    • The HCA (host channel adapter) manages a connection a connection and interfaces with a fabric
    • The TCA (target channel adapter) delivers required data such as a disk interface which replaces the existing SCSI interface
    • An InfiniBand switch links HCAs and TCAs into a network
    • The router allows the interface to other networks AND the translation of legacy components and networks. It can be used for MAN and WAN interfaces.
  • 24. Improving Database Performance
    • InfiniBand link speeds are identified in multiples of the base 1x - (0.5 Gb full duplex link - 0.25Gb in each direction)
    • Other defined sizes are $x (2 Gb full duplex) and 12x (6Gb full duplex).
    • Just for size :
    • A fast SCSi adapter could accommodate a throughput rate of 160Mb per second
    • A single InfinBand adapter 4x can deliver between 300 and 500 Mb per second
  • 25. Improving Database Performance End Nodes Routers Switch
  • 26. Improving Database Performance
    • So far we have looked at improving database performance by
    • 1. The use of ‘shared-all’ or ‘shared-nothing’ architectures
    • 2. Implementing an InfiniBand communications interface and network facility
  • 27. Improving Database Performance
    • Now we are going to look at another option
    • It’s known as the ‘Federated Database’ environment
    • So, what is a ‘Federated Database’ ?
    • Try this: It is a collection of data stored on multiple autonomous computing systems connected to a network.
    • The user or users is presented with what appears to be one integrated database
  • 28. Improving Database Performance
    • A federated database presents ‘views’ to users which look exactly the same as views of data from a centralised database
    • This is very similar to the use of the Internet where many sites have multiple sources - but the user doesn’t see them
    • In a federated database approach, each data resource is defined (as you have done) by means of table schemas, and the user is able to access and manipulate data
  • 29. Improving Database Performance
    • The ‘queries’ actually access data from a number of databases at a number of locations
    • One of the interesting aspects of a federated database is that the individual databases may consist of any DBMS (IBM, Oracle, SQL Server, possibly MS Access) and run on any operating system (Unix, VMS, MS-XP) and on different hardware ( Hewlett-Packhard servers, Unisys, IBM, Sun Microsystems …..
  • 30. Improving Database Performance
    • However, there a some reservations :
    • Acceptable performance requires the inclusion of a smart optimiser using the cost-based technique which has intelligence about both the distribution (perhaps a global data dictionary) and also the different hardware and DBMS at each accessed site.
  • 31. Improving Database Performance
    • Another attractive aspect of the federated arrangement is that additional database servers can be added to the federation at any time - and servers can also be deleted.
    • As a general comment, any multisource database can be implemented in either a centralised or federated architecture
    • In the next few overheads, there are some comments on this
  • 32. Improving Database Performance
    • The centralised approach has some disadvantages, the major one being that investment is large, and the return on investment may take many months, or years
    • The process includes these steps:
    • 1. Concept development and data model for collecting data needed to support business decisions and processes
    • 2. Identification of useful data sources (accurate, timely, comprehensive, available …)
  • 33. Improving Database Performance
    • 3. Obtain a database server platform to support the database (and probably lead to data warehousing).
    • 4. Capture data, or extract data, from the source(s)
    • 5. Clean, format, and transform data to the quality and formats required
    • 6. Design an integrated database to hold this data
    • 7. Load the database (and review quality)
  • 34. Improving Database Performance
    • 8. Develop systems to ensure that content is current (probably transaction systems)
    • From this point, that database becomes ‘usable’
    • So, what is different with the Federated Database approach
    • 1. Firstly, the economics are different - the investment in the large, high speed processor is not necessary
    • 2. Data is not centralised - it remains with and on the systems used to maintain it
  • 35. Improving Database Performance
    • 3. The database server can be a mid-range, or several servers.
    • 4. Another aspect is that it is probably most unlikely to run a query which regularly needs access to all of the individual databases - but with the centralised approach all of the data needs to be ‘central’.
    • 5. Local database support local queries - that’s probably why the local databases were introduced.
  • 36. Improving Database Performance
    • The Internet offers the capability of large federations of content servers
    • Distributed application architectures built around Web servers and many co-operating databases are (slowly) becoming common both
      • within and
      • between
      • enterprises (companies).
    • Users are normally unaware of the interfacing and supporting software necessary for federated databases to be accessible
  • 37. Improving Database Performance
    • Finally, there is another aspect which is used to improve the availability and performance of a database
    • This occurs at the ‘configuration stage’ which is when the database and its requirements are being ‘created’
    • - quite different from the ‘create table’ which you have used
    • It is the responsibility of the System Administration and Database Management (and of course Senior / Executive Management)
  • 38. Improving Database Performance
    • Physical Layouts
    • The physical layout very much influences
      • How much data a database can hold
      • The number of concurrent and database users
      • How many concurrent processes can execute
      • Recovery capability
      • Performance (response time)
      • Nature of Database Administration
      • Cost
      • Expansion
  • 39. Improving Database Performance Oracle Architecture
    • Oracle8i and 9i are object-relational database management systems. They contain the capabilities of relational and object-oriented database systems
    • They utilise database servers for many types of business applications including
      • On Line Transaction Processing (OLTP)
      • Decision Support Systems
      • Data Warehousing
  • 40. Improving Database Performance Oracle Architecture
    • In perspective, Oracle is NOT a ‘high end’ application DBMS
    • A high end system has one or more of these characteristics:
      • Management of a very large database (VLDB) - probably hundreds of gigabytes or terabytes
      • Provides access to many concurrent users - in the thousands, or tens of thousands
      • Gives a guarantee of constant database availability for mission critical applications - 24 hours a day, 7 days a week.
  • 41. Improving Database Performance Oracle Architecture
    • High end applications environments are not normally controlled by Relational Database Management Systems
    • High end database environments are controlled by mainframe computers and non-relational DBMSs.
    • Current RDBMSs cannot manage very large amounts of data, or perform well under demanding transaction loads.
  • 42. Improving Database Performance Oracle Architecture
    • There are some guidelines for designing a database with files distributed so that optimum performance, from a specific configuration, can be achieved
    • The primary aspect which needs to be clearly understood is the nature of the database
      • Is it transaction oriented ?
      • Is it read-intensive ?
  • 43. Improving Database Performance
    • The key items which need to be understood are
      • Identifying Input/Output contention among datafiles
      • Identifying Input/Output bottlenecks among all database files
      • Identifying concurrent Input/Output among background processes
      • Defining the security and performance goals for the database
      • Defining the system hardware and mirroring architecture
      • Identifying disks which can be dedicated to the database
  • 44. Improving Database Performance
    • Let’s look at tablespaces :
    • These ones will be present in some combination
    • System Data dictionary
    • Data Standard-operation tables
    • Data_2 Static tables used during standard operation
    • Indexes Indexes for the standard-operation tables
    • Indexes_2 Indexes for the static tables
    • RBS Standard-operation RollBack Segments
    • RBS_2 Special RollBack segments used for data loads
    • Temp Standard operation temporary segments
    • Temp_user Temporary segments created by a temporary user
  • 45. Improving Database Performance
    • Tools RDBMS tools tables
    • Tools_1 Indexes for the RDBMS tools tables
    • Users User objects in development tables
    • Agg_data Aggregation data and materialised views
    • Partitions Partitions of a table or index segments; create multiple tablespaces for them
    • Temp_Work Temporary tables used during data load processing
  • 46. Improving Database Performance
    • (A materialised view stores replicated data based on an underlying query. A materialised view stores data which is replicated from within the current database).
    • A Snapshot stores data from a remote database.
    • The system optimiser may choose to use a materialised view instead of a query against a larger table if the materialised view will return the same data and thus improve response time. A materialised view does however incur an overhead of additional space usage, and maintenance)
  • 47. Improving Database Performance
    • Each of the tablespaces will require a separate datafile
    • Monitoring of I/O performance among datafiles is done after the database has been created, and the DBA must estimate the I/O load for each datafile (based on what information ?)
    • The physical layout planning is commenced by estimating the relative I/O among the datafiles, with the most active tablespace given a weight of 100.
    • Estimate the I/O from the other datafiles relative to the most active datafile
  • 48. Improving Database Performance
    • Assign a weight of 35 for the System tablespace files and the index tablespaces a value of 1/3 or their data tablespaces
    • Rdb’s may go as high as 70 (depending on the database activity) - between 30 and50 is ‘normal’
    • In production, Temp will be used by large sorts
    • Tools will be used rarely in production - as will the Tools_2 tablespace
  • 49. Improving Database Performance
    • So, what do we have ? - Something like this -
    • Tablespace Weight % of Total
    • Data 100 45
    • Rbs 40 18
    • System 35 16
    • Indexes 33 15
    • Temp 5 2
    • Data_2 4 2
    • Indexes_2 2 1
    • Tools 1 1
    • (220)
  • 50. Improving Database Performance
    • 94% of the Input/Output is associated with the top four tablespaces
    • This indicates then that in order to properly the datafile activity, 5 disks would be needed, AND that NO other database files should be put on the disks which are accommodating the top 4 tablespaces
    • There are some rules which apply :
    • 1 . Data tablespaces should be stored separately from their Index tablespaces
    • 2 . RBS tablespaces should be stored separately from their Index tablespaces
  • 51. Improving Database Performance
    • and 3 . The System tablespace should be stored separately from the other tablespaces in the database
    • In my example, there is only 1 Data tablespace. In production databases there will probably be many Data tablespaces (which will happen if Partitions are used).
    • If/when this occurs, the weightings of each of the Data tablespaces will need to be made (but for my efforts, 1 Data tablespace will be used).
  • 52. Improving Database Performance
    • As you have probably guessed, there are other tablespaces which require to be considered - many used by the many and various ‘processes’ of Oracle
    • One of these considerations is the on-line redo log files (you remember these and their purpose ?)
    • They store the records of each transaction. Each database must have at least 2 online redo log files available to it - the database will write to one log in sequential mode until the redo log file is filled, then it will start writing to the second redo log file.
  • 53. Improving Database Performance
    • Redo log files (cont’d)
    • The Online Redo Log files maintain data about current transactions and they cannot be recovered from a backup unless the database is/was shut down prior to backup - this is a requirement of the ‘Offline Backup’ procedure (if we have time we will look at this)
    • On line redo log files need to be ‘mirrored’
    • A method of doing this is to employ redo log groups - which dynamically maintain multiple sets of the online redo logs
    • The operating system is also a good ally for mirroring files
  • 54. Improving Database Performance
    • Redo log files should be placed away from datafiles because of the performance implications, and this means knowing how the 2 types of files are used
    • Every transaction (unless it is tagged with the nologging parameter) is recorded in the redo log files
    • The entries are written by the LogWriter (LGWR) process
    • The data in the transaction is concurrently written to a number of tablespaces(the RBS rollback segments and the Data tablespace come to mind) via the DataBase Writer (DBWR) and this raises possible contention issues if a datafile is located on the same disk as a redo log file
  • 55. Improving Database Performance
    • Redo log files are written sequentially
    • Datafiles are written in ‘random’ order - it is a good move to have these 2 different demands separated
    • If a datafile must be stored on the same disk as a redo log files, then it should not belong to the System tablespace, the RBS tablespace, or a very active Data or Index tablespace
    • So what about Control Files ?
    • There is much less traffic here, and they can be internally mirrored. (config.ora or init.orafile). The database will maintain the control files as identical copies of each other.
    • There should be 3 copies, across 3 disks
  • 56. Improving Database Performance
    • The LGWR background process writes to the online redo files in a cyclical manner
    • When the lst redo file is full, it directs writing to the 2nd file ….
    • When the ‘last’ file is full, LWGR starts overwriting the contents of the 1st file .. and so on
    • When ARCHIVELOG mode is used, the contents of the ‘about to be overwritten file’ are written to a redo file on a disk device
  • 57. Improving Database Performance
    • There will be contention on the online redo log as LGWR will be attempting to write to one redo log file while the Archiver (ARCH) will be trying to read another.
    • The solution is to distribute the redo log files across multiple disks
    • The archived redo log files are high I/O and therefore should NOT be on the same device as System, Rbs, Data, or Indexes tablespaces
    • Neither should they be stored on the same device as any of the online redo log files.
  • 58. Improving Database Performance
    • The database will stall if there is not enough disk space, and the archived files should directed to a disk which contains small and preferably static files
    • Concurrent I/O
    • A commendable goal, and one which needs careful planning to achieve.
    • Placing two random access files which are never accessed at the same time will quite happily avoid contention for I/O capability
  • 59. Improving Database Performance
    • What we have just covered is known as
    • 1. Concurrent I/O - when concurrent processes are being performed against the same device (disk)
    • This is overcome by isolating data tables from their Indexes for instance
    • 2. Interference - when sequential writing is interfered by reads or writes to other files on the same disk
  • 60. Improving Database Performance
    • At the risk of labouring this a bit,
    • The 3 background processes to watch are
    • 1. DBWR, which writes in a random manner
    • 2. LGWR, which writes sequentially
    • 3. ARCH, which reads and writes sequentially
    • LGWR and ARCH write to 1 file at a time, but DBWR may be attempting to write to multiple files at once - (can you think of an example ?)
    • Multiple DBWR processes for each instance or multiple I/O slaves for each DBWR is a solution
  • 61. Improving Database Performance
    • What are the disk layout goals ?
    • Are they (1) recoverability or (2) performance
    • Recoverability must address all processes which impact disks (storage area for archived redo logs and for Export dump files - (which so far we haven’t mentioned) come to mind).
    • Performance calls for file I/O performance and relative speeds of the disk drives
  • 62. Improving Database Performance
    • What are some recoverability issues ?
    • All critical database files should be placed on mirrored drives, and the database run in ARCHIVELOG mode
    • The online red files must also be mirrored (Operating system or mirrored redo log groups)
    • Recoverability issues involve a few disks
    • and this is where we start to look at hardware specification
  • 63. Improving Database Performance
    • Mirroring architecture leads to specifying
      • the number of disks required
      • the models of disks (capacity and speed)
      • the strategy
      • If the hardware system if heterogeneous, the faster drives should be dedicated to Oracle database files
      • RAID systems should be carefully analysed as to their capability and the optimum benefit sought - RAID-1 , RAID- 3 and RAID-5 have different processes relating to parity
  • 64. Improving Database Performance
    • The disks chosen for mirroring architecture must be dedicated to the database
    • This guarantees that non-database load on these disks will not interfere with database processes
  • 65. Improving Database Performance
    • Goals for disk layout :
      • The database must be recoverable
      • The online redo log files must be mirrored via the system or the database
      • The database file I/O weights must be estimated
      • Contention between DBWR, LGWR and ARCH must be minimised
      • Contention between disks for DBWR must be minimised
      • The performance goals must be defined
      • The disk hardware options must be known
      • The disk mirroring architecture must be known
      • Disks must be dedicated to the database
  • 66. Improving Database Performance
    • So where does that leave us ?
    • We’re going to look at ‘solutions’ from Optimal to Practical
    • and we’ll assume that :
    • the disks are dedicated to the database
    • the online redo log files are being mirrored by the Operating System
    • the disks are of identical size
    • the disks have identical performance characteristics
    • (obviously the best case scenario !)
  • 67. Improving Database Performance
    • So, with that optimistic outlook let’s proceed
    • Case 1 - The Optimum Physical Layout
    • Disk No Contents Disk No. Contents
    • 1 Oracle Software 12 Control file 2
    • 2 SYSTEM tablespace 13 Control file 3
    • 3 RBS tablespace 14 Application software
    • 4 DATA tablespace 15 RBS_2
    • 5 INDEXES tablespace 16 DATA_2
    • 6 TEMP tablespace 17 INDEXES_2
    • 7 TOOLS tablespace 18 TEMP_ USER
    • 8 OnLine Redo Log 1 19 TOOLS_1
    • 9 OnLine redo log 2 20 USERS
    • 10 OnLine redo Log 3 21 Archived redo dest. disk
    • 11 Control file 1 22 Archived dump file
  • 68. Hardware Configurations
    • The 22 disk solution is an optimal solution.
    • It may not be feasible for a number of reasons, including hardware costs
    • In the following overheads there will be efforts to reduce the number of disks, commensurate with preserving performance
  • 69. Hardware Configurations
    • This leads to - 17 disk configuration
    • Disk Contents Disk Contents
    • 1 Oracle software 11 Application software
    • 2 SYSTEM tablespace 12 RBS_2
    • 3 RBS tablespace 13 DATA_2
    • 4 DATA tablespace 14 INDEXES_2
    • 5 INDEXES tablespace 15 TEMP_USER
    • 6 TEMP tablespace 16 Archived redo log
    • 7 TOOLS tablespace destination disk
    • 8 Online Redo log 1, Control file 1 17 Export dump
    • 9 Online Redo log 2, Control file 2 destination disk
    • 10 Online Redo log 3, Control file 3
  • 70. Hardware Configurations
    • The Control Files are candidates for placement onto the three redo log disks. The altered arrangement reflects this.
    • The Control files will interfere with the online redo logfiles but only at log switch points and during recovery
  • 71. Hardware Configurations
    • The TOOLS_1 tablespace will be merged with the TOOLS tablespace
    • In a production environment, users will not have resource privileges, and the USERS tablespace can be ignored
    • However, what will be the case if users require development and test access ?
    • Create another database ? (test ?)
  • 72. Hardware Configurations
    • The RBS and RBS_2 tablespaces have special rollback segments used during data loading.
    • Data loads should not occur during production usage, and so if the 17 disk option is not practical, we can look at combining RBS and RBS_2 - there should be no contention
    • TEMP and TEMP_USER can be placed on the same disk
    • The TEMP tablespace weighting (5 in the previous table) can vary. It should be possible to store these 2 tablespaces on the same disk.
    • TEMP_USER is dedicated to a specific user - (such as Oracle Financials, and these have temporary segments requirements which are greater than the system’s users)
  • 73. Hardware Configurations
    • The revised solution is now
    • Disk Contents Disk Content
    • 1 Oracle software 11 Application software
    • 2 SYSTEM tablespace 12 DATA_2
    • 3 RBS, RBS_2 tablespace 13 INDEXES_2
    • 4 DATA tablespace 14 Archived Redo Log
    • 5 INDEXES tablespaces destination disk
    • 6 TEMP, TEMP_USER tablespace 15 Export dump file
    • 7 TOOLS tablespace destination disk
    • 8 Online Redo Log 1, Control file 1
    • 9 Online Redo Log 2, Control file 2 15 disks
    • 10 Online Redo Log 3, Control file 3
  • 74. Hardware Configurations
    • What if there aren’t 15 disks ? -->> Move to attempt 3
    • Here the online Redo Logs will be placed onto the same disk. Where there are ARCHIVELOG backups, this will cause concurrent I/O and interference contention between LGWR and ARCH on that disk
    • What we can deduce from this, is that the combination about to be proposed is NOT appropriate for a high transaction system or systems running in ARCHIVELOG mode
    • (why is this so - Prof. Julius Sumner Miller ?)
  • 75. Hardware Configurations
    • The ‘new’ solution -
    • Disk Contents
    • 1 Oracle software
    • 2 SYSTEM tablespace, Control file 1
    • 3 RBS, RBS_2 tablespaces, Control file 2
    • 4 DATA tablespace, Control file 3
    • 5 INDEXES tablespaces
    • 6 TEMP, TEMP_USER tablespaces 12 disks
    • 7 TOOLS, INDEXES_2 tablespaces
    • 8 OnLine Redo Logs 1, 2 and 3
    • 9 Application software
    • 10 DATA_2
    • 11 Archived redo log destination disk
    • 12 Export dump file destination disk
  • 76. Hardware Configurations
    • Notice that the Control Files have been moved to Disks 2, 3 and 4
    • The Control Files are not I/O demanding, and can safely coexist with SYSTEM, RBS and DATA
    • What we have done so far is to ‘move’ the high numbered disks to the ‘low’ numbered disks - these are the most critical in the database.
    • The next attempt to ‘rationalise’ the disk arrangement is to look carefully at the high numbered disks.
  • 77. Hardware Configurations
      • DATA_2 can be combined with with the TEMP tablespaces (this disk has 4% of the I/O load).
      • This should be safe as the static tables (which ones are those ?) are not as likely to have group operations performed on them as the ones in the DATA tablespace
      • The Export dump files have been moved to the Online Redo disk (the Redo log files are about 100Mb and don’t increase in size -(is that correct ?) Exporting causes minor transaction activity.
      • The other is the combination of the application software with the archived redo log file destination area. This leaves ARCH space to write log files, and avoids conflicts with DBWR
  • 78. Hardware Configurations
    • Disk Content
    • 1 Oracle software
    • 2 SYSTEM tablespace, Control file 1
    • 3 RBS tablespace, RBS_2 tablespace, Control file 2
    • 4 DATA tablespace, Control file 3
    • 5 INDEXES tablespace 9 disks
    • 6 TEMP, TEMP_USER, DATA_2 tablespaces
    • 7 TOOLS, INDEXES_2 tablespaces
    • 8 Online Redo logs 1, 2 and 3, Export dump file
    • 9 Application software, Archived Redo log destination disk
  • 79. Hardware Configurations
    • Can the number of required disks be further reduced ?
    • Remember that the performance characteristics will deteriorate
    • It’s now important to look closely at the weights set during the I/O estimation process.
  • 80. Hardware Configurations
    • Estimated Weightings for the previous (9 disk) solution are
    • Disk Weight Contents
    • 1 Oracle software
    • 2 35 SYSTEM tablespace, Control file 1
    • 3 40 RBS, RBS_2 tablespace, Control file 2
    • 4 100 DATA tablespace, Control file 3
    • 5 33 INDEXES tablespaces
    • 6 9 TEMP, TEMP_USER, DATA_2 tablespace
    • 7 3 TOOLS, INDESES_2 tablespaces
    • 8 40+ Online Redo logs 1,2 and 3, Export dump file destination disk
    • 9 40+ Application software, archived redo log destination disk
  • 81. Hardware Configurations
    • A further compromise distribution could be
    • Disk Weight Contents
    • 1 Oracle software
    • 2 38 SYSTEM, TOOLS, INDEXES_2 tablespaces , Control file1
    • 3 40 RBS, RBS_2 tablespaces , Control file 2
    • 4 100 DATA tablespace , Control file 3
    • 5 42 INDEXES, TEMP, TEMP_USER, DATA_2 tablespaces
    • 6 40+ Online redo logs 1,2 and 3, Export dump file destination disk
    • 7 40+ Application software, Archived redo log destination disk
  • 82. Hardware Configurations
    • A few thoughts for a small database system - 3 disks
    • 1. Suitable for an OLTP application. Assumes that the transactions a small in size, large in number and variety, and randomly scattered among the available tables.
    • The application should be as index intensive as possible, and the full table scans must be kept to the minimum possible
  • 83. Hardware Configurations
    • 2. Isolate the SYSTEM tablespace. This stores the data dictionary - which is accessed for every query and is accessed many times for every query
    • In a ‘typical case’, query execution requires
      • the column names to be checked in CODES_TABLE table
      • the user’s privilege of access to the CODES_TABLE table
      • the user’s privilege to access the Code column of the CODES_TABLE table
      • the user’s role definition(s)
      • the indexes defined on the CODES_TABLE table
      • the columns of the columns defined on the CODES_TABLE table
  • 84. Hardware Configurations
    • 3. Isolate the INDEXES tablespace. This probably accounts for 35 to 40% of the I/O
    • 4. Separate the rollback segments and DATA tablespaces
    • There is a point to watch here - with 3 disks there are 4 tablespaces - SYSTEM, INDEXES, DATA and RBS.
    • The placement of RBS is determined by the volume of transactions. If high, RBS and DATA should be kept apart.
    • If low, RBS and DATA should work together without causing contention
  • 85. Hardware Configurations
    • The 3 disk layout would be one of these :
    • Disk 1: SYSTEM tablespace, control file, redo log
    • Disk 2 : INDEXES tablespace, control file, redo log, RBS tablespace
    • Disk 3 : DATA tablespace, control file, redo log
    • OR
    • Disk 1 : SYSTEM tablespace, control file, redo log
    • Disk 2 : INDEXES tablespace, control file, redo log
    • Disk 3 : DATA tablespace, control file, redo log, RBS tablespace
  • 86. Hardware Configurations
    • Summary :
    • Database Type Tablespaces
    • Small development SYSTEM
    • database DATA
    • INDEXES
    • RBS
    • TEMP
    • USERS
    • TOOLS
  • 87. Hardware Configurations
    • Summary :
    • Database Type Tablespaces
    • Production OLTP SYSTEM
    • database DATA
    • DATA_2
    • INDEXES
    • INDEXES_2
    • RBS
    • RBS_2
    • TEMP
    • TEMP_USER
    • TOOLS
  • 88. Hardware Configurations
    • Summary :
    • Database Type Tablespaces Tablespaces
    • Production OLTP SYSTEM TEMP
    • with historical DATA TEMP_USER
    • data DATA_2 TOOLS
    • DATA_ARCHIVE
    • INDEXES
    • INDEXES_2
    • INDEXES_ARCHIVE
    • RBS
    • RBS_2