OCA /OCP Oracle Database 11g A ll-in-One Exam Guide- P23 pot

OCA/OCP Oracle Database 11g All-in-One Exam Guide 176 • LOBSEGMENT, LOBINDEX, LOB PARTITION If a column is defined as a large object data type, then only a pointer is stored in the table itself: a pointer to an entry in a separate segment where the column data actually resides. LOBs can have indexes built on them for rapid access to data within the objects, and LOBs can also be partitioned. • CLUSTER A cluster is a segment that can contain several tables. In contrast with partitioning, which lets you spread one table across many segments, clustering lets you denormalize many tables into one segment. • NESTED TABLE If a column of a table is defined as a user-defined object type that itself has columns, then the column can be stored in its own segment, as a nested table. Every segment is comprised of one or more extents. When a segment is created, Oracle will allocate an initial extent to it in whatever tablespace is specified. Eventually, as data is entered, that extent will fill. Oracle will then allocate a second extent, in the same tablespace but not necessarily in the same datafile. If you know that a segment is going to need more space, you can manually allocate an extent. Figure 5-2 shows how to identify precisely the location of a segment. In the figure, the first command creates the table HR.NEWTAB, relying completely on defaults for the storage. Then a query against DBA_EXTENTS shows that the Figure 5-2 Determining the physical location of a segment’s extents Chapter 5: Oracle Storage 177 PART I segment consists of just one extent, extent number zero. This extent is in file number 4 and is 8 blocks long. The first of the 8 blocks is block number 1401. The size of the extent is 64KB, which shows that the block size is 8KB. The next command forces Oracle to allocate another extent to the segment, even though the first extent is not full. The next query shows that this new extent, number 1, is also in file number 4 and starts immediately after extent zero. Note that it is not clear from this example whether or not the tablespace consists of multiple datafiles, because the algorithm Oracle uses to work out where to assign the next extent does not simply use datafiles in turn. If the tablespace does consist of multiple datafiles, you can override Oracle’s choice with this syntax: ALTER TABLE tablename ALLOCATE EXTENT STORAGE (DATAFILE 'filename'); TIP Preallocating space by manually adding extents can deliver a performance benefit but is a huge amount of work. You will usually do it for only a few tables or indexes that have an exceptionally high growth rate, or perhaps before bulk loading operations. The last query in Figure 5-2 interrogates the view DBA_DATA_FILES to determine the name of the file in which the extents were allocated, and the name of the tablespace to which the datafile belongs. To identify the table’s tablespace, one could also query the DBA_SEGMENTS view. TIP You can query DBA_TABLES to find out in which tablespace a table resides, but this will only work for nonpartitioned tables—not for partitioned tables, where each partition is its own segment and can be in a different tablespace. Partitioning lets one table (stored as multiple segments) span tablespaces. An extent consists of a set of consecutively numbered blocks. Each block has a header area and a data area. The header is of variable size and grows downward from the top of the block. Among other things, it contains a row directory (that lists where in the block each row begins) and row locking information. The data area fills from the bottom up. Between the two there may (or may not) be an area of free space. Events that will cause a block’s header to grow include inserting and locking rows. The data area will initially be empty and will fill as rows are inserted (or index keys are inserted, in the case of a block of an index segment). The free space does get fragmented as rows are inserted, deleted, and updated (which may cause a row’s size to change), but that is of no significance because all this happens in memory, after the block has been copied into a buffer in the database buffer cache. The free space is coalesced into a contiguous area when necessary, and always before the DBWn writes the block back to its datafile. OCA/OCP Oracle Database 11g All-in-One Exam Guide 178 File Storage Technologies Datafiles can exist on four device types: local file systems, clustered file systems, raw devices, and ASM disk groups: • Files on a file local system These are the simplest datafiles; they exist as normal operating system files in a directory structure on disks directly accessible to the computer running the instance. On a PC running Windows or Linux, these could be internal IDE or SATA drives. On more sophisticated hardware, they would usually be SCSI disks, or external drives. • Files on a clustered file system A clustered file system is usually created on external disks, mounted concurrently on more than one computer. The clustered file system mediates access to the disks from processes running on all the computers in the cluster. Using clustered file systems is one way of implementing RAC: the database must reside on disks accessible to all the instances that are going to open it. Clustered file systems can be bought from operating system vendors, or Oracle Corporation’s OCFS (Oracle Clustered File System) is an excellent alternative. OCFS was first written for Linux and Windows (for which there were no proper clustered file systems) and bundled with database release 9i; with 10g it was ported to all the other mainstream operating systems. • Files on raw devices It is possible to create datafiles on disks with no file system at all. This is still supported but is really only a historical anomaly. In the bad old days before clustered file systems (or ASM) existed, raw devices were the only way to implement a Parallel Server database. Parallel Server itself was replaced with RAC in database release 9i. • Files on ASM devices ASM is Automatic Storage Management, a facility introduced with database release 10g. This is an alternative to file system– based datafile storage and covered in detail in Chapter 20. TIP Some people claim that raw devices give the best performance. With contemporary disk and file system technology, this is almost certainly not true. And even if it were true, they are so awkward to manage that no sane DBA wants to use them. ASM is tested in detail in the second OCP examination, but an understanding of what it can do is expected for the first examination. ASM is a logical volume manager provided by Oracle and bundled with the database. The general idea is that you take a bunch of raw disks, give them to Oracle, and let Oracle get on with it. Your system administrators need not worry about creating file systems at all. A logical volume manager provided by the operating system, or perhaps by a third party such as Veritas, will take a set of physical volumes and present them to the operating system as logical volumes. The physical volumes could be complete disks, or they could be partitions of disks. The logical volumes will look to application software like disks, Chapter 5: Oracle Storage 179 PART I but the underlying storage of any one logical volume might not be one physical volume but several. It is on these logical volumes that the file systems are then created. A logical volume can be much larger than any of the physical volumes of which it is composed. Furthermore, the logical volume can be created with characteristics that exploit the performance and safety potential of using multiple physical volumes. These characteristics are striping and mirroring of data. Striping data across multiple physical volumes gives huge performance gains. In principle, if a file is distributed across two disks, it should be possible to read it in half the time it would take if it were all on one disk. The performance will improve geometrically, in proportion to the number of disks assigned to the logical volume. Mirroring provides safety. If a logical volume consists of two or more physical volumes, then every operating system block written to one volume can be written simultaneously to the other volume. If one copy is damaged, the logical volume manager will read the other. If there are more than two physical volumes, a higher degree of mirroring becomes possible, providing fault tolerance in the event of multiple disk failures. Some operating systems (such as AIX) include a logical volume manager as standard; with other operating systems it is an optional (and usually chargeable) extra. Historically, some of the simpler operating systems (such as Windows and Linux) did not have much support for logical volume managers at all. If a logical volume manager is available, it may require considerable time and skill to set up optimally. ASM is a logical volume manager designed for Oracle database files. The definition of “database file” is broad. Apart from the true database files (controlfile, online redo log files, and datafiles), ASM can also store backup files, archived redo log files, and Data Pump files (all these files will be detailed in later chapters). It cannot be used for the Oracle Home, or for the alert log and trace files. EXAM TIP ASM can store only database files, not the binaries. The Oracle Home must always be on a conventional file system. Exercise 5-1: Investigate the Database’s Data Storage Structures In this exercise, you will run queries to document a database’s physical structure. The commands could be run interactively from SQL*Plus or Database Control, but it would make sense to save them as a script that (with suitable refinements for display format and for site specific customizations) can be run against any database as part of the regular reports on space usage. 1. Connect to the database as user SYSTEM. 2. Determine the name and size of the controlfile(s): select name,block_size*file_size_blks bytes from v$controlfile; 3. Determine the name and size of the online redo log file members: select member,bytes from v$log join v$logfile using (group#); OCA/OCP Oracle Database 11g All-in-One Exam Guide 180 4. Determine the name and size of the datafiles and the tempfiles: select name,bytes from v$datafile union all select name,bytes from v$tempfile; Create and Manage Tablespaces Tablespaces are repositories for schema data, including the data dictionary (which is the SYS schema). All databases must have a SYSTEM tablespace and a SYSAUX tablespace, and (for practical purposes) a temporary tablespace and an undo tablespace. These four will usually have been created when the database was created. Subsequently, the DBA may create many more tablespaces for user data, and possible additional tablespaces for undo and temporary data. Tablespace Creation To create a tablespace with Enterprise Manager Database Control, from the database home page take the Server tab and then the Tablespaces link in the Storage section. Figure 5-3 shows the result for the default database. Figure 5-3 The tablespaces in the default ORCL database Chapter 5: Oracle Storage 181 PART I There are six tablespaces shown in the figure. For each tablespace, identified by name, the window shows • Allocated size This is the current size of the datafile(s) assigned to the tablespace. It is based on the current size, not the maximum size to which it may be allowed to expand. • Space used This is the space occupied by segments in the tablespace that cannot be reclaimed. • Allocated space used (%) A graphical representation of the preceding two figures. • Allocated free space The space currently available within the tablespace. • Status A green tick indicates that the tablespace is online, and therefore that the objects within it should be accessible. An offline tablespace would be indicated with a red cross. • Datafiles The number of datafiles (or tempfiles for temporary tablespaces, if one is being precise) that make up the tablespace. • Type The type of objects that can be stored in the tablespace. A permanent tablespace stores regular schema objects, such as tables and indexes. A temporary tablespace stores only system-managed temporary segments, and an undo tablespace stores only system-managed undo segments. • Extent management The technique used for allocating extents to segments. LOCAL is the default and should always be used. • Segment management The technique used for locating blocks into which data insertions may be made. AUTO is the default and is recommended for all user data tablespaces. This information could be also be gleaned by querying the data dictionary views DBA_TABLESPACES, DBA_DATA_FILES, DBA_SEGMENTS, and DB_FREE_SPACE as in this example: SQL> select t.tablespace_name name, d.allocated, u.used, f.free, 2 t.status, d.cnt, contents, t.extent_management extman, 3 t.segment_space_management segman 4 from dba_tablespaces t, 5 (select sum(bytes) allocated, count(file_id) cnt from dba_data_files 6 where tablespace_name='EXAMPLE') d, 7 (select sum(bytes) free from dba_free_space 8 where tablespace_name='EXAMPLE') f, 9 (select sum(bytes) used from dba_segments 10 where tablespace_name='EXAMPLE') u 11 where t.tablespace_name='EXAMPLE'; NAME ALLOCATED USED FREE STATUS CNT CONTENTS EXTMAN SEGMAN EXAMPLE 104857600 81395712 23396352 ONLINE 1 PERMANENT LOCAL AUTO OCA/OCP Oracle Database 11g All-in-One Exam Guide 182 Click the CREATE button to create a tablespace. The Create Tablespace window prompts for a tablespace name, and the values for Extent Management, Type, and Status. In most circumstances, the defaults will be correct: Local, Permanent, and Read Write. Then the ADD button lets you specify one or more datafiles for the new tablespace. Each file must have a name and a size, and can optionally be set to autoextend up to a maximum file size. The autoextend facility will let Oracle increase the size of the datafile as necessary, which may avoid out-of-space errors. Figures 5-4 and 5-5 show the Database Control interfaces for creating a tablespace NEWTS with one datafile. Figure 5-4 The Create Tablespace window Chapter 5: Oracle Storage 183 PART I Clicking the sHOW SQL button would display this command (the line numbers have been added manually): 1 CREATE SMALLFILE TABLESPACE "NEWTS" 2 DATAFILE 'D:\APP\ORACLE\ORADATA\ORCL11G\newts01.dbf' 3 SIZE 100M AUTOEXTEND ON NEXT 10M MAXSIZE 200M 4 LOGGING 5 EXTENT MANAGEMENT LOCAL 6 SEGMENT SPACE MANAGEMENT AUTO 7 DEFAULT NOCOMPRESS; Figure 5-5 The Add Datafile window OCA/OCP Oracle Database 11g All-in-One Exam Guide 184 Consider this command line by line: Line 1 The tablespace is a SMALLFILE tablespace. This means that it can consist of many datafiles. The alternative is BIGFILE, in which case it would be impossible to add a second datafile later (though the first file could be resized.) The Use Bigfile Tablespace check box in Figure 5-4 controls this. Line 2 The datafile name and location. Line 3 The datafile will be created as 100MB but when full can automatically extend in 10MB increments to a maximum of 200MB. By default, automatic extension is not enabled. Line 4 All operations on segments in the tablespace will generate redo; this is the default. It is possible to disable redo generation for a very few operations (such as index generation). Line 5 The tablespace will use bitmaps for allocating extents; this is the default. Line 6 Segments in the tablespace will use bitmaps for tracking block usage; this is the default. Line 7 Segments in the tablespace will not be compressed; this is the default. Taking the Storage tab shown in Figure 5-4 gives access to options for extent management and compression, as shown in Figure 5-6. Figure 5-6 Further options for tablespace creation Chapter 5: Oracle Storage 185 PART I When using local extent management (as all tablespaces should), it is possible to enforce a rule that all extents in the tablespace should be the same size. This is discussed in the following section. If enabling compression, then it can be applied to data only when it is bulk-loaded, or as a part of all DML operations. If logging is disabled, this provides a default for the very few operations where redo generation can be disabled, such as index creation. Whatever setting is chosen, all DML operations will always generate redo. TIP All tablespaces should be locally managed. The older mechanism, known as dictionary managed, was far less efficient and is only supported (and only just) for backward compatibility. It has been possible to create locally managed tablespaces, and to convert dictionary-managed tablespaces to locally managed, since release 8i. A typical tablespace creation statement as executed from the SQL*Plus command line is shown in Figure 5-7, with a query confirming the result. The tablespace STORETABS consists of two datafiles, neither of which will autoextend. The only deviation from defaults has been to specify a uniform extent size of 5MB. The first query in the figure shows that the tablespace is not a bigfile tablespace—if it were, it would not have been possible to define two datafiles. The second query in the figure investigates the TEMP tablespace, used by the database for storing temporary objects. It is important to note that temporary tablespaces use tempfiles, not datafiles. Tempfiles are listed in the views V$TEMPFILE Figure 5-7 Tablespace creation and verification with SQL*Plus . v$tempfile; Create and Manage Tablespaces Tablespaces are repositories for schema data, including the data dictionary (which is the SYS schema). All databases must have a SYSTEM tablespace and a SYSAUX tablespace,. tablespaces for user data, and possible additional tablespaces for undo and temporary data. Tablespace Creation To create a tablespace with Enterprise Manager Database Control, from the database. Parallel Server database. Parallel Server itself was replaced with RAC in database release 9i. • Files on ASM devices ASM is Automatic Storage Management, a facility introduced with database