what next ? / 1 what’s next in database ? databases are expected to be –reliable –accurate...

What Next ? / 1

What’s Next in Database ?What’s Next in Database ?

Databases are expected to be

– Reliable– Accurate– Available– Flexible

Flexible invariably means ‘able to accommodate new demands’

What Next ? / 2

Current PositionCurrent Position

What has been happening, what will likely happen, in the land of databases ?

1. There is no sign of the demand for managed data systems to be slowing

2. Large databases are now ‘normal’

3. Centralised databases are being replaced (integrated ?) in distributed, networked systems

4. More changes are expected as Web services use XML (and other software) to speed data and analyses and accesses on/accessible on the Internet.

What Next ? / 3

Changes NoticedChanges Noticed

Database technology has caused, or has made possible, much change in Information Systems

Database technology has had to adapt to changes in IT such as client/server and the Internet

There have been solutions developed for OLTP and Decision Support. (multidimensional processing and visualisation - ‘cube’)

Number of users, volumes of ‘data’, speed of processing/communications, scaling are aspects which will not go away however

What Next ? / 4

Problems ?Problems ?

Current Concerns:

The ability and the actuality of the integration of all of the Information Assets of Companies, Organisations, Enterprises

This is for ‘access purposes’ and also for ‘discovery purposes’ - such as data mining, and Intelligent Information

What about the ‘types of data’ ?

Documents, spreadsheets, voice, video now are recognised as ‘data sources’

What Next ? / 5

RequirementsRequirements

Businesses seem to require integration - and lots of it.

The ability to bring together cross Departmental information

The ability to bring together Information about Businesses

XML seems to offer a strong capability of handing ‘data in all of its known forms’

What Next ? / 6

Moving TargetMoving Target

Relational Database effectively reduced the ‘backlog’ of application development - that was 20 to 25 years ago.

The target has been moved (or is that repositioned ?)

Business requirements need fast (or even faster) response

Web services and other associated initiatives seem to offer the leverage required to capture and describe assets and to move at a faster rate to introduce applications

What Next ? / 7

Some Interesting AspectsSome Interesting Aspects

An interesting about-face:

Work has been done on ‘unconventional’ concurrency models - and Oracle has implemented a non-locking based model (perhaps a cache based database ?).

Could all decision support systems work on the same ‘truth’ data ?

Could management be automated, and at the same time provide high availability ?

The amount of human effort in design, architecture and to install systems - could this be ‘automated’ ?

What Next ? / 8

Emerging FeaturesEmerging Features

Systems are (slowly) becoming able – to automate those aspects which can be automated– to simplify those things which cannot be automated– to enable applications such as recovery - on their own

DBMS designers are building features which use the intelligence of tools rather than that of humans

Performance management of large multi user databases is a high consumer of human intelligence and effort (e.g. SAP, which has about 20,000 tables and some 35,000 indexes)

What Next ? / 9

IBM’s DirectionIBM’s Direction

IBM have an ongoing learning optimisation research project (eLiza) which is aimed at

– automating adjustments to the configuration parameters

– memory space allotment– schemas (and more importantly changes to

schemas as these do change over time)

What Next ? / 10

Immediate DataImmediate Data

The ‘Business Intelligence industry (BI) is fixated about ‘real time’ - users demanding data very close to the time data was captured or updated

A Teradata user (in America) inputs data from point-of -sale systems in a multi retail store environment

Each cashier’s data is ‘pattern matched’ to assess if fraud is taking place. If the ‘solution’ is a ‘yes’, security staff are paged and the cashier is taken out of action (probably not a notable application, but when you consider that something like 3.8 billion dollars is estimated to ‘go missing’ each year in retail sales, this might alter perspective of the application)

What Next ? / 11

Immediate Reaction ?Immediate Reaction ?

Relational databases use triggers which are used to control active events or to alert management (the example of the payroll application)

However, there is much more data stored in non-relational applications than there is in RDBMs

The majority of stored information is (still) in non-relational applications (estimated 75 to 80% of management information)

What Next ? / 12

Accessing Non-Structured DataAccessing Non-Structured Data

As Enterprise Application Integration evolves, there could be the opportunity of message intercept messages to and from application systems - the current term is ‘sniffer’

