4 to 7 Disk System

In the past, Oracle/ENOVIA Live Collaboration would have requested a 4-7 disk system with multiple drive spindles to optimize a large scale production database. Datafiles might have been configured as follows across multiple disks:

• Disk1: OS/Oracle/ENOVIA Live Collaboration installation--init files, system, temp, rollback datafiles
• Disk 2: Data datafiles, control file1, ENOVIA Live Collaboration user default tablespace datafile
• Disk 3: Index datafiles, control file 2
• Disk 4: Redo logs
• Disk 5: Mirror of redo logs, control file 3
• Disk 6: Archive log files, backup data disk
• Disk 7: Captured store data (ftp/nfs checked-in data referenced by Oracle metadata)

This is still a very valid and optimal solution, assuming a capable backup strategy. The problem is there is vulnerability to single disk failure. Note that the most important choice is to choose multiple disks and multiple spindles rather than one large disk.

This example shows:

• How to size the Oracle datafiles for projected ENOVIA Live Collaboration growth.
• How to optimize the disk layout for optimal Disk I/O performance and really how to minimize contention of hot disk read and write needs of the application's hot table indexes and tables.

This example assumes a projected migration of 2TB of attached File Store data that might translate down to upwards of 4,000,000 business objects in this database. This estimate presumes an average file size of 500K.

The average business object sizes range from 2k - 20k depending on six independent variables, but a good guide is to presume that production systems should plan for an average business object size of 10k.

This leads to the suggestion that the production system could be sized between 60-75g.

The Development System will not reach this size, but the database could be installed with these initial tablespace structures:

The Production and Test systems may need specialized growth tuning considerations including 'large and hot' object datafile isolation with further tablespaces:

Factor in an additional 10-15g for large Undo Tablespaces (imports and dataloads which tend to stretch Undo).

For Development, however, assume that additional large specialized tablespace structures for uniquely large and hot objects are not required. So plan for the initial set of application specific tablespaces and presume subsequent Oracle tuning will occur before any large scale dataloading.