Advanced Oracle: Opera Global Technical Services

Advanced Oracle
Prepared by: Shayne Capo

Senior Database Administrator
Opera Global Technical Services

Oracle
Architectural
Components
Architectural Components
There are several files, processes and memory
structures in an Oracle Server. Some of them are
used when processing a SQL statement (or
manipulating an application like Opera).
Others are used to improve the performance of the
database, ensure that the database can be recovered
in the event of a software or hardware error, or
perform other tasks necessary to maintain the
database.
The Oracle server consists of:
Oracle Instance
Oracle database
Oracle Server

Oracle instance
A combination of background processes and memory
structures that access an Oracle database
Instance must be started before accessing the
database
Every time started, a System Global Area (SGA) is
allocated and Oracle background processes are
started
Background processes perform functions on behalf of
the invoking process
They consolidate functions that would otherwise be
handled by multiple Oracle programs running for
each user
Always opens one and only one database
Oracle Instance
Oracle Database
The physical structure consists of 3 file types + other
file structures

Overview of Primary Components
System Global Area (SGA)
Shared Pool
Library Cache
Data Dictionary Cache
Database Buffer Cache
Redo Log Buffer Cache
Large Pool
Java Pool
Background Processes
DBWn, PMON, CKPT, LGWR, SMON
Program Global Area (PGA)


Oracle
Storage
Structures

Physical vs. Logical

Datafiles
A datafile is a physical structure
Can hold data for only one tablespace
Can resize dynamically
Space allocated upon creation
Opera database datafiles:
System01.dbf, sysaux01.dbf, tempseg01.dbf,
undotbs01.dbf, findata01.dbf, finindx01.dbf,
logdata01.dbf, logindx01.dbf, namedata01.dbf,
nameindx01.dbf, opera_data01.dbf,
opera_indx01.dbf, oxi_data01.dbf, oxi_indx01.dbf,
quickdata01.dbf, quickindx01.dbf, ratedata01.dbf,
rateindx01.dbf, resvdata01.dbf, resvindx01.dbf,
tools01.dbf
Tablespaces
Largest logical unit
Can reside in one or more datafiles
May contain one or more segments
Can be taken offline
Can be made readonly (SYSREAD)
OPERA database tablespaces:
system, sysaux, tempseg, undotbs, findata,
finindx, logdata, logindx, namedata, nameindx,
opera_data, opera_indx, oxi_data, oxi_indx,
quickdata, quickindx, ratedata, rateindx, resvdata,
resvindx, tools

Logical Overview
SEGMENTS
Second largest logical unit
Can belong to only one tablespace, but can reside in
multiple datafiles
Is made up of one or more extents
EXTENTS
Third largest logical unit
Can belong to only one segment and cannot spawn datafiles
Is made up of contiguous Oracle Blocks
When segments grow, new extents are added
BLOCKS
Smallest logical unit
Can belong to only one extent
Corresponds to one or more operating system blocks
DB_BLOCK_SIZE=8m in OPERA
Storage
Structures
In Depth

Storage Relationships

Types of Segments

Storage Clause Precedence

Extent Allocation/Deallocation

Block Contents
Header
Top of the block
Data block address
Table directory
Row directory
Transaction slots
Free Space
Middle of the block
Data
Bottom of the block
Automatic Space Management
Automatic segment-space management can only be
enabled at the tablespace level for locally managed
tablespaces:

CREATE TABLESPACE "OPERA_DATA" LOGGING DATAFILE
'G:\oracle\oradata\QA10\OPERA_DATA01.dbf' SIZE 512M
AUTOEXTEND ON NEXT 100M MAXSIZE 4096M,
'G:\oracle\oradata\QA10\OPERA_DATA02.dbf' SIZE 5M
AUTOEXTEND ON NEXT 100M MAXSIZE 4096M EXTENT
MANAGEMENT LOCAL UNIFORM SIZE 1M SEGMENT SPACE
MANAGEMENT AUTO ;
Storage Information
Information about storage can be obtained by
querying the following:

DBA_EXTENTS
DBA_SEGMENTS
DBA_DATA_FILES
DBA_FREE_SPACE

UNDO
Management

Managing UNDO Data
Automatic:
Introduced in 9i
Uses undo segments
System rollback segment
Cannot store any other objects
Extents are locally managed

Manual:
Only option for 8i
Uses rollback segments

Managing UNDO Data

Read Consistency

Transaction Rollback

Automatic UNDO Management
Configure parameters in the initialization file:

######################################
# System Managed Undo and Rollback Segments
######################################
undo_management=AUTO
undo_tablespace_UNDOTBS1
undo_retention=3600