This could enhance or extend EAI - an example would be a link with a publish-and-subscribe mechanism to provide event-driven information to users (real estate, stock exchange, international currency, mergers ..

What Next ? / 13

Real TimeReal Time

Real time total data access will require the ability to utilise ‘federated’ databases - different Operating Systems, hardware, communication systems and different DBMSs.

Virtual federated databases could provide a ‘common intelligence’ to all user systems

The back end ? This is where things are becoming interesting :-

It is likely that that ‘rich’ (= multidimensional and multi datatyped) query systems, together with parallelisation and integration with relational operators will allow people on the ‘front end’ to work with standard SQL

What Next ? / 14

Software SupportSoftware Support

Web services are a major roleplayer

Others ? – Consolidation– Centralisation– Globalisation

which will assist people managing their systems.

Information will be in one place, or in a fewer number of places.

What Next ? / 15

SQL + XMLSQL + XML

Federated systems are one choice

Consolidation and centralisation is another

The integration of SQL and XML (and XSML) and the concept of a single repository which can store both relational and XML data will offer much power to business

Data mining, decision support, modelling will be based on XML data - Web services will be critical

What Next ? / 16

Mass IntegrationMass Integration

There is another highly probable opportunity– the integration of data mining, – ETL (meaning extract, transform and load, as in data

warehousing)– OLAP (on line analytical processing)

into a database engine

This will shorten the information cycle - we will be (almost) in real-time

What Next ? / 17

More Mass IntegrationMore Mass Integration

There is another style of ‘Integration’ and this is the creation of logical integration products

These are called ‘mediators’

For instance ‘who is on what plane (or is booked on what plane) going from America to New Zealand from <nominated dates>

Or, who has been qualified to fly, or is enrolled in a flying program, and is NOT sponsored by a recognised airline company

Are there any Security or Privacy issues here ?

What Next ? / 18

Whither SQLWhither SQL

Will this environment make SQL ‘out of touch’ ?

The general feeling is NO

SQL will adapt - there is research into semi-structured data

XML is a current example.

Work is in hand to optimise SQL based queries on XML

The ETL (extract, transform, load) is likely to become an ELT - extract, load, transform operation

What Next ? / 19

SQL ExtensionsSQL Extensions

Advanced analytic functions such as data mining are going to be available in SQL - the extended functions of SQL99 support this extension

SQL looks like having the capabilities to handle multimedia data, analytics and also to express business functions

The integration of SQL and XML, enterprise portals, and Internet applications are drawing the 2 worlds of structured and non-structured data together

which will allow SQL to handle both forms simultaneously

What Next ? / 20

Emerging StandardsEmerging Standards

SQL-X is an emerging standard for using SQL together with XML syntax to navigate XML documents and to express XML-relayed queries

SQL offers a much simpler view of data

The language is about value-based relationships

Data (in many cases) is maintained without value-based relationships

What Next ? / 21

Back To BusinessBack To Business

Some of the previous probably sounded very ‘focussed’.

The big question is this -– Will Web services ‘solve’ business problems

Which could lead to this : ‘Should software developers need to understand Web services’ role in business ?

A software developer’s task is to provide users with – reliable and scalable solutions

which will achieve business goals - which are ????

What Next ? / 22

Practical IssuesPractical Issues

Business constraints:

1. Provision of goods and services at competitive prices

2. Competition on a global basis

3. Expected short (or shortest) delivery time

Which leads to the conclusion that Companies need an efficient application development infrastructure (but hasn’t this been always so ?)

And what type/size/turnover business has these worries ?

What Next ? / 23

Practical WorriesPractical Worries

There are 2 Integration challenges:

1. Internal applications which cannot (or do not) communicate with each other

2. External applications which cannot (or do not) communicate with a Company’s existing ones

Internal applications are mostly developed in isolation (where is the Company’s IT strategy ?) and use different technologies and different programming languages.

As well, there are the ‘legacy’ systems which are still in use

What Next ? / 24

Practical ProblemsPractical Problems

Designers/Developers spend much time and effort creating ‘middleware’ for interface capability and in tuning systems.

The interfacing between different systems is necessary as the business processes and requirements change

Another dimension is the need to communicate with outside (external) systems - which means more interfacing and interfaces

What Next ? / 25


Companies are known to concentrate on ‘core business’

Nonstrategic processing tends to be to external suppliers (have you met this ?)

The result is that Companies need an efficient infrastructure for exchanging data with external bodies such as

– external suppliers– resellers– business partners

Building application interfaces for each external supplier is costly and may be not acceptable to the supplier (who may have a very similar scenario)

What Next ? / 26


Application integration can occur at these different levels

– Database - Oracle, DB2, SQLServer, Hitachi– the messaging level– distribution application level (e.g. Java2 platform)

However, these technologies bridge the gap between applications but not necessarily across networks

What Next ? / 27


Web services which are built on existing standard Internet protocols (XML, HTML) are designed for applications

Web services are seen as being able to reduce costs and to be a material advantage in the development and implementation of new business models

Web services seem to have the potential or common infrastructure for constructing integrated ‘solutions’ which have the capability of ‘centralising’ data from with a Company as well as integrating data from suppliers and trading partners

What Next ? / 28


The Web is not the first attempt to do this

Electronic Data Interchange (EDI) still exists and is alive and well in specialised environments. It has been with us for about 25 years.

EDI requires a Value Added Network to exchange business data between multiple companies - cost and flexibility are the adverse elements

Web services use the Internet - with the advantage that the ‘cryptic’ formats are ‘exchanged’ to XML-based industry standards

What Next ? / 29


Web services abstract

the message content

transportation

implementation language

and standardises data exchange using Simple Object Access Protocol (better known as SOAP)

Technically, businesses use Web services to interact directly with their suppliers and other stakeholders which goes a long way in avoiding third party involvement and costs - but it’s not really that easy is it ?

Or is it ?

What Next ? / 30

Web ServicesWeb Services

The definition of application interface standards is (or can be) implemented with Web Services Definition Language (WSDL)

Web services can be provided to other businesses, or

they can be published to a UDDI registry (Universal, Description, Discovery and Integration)

This avoids the need for developers to use specific message, data (in all its forms) or application structures to build new solutions (or just to build solutions).

What Next ? / 31

Another Major AdvantageAnother Major Advantage

The web service XML offers a major integration benefit

Metadata management - the management of data about data (commonly called Intelligence)

XML provides ‘built-in’ metadata to describe its contents

This is expected to be critical to successful application integration as has been the case with data warehousing

systems

What Next ? / 32

New Models ?New Models ?

Consider this : (it’s a short form of a Case Study)

There is a group of independent DVD rental companies which want to share some services and resources.

Why would they want to do this ? - Any suggestions ?

Each store uses its own POS and EFTPOS systems which have been constructed over a number of years with the characteristics which you have already seen - various technologies, hardware, O/S and programming languages

What Next ? / 33

A DVD Case StudyA DVD Case Study

The objectives are to

1. Reduce costs by decreasing the effort of repetitive of DVD information of new releases (which come from where ?)

2. Be able to access more detailed, complete movie descriptions

3. Be able to suggest titles to customers based on rental history and preferences

4. Develop a customer service so that ‘requests’ can be made and the customers informed (by email ?) when the title is available

What Next ? / 34


5. Certify or validate details of new or existing customers (what is involved here ? Security and privacy perhaps ?)

6. Minimise revenue loss from damaged property or late returns

The aim is to build a multiuser accessible service.

What Next ? / 35


What are the benefits ?

1. Central source for Customer validation and risk

2. Less cost in maintaining titles (centralised)

3. Reduction in cost ad time required in integrating new services into existing DVD applications

4. Reduce development costs

How this can be achieved :-

The Web service interface (WSDL) automatically generates the proxy classes to integrate with existing applications

The integration effort is a few lines of Java code which create a Web services proxy object, and invocation of service

What Next ? / 36


The Working Outline:

1. A business registration Web service provides business registration. Non-registers stores cannot access anything until registrations is completed.

2. A customer registration service lets a registered business register its customers on the Central register

3. A customer fault registration service allows stores to enter details of ‘uncooperative’ customers - with the obvious ability to be wary before offering a candidate customer a registration

What Next ? / 37


4. Any of the participating stores can query a customer’s list of previous rentals titles to assist with ‘recommendations’

5. A customer ‘request’ allows the registered business to add the titles of DVD’s for those customers interested. AS a side effect this list can also be a guide to the stores about the demand for particular DVD’s - and possibly alter holdings

6. Title or customer searches can be made

Now for the BIG question = do you consider that this is a winner ?

What Next ? / 38


You’re in luck - you have won a prize

And the prize is a quick runaround of the processes involved.

When a registered business requests a service, a method within a generated Java proxy class is called.

As an example, this proxy class can be WebSphere Studio Application Developer. This would be based on WSDL (web services definition language)

The request would be encoded using standard SOAP XML-based message headers

What Next ? / 39


The Web service request is started from a servlet which executes within a Web container using WebSphere Application Server. A second WebSphere Application Server decodes the request and performs the required action.

There are other features such as an XML Extender which assists in the Customer Infringement search.

Another one is a Net Search Extender which assists in the title search. This software allows for fast in-memory searches especially helpful with text searching

What Next ? / 40

AcknowledgementsAcknowledgements

Stephen Brobst - Chief Technology Officer, NCR Teradata

Donald J. Haderle - V.P. Database Technology, IBM

Ken Jacobs - V.P. Product Strategy, Oracle Server Technologies.

Jeffrey Ullman - Professor of Computer Science, Stamford University

Grant Hutchison - Leader DB2/WebSphere, IBM Toronto Lab.

What Next ? / 41

Layouts and ScriptsLayouts and Scripts

In this session, we will be looking at a number of different physical layouts

The physical layout very much influences– How much data a database can hold– How many users– How many concurrent processes can run– Recovery capability– Performance– Nature of Database Administration– Cost– Expansion

What Next ? / 42

Oracle ArchitectureOracle Architecture

Oracle8 (and 8i) is an object-relational database management system. It contains the capabilities of relational and object-oriented database systems

It is a database server for many types of business applications including

– On Line Transaction Processing (OLTP)

– Decision Support Systems

– Data Warehousing

What Next ? / 43


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

What Next ? / 44


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

What Next ? / 45


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

What Next ? / 46


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

What Next ? / 47


(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)

What Next ? / 48


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

What Next ? / 49


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 and 50 is ‘normal’

In production, Temp will be used by large sorts

Tools will be used rarely in production - as will the Tools_2 tablespace

What Next ? / 50


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)

