WO1999027451A1 - Method for analyzing disk performance of large database systems - Google Patents
Method for analyzing disk performance of large database systems Download PDFInfo
- Publication number
- WO1999027451A1 WO1999027451A1 PCT/US1998/024530 US9824530W WO9927451A1 WO 1999027451 A1 WO1999027451 A1 WO 1999027451A1 US 9824530 W US9824530 W US 9824530W WO 9927451 A1 WO9927451 A1 WO 9927451A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- data
- samples
- database
- disk
- stored
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3466—Performance evaluation by tracing or monitoring
- G06F11/3485—Performance evaluation by tracing or monitoring for I/O devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3466—Performance evaluation by tracing or monitoring
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99932—Access augmentation or optimizing
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
- Y10S707/99934—Query formulation, input preparation, or translation
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
Definitions
- This invention is related to database management systems and in particular to systems for optimizing placement of database objects in large database systems having database files stored over multiple disk drives.
- a parallel architecture is superior to a traditional single processor because the workload is divided into multiple simultaneous processes for faster execution. The same technique is used to speed access to disk storage. When additional capacity or performance is needed, the architecture is scaled by adding additional resources to those already in place, allowing for more parallel processes to occur simultaneously.
- Disk caching is of limited use as a solution to this problem. Caching provides performance advantages where access to stored data can be predicted. In a typical database application, a single transaction may require 50 to 100 disk accesses within a few seconds involving a couple of dozen database objects, such as tables, indexes, logs, etc. These accesses typically retrieve relatively small amounts of data randomly distributed through the database structure. In these types of applications, disk caching provides little or no improvement in the speed of access. Accessing such data serially takes too long for many database applications which require near instantaneous response to a human operator.
- VLDBs have addressed this problem by storing data on multiple drives and by distributing the data across the drives in a manner that reduces the probability that a single drive will need to be repeatedly accessed to retrieve a database object. For example a 23 GB database stored on a single 23 GB drive would be limited to 50 to 100 accesses per second. A typical on-line transaction processing (OLTP) operation would require this performance just to support one operator.
- OTP on-line transaction processing
- the present invention provides a tool with which a DBA can analyze a VLDB at all levels of data storage, both logical and physical, to determine exactly what is causing hotspots.
- all the significant aspects of storing the database data are monitored. Parameters indicating the activity and performance level of each of the levels of storage are taken at selected intervals and stored. These parameters are already known to the system or are based on readily-available system data, and the sampling process has negligible effect on the database system performance.
- the data is continuously sampled at the selected intervals so that a profile of the system performance over time is accumulated.
- An analysis tool allows a DBA to select a time window during which the database performance is be assessed.
- the time window can be continuous, such as May 1-5, or discontinuous such as 9:00 to 10:00 AM on Monday mornings, so that periodic system problems can be isolated for analysis.
- the analysis tool has a map of the logical and physical arrangement of the database being monitored and allows a DBA to move from level to level of both logical and physical structures involved in storing the data so that the exact source of any disk overloads can be determined.
- the analysis tool can be used both to diagnose detected performance problems and to check the database periodically to detect potential hotspots before they cause performance problems. Additionally, by using the analysis tool to identify underutilized storage resources, or "cold spots," a DBA can make informed decisions when data placements are changed.
- Figs. 1 through 3 are diagrams showing placement of data in stripes and how such stripes can interfere to cause hot spots;
- Fig. 4 is a block diagram showing the components of a database system and their interaction with the present invention.
- Fig. 5 shows the main window of the analysis tool in the present invention and illustrates the various capabilities thereof;
- Fig. 6 is a representative display showing stripe set activity for a database;
- Figs. 7A and 7B are a flow diagram showing how selected sample data is processed for display
- Fig. 8 shows how the invention would be used to display disk data activity for one of the stripe sets of Fig . 6 ;
- Fig. 9 show a display of actual sample data for one of the stripe sets in Fig. 6;
- Fig. 10 shows a display of plex activity for the busiest disk in Fig. 8 ;
- Fig. 11 shows a display of sample data for the busiest plex in Fig. 10.
- Fig. 12 is a flow diagram of a procedure that can be used with the present invention to make recommendations for improving placement in a VLDB .
- Oracle is a relational database management system (RDBMS) well known to those in the art. It should be appreciated, however, that the present invention may be used with other database systems, and applying the teachings of the present invention to such other databases can be easily accomplished by those skilled in the art after reading the description of the present invention contained herein.
- RDBMS relational database management system
- RDBMS architecture requires the storage of multiple data types which will be referred to herein as database objects.
- database objects For example, Oracle stores user data in tables that are accessed through reference to indexes . Related tables, indexes, and other objects are typically grouped in a tablespace. Transactions are logged in a redo log, so that in the event of a failure the database can be recovered. A number of other types of objects that play a role in maintaining the integrity of the database may also be stored as part of a transaction.
- An RDBMS typically stores database objects by sending requests to a file management system to store the objects as a database file. When the database object is needed, the RDBMS requests that a particular record or block from a database file be retrieved. A single query from a user may require access to many database files. It is not uncommon for a single user entry to cause 50 to 100 disk accesses to occur, involving a couple of dozen objects (tables, indexes, logs, etc.), solely for the purpose of storing a transaction and
- placement The process of choosing an arrangement for the various objects of a database and placing or distributing these objects across a number of disks is called placement.
- the objective of a DBA in doing placement of data is to achieve three goals.
- First, the access to the database is "parallelized” so that access time performance is kept within predetermined specifications by allowing as many accesses to occur simultaneously as possible.
- Second, the access to the data should be "load-leveled", so that no one disk is significantly busier than other disks in the array, otherwise, processes that access a busy disk will be slowed.
- Third, the data must be placed so that access to different objects do not conflict or "pile up,” which also will slow down performance. "Optimal placement,” is achieved when all three of these objectives are perfectly met and is the goal of DBAs in performing placement.
- Fig. 1 is a simple example of how a database might be distributed across a number of disks.
- the elements of a 5 GB database are stored on a moderately sized array of 24 individual disks, represented by ovals 12.
- the various objects making up the simplified database of Fig. 1 include three tables two indexes and a temp file for temporary storage.
- the different objects of the database are all striped over a plurality of disks.
- a logical storage area that is spread across a plurality of disks is sometimes called a plex, as discussed in more detail below.
- a group of disks containing one or more intersecting plexes will be referred to as a stripe set.
- a stripe set includes a striped plex and all other plexes that intersect it or an intersecting plex.
- a number of databases share the resources of an application server. Each of these has its own load and activity profile that may change from hour to hour. Queuing delays can result when two or more heavily loaded objects are mistakenly placed on the same stripset .
- the total available storage capacity is 45 GB, after subtracting that already used by the database shown. While only 10% of the available disk resources have been used, there will typically be other database applications that share the disk resources. These must be placed so as not to degrade performance.
- Table 1 and Index 1 are objects from a first database and Table A and Index A are objects from a second database. These databases would also include other items not shown in Fig. 2. All of these objects are striped across multiple disks to optimize performance, and while the performance for each database may have been optimized, if Table A and Index 1 are both heavily used, the three disks that the stripes of these objects share will be overloaded, and access requests will queue, generating an activity "hot-spot" and costly delays in servicing a customer request for a record.
- Fig. 3 shows a somewhat more complicated and realistic situation where several heavily used stripes overlap on isolated single drives to create several hot spots shown by the black drive symbols .
- stripe set as used herein is to be interpreted as including all of the disks that make up a set of stripes which either intersect each other or which intersect another set of intersecting stripes.
- stripe sets may include several intersecting striped plexes.
- Stripe sets, which may include many disks of multiple intersecting stripes, must be distinguished from stripes, which are made up of the disk or disks on which a plex (i.e., a logical disk) is stored.
- Figs. 2 and 3 assume that no other plexes or stripes are stored other than those shown.
- disks 12, on which Table 1 is stored would make up one stripe set.
- the stripe set includes the same disks as the plex on which Table 1 is stored.
- disks 14 would make up another stripe set.
- the stripe set would include the disks of two stripes: the stripe on which Index 1 is stored and the stripe on which Table A is stored.
- all of the disks 15 would form a single stripe set, since the various stripes shown in Fig. 3 are all intersecting. In actual databases, the situations are vastly more complicated than is shown in Figs. 1-3.
- a working VLDB would include hundreds of objects with a very large number of intersections where potential hotspots could arise. While Figs. 1-3 depict the disk array as an orderly set of orthogonally arranged drives, stripes may be distributed across any of the disks in any order. Thus, in a 50 disk array, one stripe may be on disks 2, 3, and 4 while another may be on disks 2, 5, 34, 35, and 49. With hundreds of objects spread across stripes that are essentially arbitrary in arrangement, it is virtually impossible for a DBA to visualize the system while attempting to track down and eliminate hot spots.
- the patterns of accessing the database are dynamic, changing constantly with time. It is not unusual to encounter situations where system performance is degraded only at certain times of the day, week, or month, in response to database queries which only occur periodically. For example, payroll records may only be heavily used weekly or monthly.
- Fig. 4 is a block diagram of an exemplary Oracle VLDB system.
- the system includes a host or server computer 20 on which the Oracle database application program 21 runs.
- the server 20 also includes operating system software 22, such as Unix or Windows NT.
- the operating system includes a file system 32 which responds to requests from the Oracle database to save and retrieve database files, and also disk driver routines 45 which actually control the sending and retrieval of data to individual disks.
- a volume manger 30, such a Veritas is also included, as discussed in more detail below.
- the operating system 22 includes provision for connecting via a network 24 to a plurality of terminals or other devices by which people can enter data into and retrieve data from the Oracle system.
- Data is stored on a disk drive array 26.
- Array 26 will have a large number of individual disk drives 34, the exact number being selected to provide adequate storage space and to provide the access speed required for the particular application.
- a VLDB with 200 GB of data might use a disk array with 20 to 50 disks.
- the disk drive array typically includes a controller which responds to commands from the file system 32 to store data on individual disks 34, although sometimes the disks are directly controlled by the computer 20.
- the individual disks may actually be virtual disks, implemented by a plurality of disks and a dedicated controller.
- a RAID disk array would be an example of such a virtual disk drive.
- the Oracle server stores data and makes requests for retrieval of data to the file system 32.
- the file system is usually a part of the operating system 22 and includes a file system manager.
- a VLDB needs to store data of various types including, for example, tables of data, indexes, relations, and other items. Depending on the particular implementation of a VLDB other items will be included in the list of items to be stored. These items will be collectively referred to as database objects in this description of the preferred embodiment.
- database objects are all stored as Oracle files, regardless of the type of the object.
- Oracle files are each associated with a tablespace, which can contain one or more Oracle files.
- Files can be assigned a particular storage location, and so the placement of Oracle tablespaces is determined by the placement of the associated file.
- the placement of files is determined by the DBA during the initial design and setup of an Oracle database, and file placement can be changed after the initial database setup.
- a volume is a virtual or logical disk, and may include a single disk or may include several disks across which stored database files are striped.
- the placement of a volume is determined by the DBA during initial setup.
- a database file is always stored in a single volume, and a volume may contain one or many files.
- the volume manager 30 is operating system level software that manages the striping and mirroring of data and plexes.
- the volume manager is operating system level software that manages the striping and mirroring of data and plexes.
- Some VLDB systems do not include a volume manager, and the sending of data to the disk driver routines 43 would be carried out by the operating system's file system 32 instead of by a volume manager.
- the file system 32 and volume manager 30 will send commands and data to the disk array 26 to store the data on the proper disk or disks.
- the volume manager 30 may implement redundant data storage.
- the Veritas volume manager frequently used in Oracle systems may be set up to automatically mirror selected volumes on the disk array. Data mirroring can be used for protection from disk or hardware failure, and also to allow faster access to heavily used data.
- data is stored in volumes by the volume manager, there may be more than one location where data in a volume is stored.
- Each of these individual copies of the data will be referred to herein as a plex.
- V0L1 which is mirrored by the volume manager would be stored in two different plexes, V0L1-P1 and V0L1-P2, which would normally be located on different individual disks or sets of disks in the disk array.
- Each plex that makes up a volume is normally structured the same way in terms of disk usage. Thus if the plex V0L1-P1 were striped across five individual disks, its mirror V0L1-P2 would likewise be striped across five different disks. Volumes that are not mirrored consist of a single plex. It should be understood that references to volumes or plexes refers to logical disk structures which may include a single disk or multiple disks across which files are striped.
- Data is periodically taken at preset intervals to collect information that shows the statistics of data storage on three different levels. Statistics are kept for Oracle database file I/O requests, for plex I/O operations, and for individual disk I/O operations. This data is stored in its own database, typically on a platform which is independent of the Oracle server and disk array.
- the Oracle server includes a monitor routine 40 which periodically samples and sends data about Oracle file performance which is stored for later analysis.
- This monitor routine include information on when samples are to be taken, and it gathers statistical data on Oracle file I/O operations that are readily available from the Oracle program. In the embodiment shown in Fig. 4, this data is sent over a channel 42 to a separate computer 45, but it should be understood that other arrangements may also be used. For example, some or all of the functions of the monitor computer 44 could be performed on the machine hosting the Oracle server 20.
- the volume manager 30 and the disk driver routines 43 have their own monitor routines 44 and 46 which collect and send performance data for storage, as described more fully below.
- the monitor routines may query the volume manager and the disk driver routines for the needed data, or they may have to be written to gather these statistics themselves, if the needed data is not provided by the volume manager and disk drivers.
- Veritas has a statistics function that will return this data for plex operations, while the IBM volume manager does not and needs a specialized monitor routine.
- These monitor routines 40, 44, and 46 are straightforward and may be easily written by one knowledgeable in the art. It should also be appreciated that the present invention may be used with configurations other than that shown in Fig. 4.
- a system may not include a volume manager, in which case the monitor routine 44 which collects data on logical disk accesses would monitor the file system 32, or the disk driver routines may be part of the disk array software, rather than in the operating system, in which case the monitor routine 46 which collects data on individual disk accesses would monitor the driver routines in the disk array software.
- the DBA Prior to beginning the monitoring operations that periodically sample the database system performance, the DBA must set up a schedule which determines when samples are taken.
- the scheduling data includes the data shown in the table in Table l. Items to be monitored may include database files, volumes or plexes, and individual disks.
- the scheduling data includes fields to identify the host (server) , the item to be monitored on the host to which the scheduling data applies, starting and ending times for taking samples, the interval between samples, and data identifying which days samples are to be taken.
- a host field is included because typically, the present invention would be used in situations having multiple databases from multiple servers, although the embodiment described herein only shows one database for simplicity. Different sampling times may be set for the same item. For example, accounting related items might be sampled more frequently during the end of payroll periods when usage is heavier.
- a schedule might identify all database files for sampling once an hour and additionally identify accounting related files for sampling every ten minutes during the last five days of each month when accounting activity is high.
- the system of Fig. 4 also includes a store 60 for schema data, which represents the relationships between the monitored items, including database files, logical disks such as plexes or volumes, and individual disk drives.
- the schema store 60 also includes relationships between other database structures of interest, such as tablespaces and stripe sets. Tables 2-5 show the schema data which would be stored for the described embodiment .
- Table 2 shows schema data that would be stored for each database file. This data includes the Oracle file name, the host name, the volume name on which the file is stored, the Oracle tablespace which contains the file, the database name with which the file is associated, a time stamp and usage parameters .
- Table 3 shows plex schema data that would be stored. This data includes the plex name, the host name, the name of the stripe set of which the plex is a part, the name of the volume associated with the plex, a time stamp, and usage parameters .
- Table 4 shows schema data that would be stored for each of the disk drives, including the disk name, the host name, the associated stripe set name, a time stamp, and performance specifications.
- Table 5 shows schema data that would be stored to identify each of the disks which make up a stripe on which a plex is stored. This data includes a record with the disk name and plex name for each disk making up a stripe, along with an identification of the host and a time stamp.
- the stripe schema data in Table 5 is different from the stripe set data stored in the records of Tables 3 and 4.
- the stripes identified in Table 5 are the stripes, stored on one or more disks, on which a single plex is stored.
- the time stamp data in Tables 2, 4, and 5 indicates the beginning time at which the schema data is valid.
- the relationships between plexes, stripe sets, disk drives, and other database structures may change over time as placement is changed. Accordingly, it is important to indicate the time at which the schema data is valid, otherwise the sample data that is collected and stored may be incorrectly interpreted.
- the schema usage specs in Tables 2-4 include usage and performance specs.
- the usage specs for Oracle files and plexes reflect the DBA' s estimate of the expected load for the different items, such as number of reads and writes, etc.
- the performance specs for the disk drives include seek parameters, disk RPM, and other performance data. These parameters are used to normalize the data from collected samples before it is displayed, as described more fully below.
- the monitor computer 45 in Fig. 4 has communication channels with the Oracle server 20 and with the file system manager 32, denoted by dashed lines 54 and 56. It sends sampling schedule data over these channels to each of the monitoring routines and receives updates to the schema relationships over these channels when the schema is changed .
- the monitor routines for the Oracle database, the volume manager, and the disk drivers collect a number of different performance statistics and send that data to the monitor computer 45 for storage in the usage data store 58.
- These measurements provide a series of snapshots of the system performance which are used by the analysis tool described below to diagnose system problems.
- data for each sample is gathered over three successive measurement periods that are about fifteen seconds long. It should be appreciated that the measurement period may be varied, depending on the particular application involved.
- the properties collected include the following: number of reads per second; number of writes per second; number of kilobytes read per second; number of kilobytes written per second; queue length, which is the average number of I/O requests pending for a disk drive during the measurement period; service time, which is the average time in milliseconds for an I/O request to be completed; percent busy, which represents the average utilization factor for a disk during the measurement period; and percent wait, which is the average percentage of time that there are transactions waiting for service during the measurement period.
- Table 6 shows the format for the data taken and stored for the disk performance samples, along with exemplary data.
- the data stored for each sample includes the disk name (or other disk identifier) and the time of the sample. These two fields uniquely identify each of the disk data samples.
- For each sample all of the properties listed above are stored, including: the total number of read operations performed by the disk over the last second; the total number of write operation performed; the number of kilobytes (kB) read; the total number of kB written; the percentage of time the disk was busy; the average queue size for the disk; the wait percentage for the disk; and the average service time in milliseconds.
- Table 7 shows the format for the data taken and stored for the plex performance samples, along with exemplary data. These samples are identified by fields with the plex name and the time of the sample.
- the properties stored for each plex sample include the number of reads; the number of writes; kB read; kB written; and service time.
- Table 8 shows the format for the data taken and stored for the Oracle file performance samples, along with exemplary data. Each sample is identified by fields with the file name and sample time. The properties stored for each file sample include: number of reads; number of writes; kB read; kB written; and service time.
- the monitor routines 40, 44, and 46 send data reflecting the actual operations performed at each of the three levels monitored. In many, if not most, cases, not all database files, plexes and disks being monitored will have activity during each measurement period.
- the storage routines running in monitor computer 45, or its equivalent, which store data in the usage data store 58 keeps track of all items being monitored. Monitors 40, 44 and 46 create and add usage records with zero values for each of the properties for each item being monitored which has no activity during a measurement period. In this manner, the three data tables shown in Tables 6-8 will include for each sample time stamp a complete list of records reflecting every item being monitored, even those zero values for those items - disks, plexes, and database files — which had no activity during the measurement period.
- the usage and schema data stores are the sources for data used to generate the displays that the analysis tool provides.
- the analysis software runs on an independent computer, such as an IBM compatible personal computer running an operating system such as Windows 95 or Windows NT.
- Fig. 5 shows a typical screen that would be presented to the user to initiate an analysis session.
- a DBA would first choose a particular Oracle host or server, as shown in box 70.
- the user selects the time period to be analyzed by filling in the data in the boxes in a window such as that shown in Fig. 5 as window 78.
- This determines which samples stored in the sample data store 58 will be used for the analysis.
- a user can select a long period of time to spot general trends in system usage and performance. Alternatively a very small interval can be selected if the cause of a particular problem is to be analyzed.
- the interval window will include shortcuts for selecting particular periods of interest, such as weekdays.
- I/O type menu 72 includes tablespaces, files, volumes, plexes, stripe sets, and disks, as shown by the drop down menu 72.
- Sample data from the monitor routines 40, 44, and 46 are available directly from the usage data store 58, as described above in connection with Figs. 9-11.
- Data for stripe sets, volumes, and tablespaces are calculated by adding together the statistics for the associated disks, plexes, and database files, respectively, when one of these items is selected.
- the available properties will vary, depending on the particular item selected in I/O type menu 72.
- the available properties for disks, plexes, and Oracle files are as shown in Tables 6-8.
- the properties available for tablespaces, volumes, and stripe sets are the same as for files, plexes, and disks respectively, and they are calculated as described above.
- Weighted I/O allows a user to select two or more of the available properties for an item and to combine them in whatever proportions the user desires. For example, a user might choose to select to give equal or 25% weighting to four properties such as number of reads and writes and number of kB read and written. Different properties will be chosen by a user, depending on the particular use of the database being analyzed. Different applications impose much different I/O load profiles on a VLDB storage system. For example, an OLTP application is transaction oriented, and the data blocks are typically short. In OLTP, the number of reads and writes is typically more representative of system performance than the total number of kilobytes read and written.
- the analysis offers several different mathematical methods of combining the samples, including average, minimum, peak, median and RMS, chosen in menu 76.
- the user initiates an analysis by activating the "calculate" screen button 80.
- Fig. 6 shows the results of an analysis that requested the number-of-reads property for the stripe sets of a database using the average value of the samples selected.
- the data is displayed as a bar graph with the stripe sets arranged in descending order of usage, as shown in Fig. 6.
- the identity, or name, for each stripe set is given in column 82 to the left of the corresponding bar.
- statistics are shown for a number of different items of the selected I/O type.
- statistics are shown for a plurality of stripe set items, each identified by its name in column 82.
- the term item or named item in the description below should be understood to refer the individual disks, stripes, plexes, volumes, tablespaces, or stripe sets whose properties are being displayed.
- Figs . 7A and 7B show the steps that would be carried out in response to the calculate button to produce the display of Fig. 6.
- the system determines whether the selected I/O type is disks, plexes, or files, block 130.
- the sample data is directly available from the usage data store 58, and the system can proceed to retrieve the data samples for the time interval chosen by the user, block 139.
- the system For stripe sets, volumes and tablespaces, the system must go to the schema data store 60 to determine the re- lated disks, plexes, or files, block 134. From the schema data store, the system determines the disks, plexes, or files which are related to each named item of the selected type, after which the data samples are retrieved from the usage store 58 for the related items occurring in selected time interval, block 138.
- the data sample are collected, blocks 142 and 143.
- the individual samples for each named item are combined using the selected mathematical summary to create a single statistical value for each name.
- the data values may be directly combined using the selected statistical method, block 146.
- the statistic is determined by combining the collected data values for related items and then using the selected summary type.
- Normalization is done to take into account the fact that for a particular I/O type the different named items may have different I/O capacities. In order to accurately display the relative hotness for many items, the activity of that item should be displayed normalized based on the relative performance of the item.
- the disk array 26 may have disks of varying performance capabilities. If for example, the disk array has half of its disks which have a maximum capability of 60 I/O operations per second and half with a maximum of 80 I/O operations per second, the calculated statistical values for each of those two disks is normalized by dividing by the respective I/O capacity.
- the disk performance parameters used for performing this normalization are stored in the schema data store, as discussed above in connection with Table 4. Stripe set normalization is performed similarly. The I/O performance parameters for the disks which make up each stripe set are added together to provide the normalization factor for that stripe set .
- Normalization for volumes, plexes, files, and tablespaces is done differently. If, for example, there are 10 volumes stored on one stripe, each individual volume can perform at the level set by the disks on which it is striped, but obviously all 10 volumes cannot perform this well if they are being accessed at the same time.
- One method for normalizing I/O types other than disks and stripe sets is to normalize them relative to the performance of disk stripe on which they are stored. Alternatively, these I/O types can be normalized with respect to the expected activity of the particular item in question. The level of expected activity can be determined by prediction based on the database design and expected usage, or it can be determined by using the actual usage as reflected by the data samples gathered by the present invention. The expected activity for files and plexes would be stored as usage parameters in the schema data file as discussed above in connection with Tables 2 and 3.
- Fig. 7B illustrates normalization using the second method described above where non-disk-related I/O types are normalized based on expected I/O operations.
- the system first checks to see if the I/O type is disks or stripe sets, block 150. If so, then the disk performance parameters are retrieved to normalize the statistics for each item, block 154. If not, then the expected I/O operations are retrieved from the schema data store 60, block 155. Next the calculated values for each named item, as determined in blocks 146 and 147, are normalized as described above, block 158. Finally, the data is arranged in order of hotness, block 162, and the normalized data is displayed on the monitor, block 166, to give the screen shown in Fig. 6.
- a user can display usage data related to any of the displayed items. Referring again to Fig. 6, further analysis may be carried out for any of the stripe sets shown.
- a menu 84 may be brought up which allows a user to select the disk, file volume, plex, or tablespace usage associated with stripe 14 for display.
- a "samples" option in menu 84 is also available and may be selected to view the actual sample data plotted against time, as shown by Figs. 9 and 11 and discussed in more detail below.
- Fig. 8 shows a bar graph similar in form to Fig. 6 displaying the number of reads for the three disks that stripe 14 is spread across.
- the procedure for generating the display of Fig. 8 is the same as shown in Figs 7A and 7B, with the additional step before blocks 138 or 139 of further narrowing the subset of retrieved samples by selecting those items that are related to the selected named item, which is stripe set 14 in the example shown in Fig. 8.
- a display similar to that shown in Fig. 9 would be displayed, showing the values of each stored sample in the selected time frame.
- This procedure can be reiterated to determine the ultimate source or cause of a hot item. For example, right clicking on bar 90 in Fig. 8 brings up a menu 88 similar to menu 84 which allows a user to do an analysis of the stripe sets, plexes, volumes, files, or tablespaces associated with disk 12. This procedure can be repeated until the source of the problem is tracked down.
- Figs. 6 and 8 show only a few bars representing different stripe sets and disks. A VLDB would typically contain many times this number.
- the windows of Figs. 6 and 8 would be typically programmed to include other conventional features, such as the ability to zoom in and out to show different numbers of the selected item, and provision for scroll bars to move the displayed part of a large window up and down. Programming these functions is a normal part of designing such windows and is easily done by one skilled in the art. Other options may added to the interface without departing from the teachings of the present invention.
- the following example illustrates how the present invention may be used in a realistic situation.
- an on-line transactional processing database is being used to provide order entry support for customer service personnel taking orders, and that the present invention has been used to collect samples for the database every fifteen minutes.
- One typical problem that might arise would be a sudden degradation of performance of the order entry application, and for this example, assume that the degradation started at 7:00 am and lasted for a period of about three hours. This type of problem typically results in an increase in the waiting period for telephone customers, resulting in abandoned calls and lost sales, so that correction of the problem quickly is of utmost importance.
- a DBA using the present invention might first set the Select Interval window 78 in Fig. 5 to select a time period of 7:00 am to 10:00 am on the date in question. Next, the DBA might select to analyze the stripe set activity. Fig. 6 shows the display that would result. From Fig. 6, it is apparent that stripe set 14 is the busiest or "hottest" stripe set, The question is now what is causing this stripe set to be so hot .
- the DBA might next choose stripe 14 and select samples, to show the activity for stripe set 14 over time.
- the DBA has chosen to display I/O transactions from 5:00 am to 1:00 PM . From this display it appears that the source of the problem is not an abnormally high number of I/O operations during the 7:00-10:00 time period, which would be the first cause that a DBA might assume in attempting to fix the problem without the facilities provided by the present invention.
- the DBA might next choose to look at individual disk activity within stripe set 14. This would produce the display of Fig. 8. From Fig. 8, it would be clear that disk 12 is very hot and that something stored on this disk is slowing the performance of the stripe set .
- the problem could be that a single unstriped plex or volume is installed there, perhaps because there was free space available on that disk when it was installed. Alternatively, the problem might be multiple plexes interfering at a point of intersection on disk 12.
- the DBA might next choose to look into the plexes stored on the disk. Selecting to examine the plexes associated with disk 12 for analysis would result in the display of Fig. 10. From this display, it is appears that high activity on plex 14A is causing the slowdown. The DBA might then choose to look at the samples for plex 14A I/O over the time period from 5:00 am to 1:00 PM, resulting in the display of Fig. 11. Fig. 11 shows that there is spike of abnormally high activity on plex 14A during the time period of poor performance, indicating that the DBA is homing in on the problem.
- the present invention can be used to improve placement, even when there is no apparent problem, by analyzing the data collected and stored. This data is analyzed by the process shown in the flow chart of Fig. 12.
- the user would first select the relevant time period and the type of property to be used, as indicated by block 102 in Fig. 12.
- different properties are more or less important depending on the particular application of the database being analyzed.
- the number of reads and the number or writes are the most important statistics, and a weighted I/O property with 50% read and 50% writes would be selected.
- the number of reads would be the most relevant statistical.
- the most important statistic is kilobytes read per second.
- the present invention carries out the remainder of the procedure shown in Fig. 12 to recommend placement actions to take out .
- These procedures may be done on the PC 52 , shown in Fig. 4, or by another processor which has access to the usage and schema data stores 58 and 60.
- the system determines the busiest stripe set, block 104.
- the system determines whether the busiest stripe set has more that one plex stored in it, block 106. If only a single plex or logical file is stored on the stripe set, the system will recommend using more disks for the stripe set, block 110. If more than one logical file is stored on the stripe set, the system determines the second busiest plex in the busiest stripe set, block 108. This plex will be referred to below as the plex to be moved. Next the least busy stripe set is determined, block 112. The free space in the least busy stripe set is then checked to see whether there is enough room for the plex to be moved to the least busy stripe set, block 114.
- the least busy stripe set is analyzed by totaling (1) the free space, and (2) the space occupied by least busy plexes in that stripe set, until the total provides sufficient space to hold the plex to be moved, and that recommendation is made block 116.
Abstract
Description
Claims
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2000522523A JP2001524711A (en) | 1997-11-24 | 1998-11-24 | Disk Performance Analysis Method for Large Database System |
AU15271/99A AU1527199A (en) | 1997-11-24 | 1998-11-24 | Method for analyzing disk performance of large database systems |
GB0012368A GB2346995B (en) | 1997-11-24 | 1998-11-24 | Method for analyzing disk performance of large database systems |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US08/977,268 US6035306A (en) | 1997-11-24 | 1997-11-24 | Method for improving performance of large databases |
US08/977,268 | 1997-11-24 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO1999027451A1 true WO1999027451A1 (en) | 1999-06-03 |
Family
ID=25524977
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US1998/024530 WO1999027451A1 (en) | 1997-11-24 | 1998-11-24 | Method for analyzing disk performance of large database systems |
Country Status (5)
Country | Link |
---|---|
US (1) | US6035306A (en) |
JP (1) | JP2001524711A (en) |
AU (1) | AU1527199A (en) |
GB (1) | GB2346995B (en) |
WO (1) | WO1999027451A1 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105304140A (en) * | 2014-06-13 | 2016-02-03 | 北京安兔兔科技有限公司 | Method and apparatus for testing memory performance of electronic equipment |
CN105446848A (en) * | 2014-06-13 | 2016-03-30 | 北京安兔兔科技有限公司 | Electronic device data processing performance test method and device |
US9330108B2 (en) | 2013-09-30 | 2016-05-03 | International Business Machines Corporation | Multi-site heat map management |
Families Citing this family (108)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH1115897A (en) * | 1997-06-20 | 1999-01-22 | Fujitsu Ltd | Interactive data analysis supporting device and medium recording interactive data analysis supporting program |
US6546548B1 (en) * | 1997-12-12 | 2003-04-08 | International Business Machines Corporation | Method and system for compensating for output overhead in trace data using initial calibration information |
US6385763B1 (en) * | 1998-12-29 | 2002-05-07 | At&T Corp. | Methodology for mapping use cases to operations for operational profile development |
US6553369B1 (en) * | 1999-03-11 | 2003-04-22 | Oracle Corporation | Approach for performing administrative functions in information systems |
US6542854B2 (en) | 1999-04-30 | 2003-04-01 | Oracle Corporation | Method and mechanism for profiling a system |
US7389351B2 (en) * | 2001-03-15 | 2008-06-17 | Microsoft Corporation | System and method for identifying and establishing preferred modalities or channels for communications based on participants' preferences and contexts |
US7103806B1 (en) * | 1999-06-04 | 2006-09-05 | Microsoft Corporation | System for performing context-sensitive decisions about ideal communication modalities considering information about channel reliability |
US6668253B1 (en) * | 1999-09-08 | 2003-12-23 | Reynolds & Reynolds Holdings, Inc. | Enterprise information management system and methods |
AU7596500A (en) | 1999-09-20 | 2001-04-24 | Quintiles Transnational Corporation | System and method for analyzing de-identified health care data |
US7320004B1 (en) * | 2000-04-28 | 2008-01-15 | Microsoft Corporation | System and method for managing database files in a client management tool |
GB2363221B (en) * | 2000-06-09 | 2002-05-01 | Oracle Corp | Summary creation |
US6948135B1 (en) * | 2000-06-21 | 2005-09-20 | Microsoft Corporation | Method and systems of providing information to computer users |
US6523047B1 (en) * | 2000-08-17 | 2003-02-18 | International Business Machines Corporation | System and method for volume expansion in the presence of multiple plug-in features |
US6886020B1 (en) * | 2000-08-17 | 2005-04-26 | Emc Corporation | Method and apparatus for storage system metrics management and archive |
US7330895B1 (en) * | 2001-03-15 | 2008-02-12 | Microsoft Corporation | Representation, decision models, and user interface for encoding managing preferences, and performing automated decision making about the timing and modalities of interpersonal communications |
KR100344640B1 (en) * | 2001-03-24 | 2002-07-25 | 주식회사 엑셈 | Apparatus for monitoring performance of database and method thereof |
US7739614B1 (en) * | 2001-05-22 | 2010-06-15 | Netapp, Inc. | System and method for consolidated reporting of characteristics for a group of directories |
JP4162183B2 (en) * | 2001-11-12 | 2008-10-08 | 株式会社日立製作所 | Storage device having means for acquiring static information of database management system |
JP4087097B2 (en) * | 2001-11-12 | 2008-05-14 | 株式会社日立製作所 | Data relocation method and data relocation method considering database management system information |
US7644144B1 (en) | 2001-12-21 | 2010-01-05 | Microsoft Corporation | Methods, tools, and interfaces for the dynamic assignment of people to groups to enable enhanced communication and collaboration |
KR100850255B1 (en) * | 2001-12-28 | 2008-08-19 | 인터내셔널 비지네스 머신즈 코포레이션 | Real time data warehousing |
US7249118B2 (en) * | 2002-05-17 | 2007-07-24 | Aleri, Inc. | Database system and methods |
US7085786B2 (en) * | 2002-05-20 | 2006-08-01 | International Business Machines Corporation | Apparatus and method to schedule and perform database maintenance |
JP4100968B2 (en) * | 2002-06-06 | 2008-06-11 | 株式会社日立製作所 | Data mapping management device |
US6925541B2 (en) * | 2002-06-12 | 2005-08-02 | Hitachi, Ltd. | Method and apparatus for managing replication volumes |
US7870240B1 (en) | 2002-06-28 | 2011-01-11 | Microsoft Corporation | Metadata schema for interpersonal communications management systems |
US7032093B1 (en) * | 2002-08-08 | 2006-04-18 | 3Pardata, Inc. | On-demand allocation of physical storage for virtual volumes using a zero logical disk |
AU2003270482A1 (en) | 2002-09-09 | 2004-03-29 | Commvault Systems, Inc. | Dynamic storage device pooling in a computer system |
US6806543B2 (en) * | 2002-09-12 | 2004-10-19 | Intel Corporation | Microfluidic apparatus with integrated porous-substrate/sensor for real-time (bio)chemical molecule detection |
US7900052B2 (en) * | 2002-11-06 | 2011-03-01 | International Business Machines Corporation | Confidential data sharing and anonymous entity resolution |
US20040117408A1 (en) * | 2002-12-17 | 2004-06-17 | Capital One Financial Corporation | Systems, methods and articles of manufacture for determining available space in a database |
US8620937B2 (en) * | 2002-12-27 | 2013-12-31 | International Business Machines Corporation | Real time data warehousing |
WO2004061668A1 (en) | 2002-12-31 | 2004-07-22 | International Business Machines Corporation | Authorized anonymous authentication |
US6804627B1 (en) * | 2002-12-31 | 2004-10-12 | Emc Corporation | System and method for gathering and analyzing database performance statistics |
US7200602B2 (en) * | 2003-02-07 | 2007-04-03 | International Business Machines Corporation | Data set comparison and net change processing |
US20040181707A1 (en) * | 2003-03-11 | 2004-09-16 | Hitachi, Ltd. | Method and apparatus for seamless management for disaster recovery |
WO2004097596A2 (en) * | 2003-03-24 | 2004-11-11 | Systems Research & Development | Secure coordinate identification method, system and program |
JP4294353B2 (en) * | 2003-03-28 | 2009-07-08 | 株式会社日立製作所 | Storage system failure management method and apparatus having job management function |
JP4313068B2 (en) * | 2003-03-28 | 2009-08-12 | 株式会社日立製作所 | Cache management method for storage device |
JP2004302751A (en) * | 2003-03-31 | 2004-10-28 | Hitachi Ltd | Method for managing performance of computer system and computer system managing performance of storage device |
US7246207B2 (en) | 2003-04-03 | 2007-07-17 | Commvault Systems, Inc. | System and method for dynamically performing storage operations in a computer network |
JP4335597B2 (en) * | 2003-06-30 | 2009-09-30 | 株式会社日立製作所 | Storage management system |
US7526508B2 (en) * | 2003-09-04 | 2009-04-28 | Oracle International Corporation | Self-managing database architecture |
US7774312B2 (en) * | 2003-09-04 | 2010-08-10 | Oracle International Corporation | Self-managing performance statistics repository for databases |
US7292961B2 (en) * | 2003-09-05 | 2007-11-06 | Oracle International Corporation | Capturing session activity as in-memory snapshots using a time-based sampling technique within a database for performance tuning and problem diagnosis |
US7673291B2 (en) * | 2003-09-05 | 2010-03-02 | Oracle International Corporation | Automatic database diagnostic monitor architecture |
US7376682B2 (en) * | 2003-09-05 | 2008-05-20 | Oracle International Corporation | Time model |
US7577807B2 (en) * | 2003-09-23 | 2009-08-18 | Symantec Operating Corporation | Methods and devices for restoring a portion of a data store |
US7577806B2 (en) * | 2003-09-23 | 2009-08-18 | Symantec Operating Corporation | Systems and methods for time dependent data storage and recovery |
US7904428B2 (en) * | 2003-09-23 | 2011-03-08 | Symantec Corporation | Methods and apparatus for recording write requests directed to a data store |
US7827362B2 (en) * | 2004-08-24 | 2010-11-02 | Symantec Corporation | Systems, apparatus, and methods for processing I/O requests |
US7296008B2 (en) * | 2004-08-24 | 2007-11-13 | Symantec Operating Corporation | Generation and use of a time map for accessing a prior image of a storage device |
US7730222B2 (en) * | 2004-08-24 | 2010-06-01 | Symantec Operating System | Processing storage-related I/O requests using binary tree data structures |
US7991748B2 (en) * | 2003-09-23 | 2011-08-02 | Symantec Corporation | Virtual data store creation and use |
US7725760B2 (en) * | 2003-09-23 | 2010-05-25 | Symantec Operating Corporation | Data storage system |
US7239581B2 (en) * | 2004-08-24 | 2007-07-03 | Symantec Operating Corporation | Systems and methods for synchronizing the internal clocks of a plurality of processor modules |
US7409587B2 (en) * | 2004-08-24 | 2008-08-05 | Symantec Operating Corporation | Recovering from storage transaction failures using checkpoints |
US7631120B2 (en) * | 2004-08-24 | 2009-12-08 | Symantec Operating Corporation | Methods and apparatus for optimally selecting a storage buffer for the storage of data |
US7287133B2 (en) * | 2004-08-24 | 2007-10-23 | Symantec Operating Corporation | Systems and methods for providing a modification history for a location within a data store |
US7895247B2 (en) * | 2003-10-29 | 2011-02-22 | Oracle International Corporation | Tracking space usage in a database |
JP4516306B2 (en) * | 2003-11-28 | 2010-08-04 | 株式会社日立製作所 | How to collect storage network performance information |
US8024301B2 (en) * | 2004-03-26 | 2011-09-20 | Oracle International Corporation | Automatic database diagnostic usage models |
US7647356B2 (en) * | 2004-05-07 | 2010-01-12 | Oracle International Corporation | Methods and apparatus for facilitating analysis of large data sets |
US8010337B2 (en) * | 2004-09-22 | 2011-08-30 | Microsoft Corporation | Predicting database system performance |
US7533230B2 (en) * | 2004-10-13 | 2009-05-12 | Hewlett-Packard Developmetn Company, L.P. | Transparent migration of files among various types of storage volumes based on file access properties |
GB2419198A (en) * | 2004-10-14 | 2006-04-19 | Hewlett Packard Development Co | Identifying performance affecting causes in a data storage system |
US7756840B2 (en) * | 2004-11-03 | 2010-07-13 | DBA InfoPower Inc. | Real-time database performance and availability monitoring method and system |
WO2006052872A2 (en) | 2004-11-05 | 2006-05-18 | Commvault Systems, Inc. | System and method to support single instance storage operations |
US7490207B2 (en) | 2004-11-08 | 2009-02-10 | Commvault Systems, Inc. | System and method for performing auxillary storage operations |
US20060161752A1 (en) * | 2005-01-18 | 2006-07-20 | Burkey Todd R | Method, apparatus and program storage device for providing adaptive, attribute driven, closed-loop storage management configuration and control |
US7941602B2 (en) * | 2005-02-10 | 2011-05-10 | Xiotech Corporation | Method, apparatus and program storage device for providing geographically isolated failover using instant RAID swapping in mirrored virtual disks |
JP4579000B2 (en) * | 2005-02-14 | 2010-11-10 | 株式会社日立製作所 | Data allocation setting in computer system |
US20060200450A1 (en) * | 2005-03-04 | 2006-09-07 | Microsoft Corporation | Monitoring health of actively executing computer applications |
US7853585B2 (en) | 2005-03-17 | 2010-12-14 | International Business Machines Corporation | Monitoring performance of a data processing system |
US20060218360A1 (en) * | 2005-03-22 | 2006-09-28 | Burkey Todd R | Method, apparatus and program storage device for providing an optimized read methodology for synchronously mirrored virtual disk pairs |
US7571192B2 (en) * | 2005-06-15 | 2009-08-04 | Oracle International Corporation | Methods and apparatus for maintaining consistency during analysis of large data sets |
WO2007047346A2 (en) * | 2005-10-14 | 2007-04-26 | Symantec Operating Corporation | Technique for timeline compression in a data store |
US7657782B2 (en) * | 2006-06-08 | 2010-02-02 | International Business Machines Corporation | Creating and managing multiple virtualized remote mirroring session consistency groups |
US8204831B2 (en) * | 2006-11-13 | 2012-06-19 | International Business Machines Corporation | Post-anonymous fuzzy comparisons without the use of pre-anonymization variants |
US9355273B2 (en) | 2006-12-18 | 2016-05-31 | Bank Of America, N.A., As Collateral Agent | System and method for the protection and de-identification of health care data |
US7711716B2 (en) * | 2007-03-06 | 2010-05-04 | Microsoft Corporation | Optimizations for a background database consistency check |
US9449047B2 (en) | 2007-06-19 | 2016-09-20 | Sybase, Inc. | Dynamic modification of schemas in streaming databases |
US8745012B2 (en) | 2007-08-10 | 2014-06-03 | Sybase, Inc. | Log-structured store for streaming data |
JP4456626B2 (en) * | 2007-09-28 | 2010-04-28 | 富士通株式会社 | Disk array device, disk array device control program, and disk array device control method |
US8990811B2 (en) * | 2007-10-19 | 2015-03-24 | Oracle International Corporation | Future-based performance baselines |
US7971013B2 (en) * | 2008-04-30 | 2011-06-28 | Xiotech Corporation | Compensating for write speed differences between mirroring storage devices by striping |
US20100011176A1 (en) * | 2008-07-11 | 2010-01-14 | Burkey Todd R | Performance of binary bulk IO operations on virtual disks by interleaving |
US20100011371A1 (en) * | 2008-07-11 | 2010-01-14 | Burkey Todd R | Performance of unary bulk IO operations on virtual disks by interleaving |
CN102231130B (en) * | 2010-01-11 | 2015-06-17 | 国际商业机器公司 | Method and device for analyzing computer system performances |
US8346990B2 (en) * | 2011-01-31 | 2013-01-01 | Lsi Corporation | Methods and systems for tracking data activity levels |
US10528590B2 (en) | 2014-09-26 | 2020-01-07 | Oracle International Corporation | Optimizing a query with extrema function using in-memory data summaries on the storage server |
US10642837B2 (en) | 2013-03-15 | 2020-05-05 | Oracle International Corporation | Relocating derived cache during data rebalance to maintain application performance |
US10698918B2 (en) * | 2013-11-20 | 2020-06-30 | Qliktech International Ab | Methods and systems for wavelet based representation |
US9483510B2 (en) * | 2014-04-17 | 2016-11-01 | Netapp, Inc. | Correlating database and storage performance views |
US11048677B1 (en) | 2014-10-01 | 2021-06-29 | Servicenow, Inc. | Streamlined transaction and dimension data collection |
US9953070B1 (en) | 2015-04-05 | 2018-04-24 | Simply Data Now Inc. | Enterprise resource planning (ERP) system data extraction, loading, and directing |
US10366083B2 (en) | 2015-07-29 | 2019-07-30 | Oracle International Corporation | Materializing internal computations in-memory to improve query performance |
US10204135B2 (en) | 2015-07-29 | 2019-02-12 | Oracle International Corporation | Materializing expressions within in-memory virtual column units to accelerate analytic queries |
US10459895B2 (en) | 2017-03-21 | 2019-10-29 | Bank Of America Corporation | Database storage monitoring equipment |
JP6681369B2 (en) * | 2017-09-07 | 2020-04-15 | 株式会社日立製作所 | Performance management system, management device, and performance management method |
US11086876B2 (en) | 2017-09-29 | 2021-08-10 | Oracle International Corporation | Storing derived summaries on persistent memory of a storage device |
US10852951B1 (en) * | 2017-10-18 | 2020-12-01 | EMC IP Holding Company, LLC | System and method for improving I/O performance by introducing extent pool level I/O credits and user I/O credits throttling on Mapped RAID |
US10852966B1 (en) * | 2017-10-18 | 2020-12-01 | EMC IP Holding Company, LLC | System and method for creating mapped RAID group during expansion of extent pool |
US11226955B2 (en) | 2018-06-28 | 2022-01-18 | Oracle International Corporation | Techniques for enabling and integrating in-memory semi-structured data and text document searches with in-memory columnar query processing |
US11200234B2 (en) | 2019-06-14 | 2021-12-14 | Oracle International Corporation | Non-disruptive dynamic ad-hoc database catalog services |
US10990596B2 (en) | 2019-06-14 | 2021-04-27 | Oracle International Corporation | Non-disruptive referencing of special purpose operators for database management systems |
US11816589B2 (en) * | 2020-01-16 | 2023-11-14 | Sap Se | Performance throttling identification service for autonomous databases as a service |
US11593223B1 (en) | 2021-09-02 | 2023-02-28 | Commvault Systems, Inc. | Using resource pool administrative entities in a data storage management system to provide shared infrastructure to tenants |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0714063A2 (en) * | 1994-11-22 | 1996-05-29 | Hewlett-Packard Company | Method for identifying ways to improve performance in computer data storage systems |
WO1996017306A2 (en) * | 1994-11-21 | 1996-06-06 | Oracle Corporation | Media server |
WO1997017660A1 (en) * | 1995-11-03 | 1997-05-15 | Bull S.A. | Administrative interface for a database in a distributed computer environment |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4849879A (en) * | 1986-09-02 | 1989-07-18 | Digital Equipment Corp | Data processor performance advisor |
US5086386A (en) * | 1990-03-23 | 1992-02-04 | Sun Microsystems, Inc. | Method and apparatus for benchmarking the working set of window-based computer systems |
US5604899A (en) * | 1990-05-21 | 1997-02-18 | Financial Systems Technology Pty. Ltd. | Data relationships processor with unlimited expansion capability |
US5245638A (en) * | 1990-10-29 | 1993-09-14 | Iowa State University Research Foundation, Inc. | Method and system for benchmarking computers |
GB9023633D0 (en) * | 1990-10-31 | 1990-12-12 | Int Computers Ltd | Predicting the performance of a computer system |
US5303166A (en) * | 1992-04-14 | 1994-04-12 | International Business Machines Corporation | Method and system for automated network benchmark performance analysis |
US5337258A (en) * | 1992-07-10 | 1994-08-09 | Microsoft Corporation | Cost metrics |
US5794229A (en) * | 1993-04-16 | 1998-08-11 | Sybase, Inc. | Database system with methodology for storing a database table by vertically partitioning all columns of the table |
US5544313A (en) * | 1994-05-11 | 1996-08-06 | International Business Machines Corporation | Baton passing optimization scheme for load balancing/configuration planning in a video-on-demand computer system |
EP0689141A3 (en) * | 1994-06-20 | 1997-10-15 | At & T Corp | Interrupt-based hardware support for profiling system performance |
-
1997
- 1997-11-24 US US08/977,268 patent/US6035306A/en not_active Expired - Lifetime
-
1998
- 1998-11-24 GB GB0012368A patent/GB2346995B/en not_active Expired - Lifetime
- 1998-11-24 WO PCT/US1998/024530 patent/WO1999027451A1/en active Application Filing
- 1998-11-24 AU AU15271/99A patent/AU1527199A/en not_active Abandoned
- 1998-11-24 JP JP2000522523A patent/JP2001524711A/en active Pending
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1996017306A2 (en) * | 1994-11-21 | 1996-06-06 | Oracle Corporation | Media server |
EP0714063A2 (en) * | 1994-11-22 | 1996-05-29 | Hewlett-Packard Company | Method for identifying ways to improve performance in computer data storage systems |
WO1997017660A1 (en) * | 1995-11-03 | 1997-05-15 | Bull S.A. | Administrative interface for a database in a distributed computer environment |
Non-Patent Citations (2)
Title |
---|
"OS/2 DATABASE MANAGER DATABASE EVENT MONITOR", IBM TECHNICAL DISCLOSURE BULLETIN, vol. 34, no. 4A, 1 September 1991 (1991-09-01), New York, US, pages 150 - 151, XP000210859 * |
"Table Activity/ Reorg Indicator for the OS/2 EE Database Manager", IBM TECHNICAL DISCLOSURE BULLETIN., vol. 34, no. 10A, March 1992 (1992-03-01), NEW YORK US, pages 163 - 164, XP002093172 * |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9330108B2 (en) | 2013-09-30 | 2016-05-03 | International Business Machines Corporation | Multi-site heat map management |
CN105304140A (en) * | 2014-06-13 | 2016-02-03 | 北京安兔兔科技有限公司 | Method and apparatus for testing memory performance of electronic equipment |
CN105446848A (en) * | 2014-06-13 | 2016-03-30 | 北京安兔兔科技有限公司 | Electronic device data processing performance test method and device |
CN105304140B (en) * | 2014-06-13 | 2018-07-13 | 北京安兔兔科技有限公司 | The test method and device of the memory performance of electronic equipment |
Also Published As
Publication number | Publication date |
---|---|
JP2001524711A (en) | 2001-12-04 |
GB2346995A (en) | 2000-08-23 |
GB2346995B (en) | 2002-08-07 |
AU1527199A (en) | 1999-06-15 |
GB0012368D0 (en) | 2000-07-12 |
US6035306A (en) | 2000-03-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6035306A (en) | Method for improving performance of large databases | |
US20200142587A1 (en) | Automatic tiering of storage using dynamic grouping | |
US6760684B1 (en) | Method and mechanism for profiling a system | |
US9665630B1 (en) | Techniques for providing storage hints for use in connection with data movement optimizations | |
US6681309B2 (en) | Method and apparatus for measuring and optimizing spatial segmentation of electronic storage workloads | |
US7107273B2 (en) | Method and program of collecting performance data for storage network | |
US8498968B2 (en) | Method and apparatus for managing and archiving performance information relating to storage system | |
US7082441B1 (en) | Method and storage and manipulation of storage system metrics | |
KR100655358B1 (en) | Method for exchanging volumes in a disk array storage device | |
US20150379053A1 (en) | Managing database object placement on multiple storage devices | |
JP4896593B2 (en) | Performance monitoring method, computer and computer system | |
US8788527B1 (en) | Object-level database performance management | |
US6269410B1 (en) | Method and apparatus for using system traces to characterize workloads in a data storage system | |
US20050071596A1 (en) | Method, apparatus and program storage device for providing automatic performance optimization of virtualized storage allocation within a network of storage elements | |
JP2004538557A (en) | Systems and methods for monitoring computer applications and resource utilization | |
JP2001159989A (en) | Method for balancing load of disk array storage device | |
Thereska et al. | Informed data distribution selection in a self-predicting storage system | |
US6633884B2 (en) | System and method for analyzing a database for on-line reorganization | |
US11494081B2 (en) | System and method for using telemetry data to change operation of storage middleware client of a data center | |
Lau | Microsoft SQL server 7.0 performance tuning guide | |
Zibitsker et al. | How to apply modeling and optimization to select the appropriate cloud platform | |
Burleson | Creating a Self-Tuning Oracle Database: Automating Oracle9i Dynamic Sga Performance | |
Tool | System Performance Analysis | |
Draper et al. | Performance measurement in a university computing facility | |
Burleson et al. | Oracle Silver Bullets: Real-World Oracle Performance Secrets |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A1 Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CZ DE DK EE ES FI GB GE GH GM HR HU ID IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A1 Designated state(s): GH GM KE LS MW SD SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
DFPE | Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101) | ||
ENP | Entry into the national phase |
Ref country code: GB Ref document number: 200012368 Kind code of ref document: A Format of ref document f/p: F |
|
ENP | Entry into the national phase |
Ref country code: JP Ref document number: 2000 522523 Kind code of ref document: A Format of ref document f/p: F |
|
NENP | Non-entry into the national phase |
Ref country code: KR |
|
REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
NENP | Non-entry into the national phase |
Ref country code: CA |
|
122 | Ep: pct application non-entry in european phase |