Create at least one Undo tablespace
SYSTEM: Used in the SYSTEM tablespace
Non-SYSTEM: Used by other tablespaces
Auto: Uses UNDO tablespace
Manual: Uses Rollback Segments

UNDO Tablespaces
Only one Undo tablespace can be assigned to a
database at a time
Can have more than one undo tablespace, but only
one tablespace will be active
Switch active undo tablespace using the following
command:
ALTER SYSTEM SET UNDO_TABLESPACE=undotbs2;
RAC databases have one undo tablespace per
instance
UNDO Information
Information about undo segments can be
obtained by querying the following:

DBA_ROLLBACK_SEGS
V$ROLLNAME
V$ROLLSTAT
V$UNDOSTAT
V$TRANSACTION


Managing
Tables

Table Storage Options

Structure of a Row

Row Migration and Chaining

Creating Tables
CREATE TABLE employee(id NUMBER(8) NOT
NULL, last_name VARCHAR2(30))
TABLESPACE userdata;
CREATE TABLE emp AS SELECT * FROM
employee;

Creating Temporary Tables
Contain session private data held by the duration of
the transaction or session

CREATE GLOBAL TEMPORARY TABLE test
ON COMMIT PRESERVE|DELETE ROWS
AS SELECT * FROM name;

Moving Tables
Non-partitioned tables can be moved to another
tablespace with the following statement:

ALTER TABLE test MOVE TABLESPACE tools;

Useful for reorganizing and eliminating row migration
Truncating Tables
TRUNCATE TABLE test;

Deletes all rows
Truncate its indexes
Delete triggers are not fired
No undo is generated
A table referenced by a foreign key can not be
truncated

Dropping Tables
DROP TABLE test CASCADE CONSTRAINTS;

Extents released
CASCADE CONSTRAINTS option must be used if the
table is being referenced by a foreign key

Dropping Columns
ALTER TABLE test DROP COLUMN comments
CASCADE CONSTRAINTS CHECKPOINT 1000;

All data from the column is removed
CHECKPOINT command can be used to minimize
undo usage (expressed in number of rows)
Drop Column, UNUSED option
ALTER TABLE test SET UNUSED COLUMN comments
CASCADE CONSTRAINTS;

Data is not removed
Column becomes invisible
Unused columns can be dropped with the
following command:

ALTER TABLE test DROP UNUSED COLUMN
comments CHECKPOINT 1000;
Table Information
Information about tables can be obtained by

DBA_TABLES
DBA_OBJECTS
DBA_TAB_COLUMNS
DBA_TAB_COMMENTS
DBA_COL_COMMENTS

Managing
Indexes

Index Classifications
Logical
Single column or concatenated
Unique or nonunique
Function-based
Domain
Physical
Partitioned or nonpartitioned
B-tree (normal or reverse key)
Bitmap

B-Tree Index

Bitmap Index

B-Tree vs. Bitmap

Creating Indexes
Balance query and DML operations
Place in separate tablespace
Use uniform extent sizes
NOLOGGING option for large indexes
CREATE [BITMAP] INDEX index_name ON
table_name(column [ASC|DESC], [column])
[TABLESPACE tablespace_name] [NOSORT]
[storage_clause][LOGGING|NOLOGGING];

Managing Indexes
Moving the index to a new tablespace:
ALTER INDEX index_name REBUILD TABLESPACE
tablespace_name;
Rebuilding an index online:
ALTER INDEX index_name REBUILD ONLINE;
Reducing fragmentation:
ALTER INDEX index_name COALESCE;
Dropping an index:
DROP INDEX index_name;

Index Information
Information about indexes can be obtained by

DBA_INDEXES
DBA_IND_COLUMNS
DBA_IND_EXPRESSIONS

Data
Integrity

Data Integrity

Types of Constraints

Constraint States

EXCEPTIONS Table
Create the table running the utlexcpt1.sql script
Enable the constraint:
ALTER TABLE table_name ENABLE VALIDATE
CONSTRAINT constraint_name EXCEPTIONS INTO
system.exceptions;
Use a subquery to find the offending rows:
SELECT * FROM table_name WHERE ROWID IN
(SELECT ROWID FROM exceptions);
Modify the data with DML and re-enable the
constraint

Constraint Checking
Constraints can be set
up as immediate or
deferred
Deferred constraints
useful when both
parent and child keys
are entered at the same
time
ALTER SESSION SET
CONSTRAINTS to make
constraints immediate
or deferred

Foreign Key Guidelines

Constraint Information
Information about constraints can be obtained by

DBA_CONSTRAINTS
DBA_CONS_COLUMNS