What Next ? / 51


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

What Next ? / 52


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 spaces (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).

What Next ? / 53


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

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.

What Next ? / 54


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

What Next ? / 55


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

What Next ? / 56


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

What Next ? / 57


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

What Next ? / 58


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.

What Next ? / 59


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

(what about Oracle’s philosophy of not implementing a lock-based model)

What Next ? / 60


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

What Next ? / 61


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

What Next ? / 62


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

What Next ? / 63


What are some recoverability issues ?

All critical database files should be placed on mirrored drives, and the database run in ARCHIVELOG mode

The online redo 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

What Next ? / 64


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

What Next ? / 65


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

What Next ? / 66


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

What Next ? / 67


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 !)

What Next ? / 68


So, with that optimistic outlook let’s proceed

Case 1 - The Optimum Physical LayoutDisk 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

What Next ? / 69

Hardware ConfigurationsHardware 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

What Next ? / 70


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

What Next ? / 71


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

What Next ? / 72


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 ?)

What Next ? / 73


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)

What Next ? / 74


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

What Next ? / 75


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 ?)

What Next ? / 76


The ‘new’ solution -

Disk Contents

1 Oracle software2 SYSTEM tablespace, Control file 13 RBS, RBS_2 tablespaces, Control file 24 DATA tablespace, Control file 35 INDEXES tablespaces6 TEMP, TEMP_USER tablespaces 12 disks7 TOOLS, INDEXES_2 tablespaces8 OnLine Redo Logs 1, 2 and 39 Application software10 DATA_211 Archived redo log destination disk12 Export dump file destination disk

What Next ? / 77


Notice that the Control Files have been moved to Disks 3, 4 and 5

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.

What Next ? / 78


– 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

What Next ? / 79


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

What Next ? / 80


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.

What Next ? / 81


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 dumpfile destination disk

9 40+ Application software, archived redo log destination disk