Data
Dictionary


Redo Logs

Redo Logs
Record all changes made to data
Provides a means to recover the database
Can be organized into groups (multiplexing)
Minimum of two groups required

How Redo Logs Work
Written in a cyclic fashion
When one group is full LGWR moves to the next
group
Log switch and checkpoint occurs
Redo Log Information
Information about the redo logs can be obtained by

V$LOG
V$LOGFILE
V$LOGHIST
V$BACKUP_REDOLOG

Archived Redo Logs
Filled online redo logs can be archived
The two advantages are:
A backup of the datafiles + redo logs + archive
logs can be used to restore the database up to the
last committed transaction.
The backup can be made online.
When running in ARCHIVELOG mode a redo log file
cannot be overwritten until
Checkpoint has completed
Redo Log has been archived
By default the database is created in NOARCHIVELOG
mode
Archive Parameters
Archiving uses the ARCn background process to write
the redo logs to archive
initOPERA.ora archive parameters:
#log_archive_dest_1 =
"location=D:\oracle\admin\opera\archive
mandatory REOPEN=120"
#log_archive_format=ARC%S_%R.%T

Enable Archiving
Set initOPERA.ora archiving parameters
Mount the database in exclusive mode
D:\>sqlplus sys/opera10g as sysdba
SQL>Startup mount exclusive
Set the database in ARCHIVELOG mode
SQL>ALTER DATABASE ARCHIVELOG;
Startup the database
SQL>ALTER DATABASE OPEN;

Disable Archiving
Remove initOPERA.ora archiving parameters
Mount the database in exclusive mode
D:\>sqlplus sys/opera10g as sysdba
SQL>Startup mount exclusive
Set the database in NOARCHIVELOG mode
SQL>ALTER DATABASE NOARCHIVELOG;
Startup the database
SQL>ALTER DATABASE OPEN;

Tablespaces
And
Datafiles

Tablespaces and Datafiles
All objects in the database are stored logically in
TABLESPACES and physically in DATAFILES
TABLESPACES:
- Belong to only one Database
- Consist of one or more Datafiles
- Are divided in Segments, Extents and Blocks
DATAFILES
- Belong to only one Tablespace
- Physical files on the operating system
Locally Managed Tablespaces
Reduced contention on the data dictionary
No undo data generation when space allocation or
deallocation occurs
No coalescing required
UNIFORM sized extents are more reusable

CREATE TABLESPACE opera_data DATAFILE
g:\oracle\oradata\opera\opera_data01.dbf SIZE
512M AUTOEXTEND ON NEXT 100M MAXSIZE 2048M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M
SEGMENT SPACE MANAGEMENT AUTO;

Dictionary Managed Tablespaces
Extents managed in the data dictionary
Each segment may have a different storage clause
Coalescing required

CREATE TABLESPACE opera_data DATAFILE
g:\oracle\oradata\opera\opera_data01.dbf SIZE
512M EXTENT MANAGEMENT DICTIONARY DEFAULT
STORAGE (initial 1M NEXT 1M PCTINCREASE 0);
Temporary Tablespace
Used for sort operations
Cannot store any permanent objects
Locally managed extents
Tempfiles are always NOLOGGING

CREATE TEMPORARY TABLESPACE tempseg TEMPFILE
g:\oracle\oradata\opera\temp01.dbf SIZE 512M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 4M;

Default temporary tablespace define at database creation.
Can change the default temporary tablespace
ALTER DATABASE DEFAULT TEMPORARY TABLESPACE
tempseg;
Cannot be taken offline or dropped until a new temporary
tablespace is available
Read Only Tablespace
The following command makes a tablespace read
only:

ALTER TABLESPACE sys_read READ ONLY;

This causes a checkpoint
Data within the tablespace is available only for
Selects
Objects can be dropped
SYS_READ tablespace
Resizing Tablespaces
ALTER DATABASE
ALTER TABLESPACE
Can change the size of a tablespace by:
Alter the size of the datafile
Alter the datafile to have AUTOEXTEND turned on
Add a datafile
ALTER DATABASE DATAFILE
g:\oracle\oradata\opera\opera_data01.dbf RESIZE 4096m;
ALTER DATABASE DATAFILE
g:\oracle\oradata\opera\opera_data01.dbf AUTOEXTEND ON
NEXT 100m MAXSIZE 4096m;
ALTER TABLESPACE opera_data ADD DATAFILE
g:\oracle\oradata\opera\opera_data02.dbf size 2048m;

Moving or Renaming Datafiles
Shutdown the database
Physically on the OS move the datafile
Startup mount the database
Execute: ALTER DATABASE DATAFILE
g:\oracle\oradata\opera\opera_data01.dbf TO
h:\oracle\oradata\opera_data01.dbf;
Open the database
Tablespace Information
Information about tablespaces and datafiles can be
obtained in the following views:
Tablespaces
DBA_TABLESPACES
V$TABLESPACE
Datafiles
DBA_DATA_FILES
V$DATAFILE
Temporary files
DBA_TEMP_FILES
V$TEMPFILE

Networking

Oracle Net Services

Oracle 9i/10g Standard

Oracle RAC Option

Oracle Net Models
Locally Managed:
Files reside on each computer
listener.ora (server)
tnsnames.ora (client)
sqlnet.ora (server and client)

Centrally Managed:
LDAP directory server
ldap.ora (server and client)
Oracle Names server
names.ora (server and client)

Opera Local Naming

Establishing a Connection

Default Listener Parameters

Listener Contents
Listener contains the following entries:
Listeners name
Protocol addresses that it is accepting connection
requests on
Services it is listening for
Control parameters

Dynamic Service Registration
Initialization file contains the following entries:
SERVICE_NAMES
INSTANCE_NAME
LOCAL_LISTENER for non-default listener
REMOTE_LISTENER for RAC
LSNRCTL Utility
Listener Control Utility enables manupulation of the
listener through the command line
LSNRCTL> command_name
LSNRCTL> help
The following operations are available
An asterisk (*) denotes a modifier or extended command:

start stop status
services version reload
save_config trace change_password
quit exit set*
show*
Cost
Based
Optimizer

Query Optimization
A query is a non-procedural request of information
from the database. To process a query the kernel has
to characterize the retrieval strategy or formulate an
execution plan for fetching the candidate rows.
Typically, to execute a query, several execution plans
may be feasible. For example, tables participating in
a join could be processed in a number of different
orders depending on the join conditions and the join
methods implemented in the kernel. To choose
between alternative plans, the kernel must use some
realistic unit to measure the resources used by each
plan. It can then choose between competing plans on
the basis of costs and discard all except the one
which consumes the least.
Cost Based Optimizer
Oracle addresses query optimization by incorporating
a Cost Engine in the kernel to estimate and select
execution plans on the basis of costs.
Costs quantify the resource consumption of the
query.
Resources used by a query can be broken into three
principal parts
I/O cost
CPU Costs
Network Costs
Cost Based vs. Rule Based
The RBO has a set number of rules that SQL uses to
create an execution plan. For example: The RBO
designates whether an index is used/not used or
which table in the FROM clause should be the
primary table in a union. There are approximately 16
different rules from which the RBO can choose.
The CBO operates very differently from the RBO.
CBO uses actual table statistics to determine the best
execution plan. These statistics are gathered running
Gather Schema Statistics.
Analyze Objects
To enable costing of execution plans, detailed
statistical descriptions of the data relating to objects
in the query is required. The statistics are generated
by the ANALYZE facility.
There are two modes in which analyze may be
performed
COMPUTE
Compute scans each member of the object
ESTIMATE
Estimate mode looks at a sample of the total.
If there are no statistics, then the cost optimizer uses
hardcoded estimates or "guesses".
Gather Statistics Command
execute
dbms_stats.gather_database_stats(options=>'GATHE
R',estimate_percent=>dbms_stats.auto_sample_size,
method_opt=> 'FOR ALL COLUMNS SIZE AUTO',
cascade=>true);
GATHER_STATS_JOB
GATHER_STATS_JOB runs every night at midnight to
gather stale statistics
Verify the job by viewing the DBA_SCHEDULER_JOBS
view:
SELECT * FROM DBA_SCHEDULER_JOBS WHERE JOB_NAME
= 'GATHER_STATS_JOB';
Verify statistics in a schema are current by querying
LAST_ANALYZED column in dba_tables
select distinct(last_analyzed), owner from dba_tables;

Daylight
Savings
Time

DST Changes
The Energy Policy Act of 2005 was signed into law in
August 2005 to extend daylight saving time.

Beginning in 2007, daylight saving time in the U.S. will
begin on the second Sunday in March and end the first
Sunday in November rather than beginning on the first
Sunday in April and ending the last Sunday in October, as
it did in the past.

Under the new rules for 2007, DST will start on March 11,
2007 end on November 04, 2007. As a result the database
may report incorrect time zone data between 03/11/2007
04/01/2007 and between 10/28/2007 11/04/2007 (and
on different dates in subsequent years), unless the
required patches are applied.
What is the database timezone?
The database time zone is not as important as it sounds. First of
all it does not influence functions like sysdate, or systimestamp.
These function take their contents (date and time, and in the
case of systimestamp also time zone) completely from the OS
without any "Oracle" intervention.

The only function of the database time zone is that it functions
as a time zone in which the values of the "TIMESTAMP WITH
LOCAL TIME ZONE" (TSLTZ) datatype are normalized when they
are stored in the database.

However, these values are always converted into the session
time zone on insert and retrieval, so the actual setting of the
database time zone is more or less immaterial.
DST Patch
Who needs the DST patch?
ONLY locations where the database is not in the
same time zone as the hotel would be
affected. Mostly larger sites will be impacted, like
Candlewood datacenter. All sites just need to
make sure they have the OS patches/updates
applied.
The patch is applied to the database. It replaces two
files and requires the database to be restarted.
The patch is included in the Micros 403 database CD.

OPERA_SMT
Opera_SMT Command Line
SMT now supports command line
Command Line Functionality:
COMPILE to compile a schema
EXPORT to export a schema
IMPORT to import a schema - (requires SYS
password!)
EPATCH to run scripts against a schema
ANALYZE to analyze schema (Oracle 10g only) -
(requires SYS password!)
SMT Command Line Syntax
opera_smt /cmd=<command>[;<command options>]

<command> ::= ['COMPILE', 'EXPORT', 'IMPORT', 'SYNONYM',
'EPATCH', 'ANALYZE']

<command option> ::= <parameter>=<value>

<parameter> ::= ['USR','PWD','ODB','SYPWD','LOG','O9I','ZIP',
'TBS','OPU','OPP','OPD','OXU','OXP','OXD','SIL','SYN','DBG']
SMT Command Line Parameters
USR: Oracle UserName/SchemaName
PWD: Oracle Schema/User Password
ODP: Oracle Database Alias (as specified in TNSnames.ora)
SYPWD: SYS password
LOG: Log file name (always overwritten)
O9I: <Y, N> Use 9i export utility (only for import into 9i database)
ZIP: <Y, N> Create selfextracting Archive on export
TBS: Tablespace for imported schema
OPU: Opera Schema UserName (on Import if imported schema is
OXI/OXIHUB)
OPP: Opera Schema Password (on Import if imported schema is
OXI/OXIHUB)
OPD: Opera Schema Alias (on Import if imported schema is
OXI/OXIHUB)
SIL: <Y, N> Silent mode, no output on command window
DBG: <Y, N> Debug mode
SMT Command Line Examples
Compile Opera Schema
opera_smt
/cmd=compile;usr=opera;pwd=opera;odb=opera;log=smt_compil
e.log
Compile Opera Schema and refresh all synomyms
opera_smt
/cmd=compile;usr=opera;pwd=opera;odb=opera;log=smt_compil
e.log;syn=y
Export Opera Schema
opera_smt
/cmd=export;usr=opera;pwd=opera;odb=opera;zip=n;log=smt_ex
port.log /id:\export\opera\opera.dmp
Import Opera Schema
opera_smt
/cmd=import;usr=newopera;pwd=newopera;odb=opera;sypwd=*
*****;log=smt_import.log /id:\export\opera\opera.dmp

OPERA
Information

OPERA Commands
sqlplus opera/opera
Select * from installed_app;
select license_code from installed_app_licenses;
ALTER USER user_name IDENTIFIED BY
new_password;
DROP USER user_name [CASCADE];

OPERA File Locations
alertOPERA.log
G:\oracle\admin\opera\bdump
Arvhive logs
D:\oracle\admin\opera\archive
Control Files
D:\oracle\oradata\opera\control01.ctl
G:\oracle\oradata\opera\control02.ctl
OPERA datafiles
:\oracle\oradata\opera\<datafile_name>.dbf

Character Set
UTF8
Unicode
Varying width multibyte
US7ASCII characters (A-Z,a-Z,0-1 and ./?,*# etc..) are in
UTF8 1 byte, so for most West european languages the
impact is rather limited as only "special" characters like , ,
will use more bytes then in a 8 bit characterset.

Information about NLS settings can be obtained by
NLS_DATABASE_PARAMETERS
NLS_INSTANCE_PARAMETERS
NLS_SESSION_PARAMETERS
V$NLS_VALID_VALUES


Questions
Answers

Thank You

Advanced Oracle: Opera Global Technical Services

Uploaded by

Copyright:

Available Formats

Advanced Oracle: Opera Global Technical Services

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Advanced Oracle: Opera Global Technical Services

Uploaded by

Copyright:

Available Formats

Advanced Oracle

Prepared by: Shayne Capo

You might also like