tsingleeµÄÖíȦ

ÈËÁ¦:Ö»ÐèÒªÄãÔÚ¹¤×÷ÖпÏÂôÁ¦Æø¾Í×ã¹»ÁË;
ÈËÊÖ:ÔòÐèÒªÄãÊìϤÕÆÎÕ¹¤×÷£¬ÄÜÓ¦¸¶Í»·¢Ê¼þ;
È˲Å:ÔòÐèÒªÄãÍ·ÄÔÁé»î£¬Äܹ»ÔÚ¹¤×÷ÖÐÌá³ö´´ÔìÐԵķ½°¸;
ÈËÎï:¾ÍÐèÒª°ËÃæÁáç磬ÓÃ×Ô¼ºÌØÓеķ½Ê½Îª¹«Ë¾×ö³ö±È½Ï´óµÄ¹±Ï×.

1)prior·ÅÔÚ×Ó½Úµã¶Ë,Ôò±íʾɨÃèÊ÷ÊÇÒÔstart withÖ¸¶¨µÄ½Úµã×÷Ϊ¸ù½Úµã´ÓÉÏÍùÏÂɨÃè
.¿ÉÄܶÔÓ¦Ò»¸ö»ò¶à¸ö·ÖÖ§.
start with¿ÉÒÔÊ¡ÂÔ,Èç¹ûÊ¡ÂÔ,±íʾ¶ÔËùÓнڵ㶼µ±³É¸ù½Úµã·Ö±ð½øÐбéÀú.

2)prior·ÅÔÚ¸¸½Úµã¶Ë,Ôò±íʾɨÃèÊ÷ÊÇÒÔstart withÖ¸¶¨µÄ½Úµã×÷Ϊ×îµÍ²ã×Ó½Úµã,´ÓÏÂ
ÍùÉÏɨÃè.˳ÐòÊÇ×Ó½ÚµãÍù¸¸½ÚµãɨÃè,Ö±µ½¸ù½ÚµãΪֹ,ÕâÖÖÇé¿öÖ»Äܵõ½Ò»¸ö·ÖÖ§.
start with¿ÉÒÔÊ¡ÂÔ,Èç¹ûÊ¡ÂÔ,±íʾ¶ÔËùÓнڵ㶼µ±³É×îµÍ²ã×Ó½Úµã·Ö±ðÍù¸ù½Úµã·½Ïò±é
Àú.

The DBMS_OUTLN and DBMS_OUTLN_EDIT package provides procedures used for
managing stored outlines and their outline categories.
Users need the EXECUTE_CATALOG_ROLE role to execute DBMS_OUTLN, but public
has execute privileges on DBMS_OUTLN_EDIT. The DBMS_OUTLN_EDIT package is an
invoker's rights package.
Some of the useful DBMS_OUTLN and DBMS_OUTLN_EDIT procedures are:
¡ö CLEAR_USED - Clears specified outline
¡ö DROP_BY_CAT - Drops outlines that belong to a specified category
¡ö UPDATE_BY_CAT - Changes the category of outlines in one specified category to
a new specified category
¡ö EXACT_TEXT_SIGNATURES - Computes an outline signature according to an
exact text matching scheme
¡ö GENERATE_SIGNATURE - Generates a signature for the specified SQL text

catalog.sql - create data dictionary views.
cataudit.sql - data dictionary views for auditing. (catnoaud.sql will remove)
catblock.sql - create views of oracle locks
catclust.sql - create cluster database specific views definitions
catdbsyn.sql - catalog dba synonyms (dba_synonyms.sql)
catexp7.sql - create v7 style export/import views
catexp81.sql - create internal views for export/import utility
catio.sql - collect i/o per table/object stats by statistical sampling
catjava.sql - catalog scripts for java
catjobq.sql - catalog views for the job queue
catjvm.sql - create user|dba|all_java_* views
catldap.sql - catalog for ldap pl/sql api
catldr.sql - views for the direct path of the loader
catlsby.sql - logical standby tables and views
catpart.sql - creates data dictionary views for the partitioning table.
catoctk.sql - catalog - oracle cryptographic toolkit
catol.sql - outline views and synonyms
catparr.sql - parallel-server specific views, performance queries, etc
catpatch.sql - script to apply catalog patch set
catpitr.sql - tablespace point in time specific views
catplug.sql - pluggable tablespace check views
catprc.sql - creates data dictionary views for types, stored procedures, and
triggers.
catproc.sql - run all sql scripts for the procedural option
catqm.sql - creates the tables and views needed to run the xdb system
catqueue.sql - contains the queue dictionary information
catrep.sql - run all sql scripts for replication option
catrepc.sql - repcat tables, views, and sequences
catrepm.sql - catalog script for master replication packages
catrepr.sql - catalog replication remove
catreps.sql - installs pl/sql packages for snapshot functionality.
catrls.sql - catalog views for row level security
catrm.sql - packages for the dbms resource manager
catrpc.sql - rpc procedural option
catrule.sql - rules catalog creation
catsnap.sql - data dictionary views for snapshots
catsnmp.sql - creates an snmpagent role
catspace.sql - catalog space management (remove with catspaced.sql)
catsum.sql - data dictionary views for summary management
catsvrmg.sql - create the views and tables required for server manager
catblock.sql - creates the view blocking_locks, which shows which locks are
blocking the system
catnoaud.sql - removes the database audit trail created by cataudit.sql,
including its data and views
catnoprc.sql - removes data dictionary structures that were created by
catprc.sql

Question: I'm creating a new database manually and I don't know all of the data
dictionary scripts that I need to run. I know that I need to run catalog.sql
and catproc.sql, but what other data dictionary scripts are required?

Answer: The answer depends on what options that you are installing. Also note
that some scripts have sub-scripts, and catalog.sql calls other scripts within
the $ORACLE_HOME/rdbms/admin directory. Here are the sub-scripts within
catalog.sql:

* catadt.sql - Creates views that support user-defined types and object
components.
* cataudit.sql - Creates the sys.aud$ dictionary table,
* catexp.sql - Creates views for the import/export utilities
* catldr.sql - Creates views for the sql*loader tool
* catpart.sql - Creates views for partitioning oracle option,

Also, most DBA will run pupbld.sql. The Oracle docs note:

The PRODUCT_USER_PROFILE (PUP) table provides product-level security that
supplements the user-level security provided by the SQL GRANT and REVOKE
commands and user roles. To create the PUP table, log in to SQL*Plus as the
SYSTEM user and run PUPBLD.SQL which is located in the
ORACLE_HOMESQLPLUSADMIN directory with:

SQL> @%ORACLE_HOME%SQLPLUSADMINPUPBLD.SQL

SQL*Plus uses the PRODUCT_USER_PROFILE (PUP) table, a table in the SYSTEM
account, to provide product-level security that supplements the user-level
security provided by the SQL GRANT and REVOKE commands and user roles.

DBAs can use the PUP table to disable certain SQL and SQL*Plus commands in the
SQL*Plus environment on a per-user basis. SQL*Plus¡ªnot Oracle Database¡ª
enforces this security. DBAs can even restrict access to the GRANT, REVOKE, and
SET ROLE commands to control users' ability to change their database privileges.

SQL*Plus reads restrictions from the PUP table when a user logs in to SQL*Plus
and maintains those restrictions for the duration of the session. Changes to the
PUP table will only take effect the next time the affected users log in to
SQL*Plus.

When SYSTEM, SYS, or a user authenticating with SYSDBA or SYSOPER privileges
connects or logs in, SQL*Plus does not read the PUP table. Therefore, no
restrictions apply to these users.

The PUP table applies only to the local database. If accessing objects on a
remote database through a database link, the PUP table for the remote database
does not apply. The remote database cannot extract the username and password
from the database link in order to determine that user's profile and privileges.

Example : Setting Restrictions in the PUP Table
This is an example of how to insert a row into the PUP table to restrict the
user HR from using the SELECT statement:
1.
Log in as SYSTEM with the command
SQLPLUS SYSTEM
2.
Insert a row into the PUP table with the command:
INSERT INTO PRODUCT_USER_PROFILE
VALUES ('SQL*Plus', 'HR', 'SELECT', NULL, NULL, 'DISABLED', NULL, NULL);
3.
Connect as HR and try to SELECT something:
CONNECT HR
SELECT * FROM EMP_DETAILS_VIEW;
This command causes the following error message:
SP2-0544: Command SELECT disabled in Product User Profile
4.
To delete this row and remove the restriction from the user HR, CONNECT
again as SYSTEM and enter:
DELETE FROM PRODUCT_USER_PROFILE WHERE USERID = 'HR';

RMAN automatically backs up the current server parameter file in certain cases. The BACKUP
SPFILE command backs up the parameter file explicitly. For example:

BACKUP DEVICE TYPE sbt SPFILE;

The SPFILE that is backed up is the one currently in use by the instance. If the instance
is started with a client-side initialization parameter file, then RMAN does not back up
anything when this command is used.

You can back up the control file when the database is mounted or open. RMAN uses a
snapshot control file to ensure a read-consistent version. If CONFIGURE CONTROLFILE
AUTOBACKUP is ON (by default it is OFF), then RMAN automatically backs up the
control file and server parameter file after every backup and after database structural
changes. The control file autobackup contains metadata about the previous backup,
which is crucial for disaster recovery.

If the autobackup feature is not set, then you must manually back up the control file in
one of the following ways:
¡ö Run BACKUP CURRENT CONTROLFILE
¡ö Include a backup of the control file within any backup by using the INCLUDE
CURRENT CONTROLFILE option of the BACKUP command
¡ö Back up datafile 1, because RMAN automatically includes the control file and
SPFILE in backups of datafile 1

A manual backup of the control file is not the same as a control file autobackup. In
manual backups, only RMAN repository data for backups within the current RMAN
session is in the control file backup, and a manually backed-up control file cannot be
automatically restored.

You can backup one or more individual tablespaces with the BACKUP TABLESPACE
command. You can use this command when the database is mounted or open.

To back up a tablespace:

After starting RMAN, run the BACKUP TABLESPACE command at the RMAN prompt.
This example backs up the users and tools tablespaces to tape, using the
MAXSETSIZE parameter to specify that no backup set should be greater than 10 MB:

BACKUP DEVICE TYPE sbt MAXSETSIZE = 10M TABLESPACE users, tools;

Oracle translates the tablespace name internally into a list of datafiles.

You can perform whole database backups with the database mounted or open. To
perform a whole database backup, from the RMAN prompt, use the BACKUP
DATABASE command. The simplest form of the command requires no parameters, as
shown in this example:

RMAN> BACKUP DATABASE;
This example shows the procedure for taking a whole database backup to the default
destination:

RMAN> BACKUP DATABASE; # uses automatic channels to make backup
RMAN> SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT'; # switches logs and archives all logs

By archiving the logs immediately after the backup, you ensure that you have a full set
of archived logs through the time of the backup. This guarantees that you can perform
media recovery after restoring this backup.

Í·¶¥ÁÒÈÕ , µÈÁËÁ½¸öСʱ , Ä¿¶Ã°ÂÔË»ð¾æÊÖÔÚ°ë·ÖÖÓÄÚ±»¼ÓÓÍÉù¼°¹úÆì°ÂÔËÎå»·ÆìÍÌû , ÕæÊDz»ÈÝÒ×°¡.

RMAN can also store backup information a logical structure called a backup set. A
backup set contains the data from one or more datafiles, archived redo logs, or control
files or SPFILE. (Datafiles and archivelogs cannot be mixed together in the same
backup set.) You can also back up existing backup sets into another backup set.

A backup set consists of one or more files in an RMAN-specific format, known as
backup pieces. By default, a backup set consists of one backup piece. For example,
you can back up ten datafiles into a single backup set consisting of a single backup
piece (that is, one backup piece will be produced as output, the backup set consists of
the single file containing the backup piece, and the backup piece and the backup set
that contains it will be recorded in the RMAN repository). A file cannot be split across
backup sets.

When backing up datafiles to backup sets, RMAN is able to skip some datafile blocks
that do not currently contain data, reducing the size of backup sets and the time
required to create them. This behavior, known as unused block compression, means
that backups of datafiles as backup sets are generally smaller than image copy backups
and take less time to write. This behavior is fundamental to how RMAN writes datafiles
into backup pieces, and cannot be disabled.

An image copy is a bit-for-bit duplicate of a database file, identical to a copy made
with an operating system command. (RMAN-created image copies are, however,
recorded in the RMAN repository, unlike file copies created using operating
system-level commands.)

Image copy backups can only be created on disk. RMAN can create image copies of
datafiles and datafile copies, control files and control file copies, archived redo logs,
and backup pieces. RMAN creates image copies when the AS COPY option is used with
the BACKUP command.

RMAN's BACKUP command supports backing up the following types of files:
¡ö Database files, including datafiles, control files, and the server parameter file
(SPFILE)
¡ö Archived redo logs
¡ö Other backups created by RMAN, including such as datafile and control file image
copies, and backup sets containing SPFILEs, control files, datafiles and archived
logs
Although the database depends on other types of files for operation, such as network
configuration files, password files, and the contents of the Oracle home, these files
cannot be backed up with RMAN. Likewise, some features of Oracle, such as external
tables, may depend upon files other than the datafiles, control files, and redo log for
storing information. RMAN cannot back up these files. Use some non-RMAN backup
solution for any files not in the preceding list.

¹¦Äܱí->ͨѶ¼Ç¼->ÐÅÏ¢ÊÕÐÅÈË

Quotation marks can be nested in one of two ways. The first
method is to double the quotation marks in the nested string. For example:
NLS_DATE_FORMAT = '''Today is'' MM/DD/YYYY'
The second method is to alternate single and double quotation marks. For example:
NLS_DATE_FORMAT = '"Today is" MM/DD/YYYY'

Character Name Description # Number sign Comment ( Left parenthesis Start list of values ) Right parenthesis End list of values " Double quotation mark Start or end of quoted string ' Single quotation mark Start or end of quoted string = Equal sign Separator of keyword and values , Comma Separator of elements - Minus sign Precedes UNIX-style keywords Backslash Escape character

If a parameter value contains a special character, then the special character
must be preceded by a backslash or the entire parameter value must be enclosed
in quotation marks. For example, you can specify
special characters using either of the following:
DB_DOMAIN = 'JAPAN.ACME#.COM'
DB_DOMAIN = JAPAN.ACME#.COM

The following rules govern the specification of parameters in initialization parameter files:
¡ö An initialization parameter file should contain only parameters and comments. A
pound sign (#) starts a comment line. The rest of the line is ignored.
¡ö You can specify parameters in any order.
¡ö Case (upper or lower) in filenames is significant only if case is significant on the
host operating system.
¡ö To enter several parameters on one line, use spaces between parameter names and
values, as in the following example:
PROCESSES = 100 CPU_COUNT = 1 OPEN_CURSORS = 10
¡ö Some parameters, such as ROLLBACK_SEGMENTS, accept multiple value entries.
Enter multiple values enclosed in parentheses and separated by commas. For
example:
ROLLBACK_SEGMENTS = (SEG1, SEG2, SEG3, SEG4, SEG5)
Alternatively, you can enter multiple values without parentheses and commas. For
example:
ROLLBACK_SEGMENTS = SEG1 SEG2 SEG3 SEG4 SEG5
Either syntax is valid.
If you enter values for one parameter in multiple entries, then the entries must be
on consecutive lines. If they are not, then the first entry will not be processed
properly. For example, in the following entry the setting for SEG3 and SEG4 will
override the setting for SEG1 and SEG2:
ROLLBACK_SEGMENTS = SEG1 SEG2
OPEN_CURSORS = 10
ROLLBACK_SEGMENTS = SEG3 SEG4
¡ö A backslash (), also known as an escape character, indicates continuation of the
parameter specification. If a backslash continues a line, then the continued line
must have no leading spaces. For example:
ROLLBACK_SEGMENTS = (SEG1, SEG2,
SEG3, SEG4, SEG5)
¡ö You can use the IFILE initialization parameter to embed the contents of another
initialization parameter file into the current initialization parameter file.
¡ö Enclose in quotation marks any parameter values that contain spaces or tabs. You
can use either single or double quotation marks unless otherwise indicated. For
example:
NLS_TERRITORY = 'CZECH REPUBLIC'
¡ö Enclose in quotation marks any parameter value that contains a special character.

¡ö The ashrpt.sql SQL script generates an HTML or text report that displays ASH
information for a specified duration.
¡ö The ashrpti.sql SQL script generates an HTML or text report that displays
ASH information for a specified duration for a specified database and instance.

You can view AWR reports by running the following SQL scripts:
¡ö The awrrpt.sql SQL script generates an HTML or text report that displays
statistics for a range of snapshot Ids.
¡ö The awrrpti.sql SQL script generates an HTML or text report that displays
statistics for a range of snapshot Ids on a specified database and instance.
¡ö The awrsqrpt.sql SQL script generates an HTML or text report that displays
statistics of a particular SQL statement for a range of snapshot Ids. Run this report
to inspect or debug the performance of a SQL statement.
¡ö The awrsqrpi.sql SQL script generates an HTML or text report that displays
statistics of a particular SQL statement for a range of snapshot Ids on a specified
database and instance. Run this report to inspect or debug the performance of a
SQL statement on a specific database and instance.
¡ö The awrddrpt.sql SQL script generates an HTML or text report that compares
detailed performance attributes and configuration settings between two selected
time periods.
¡ö The awrddrpi.sql SQL script generates an HTML or text report that compares
detailed performance attributes and configuration settings between two selected
time periods on a specific database and instance.

Typically, you would view the AWR data through Oracle Enterprise Manager screens
or AWR reports. However, you can view the statistics with the following views:
¡ö V$ACTIVE_SESSION_HISTORY
This view displays active database session activity, sampled once every second.
¡ö V$ metric views provide metric data to track the performance of the system
The metric views are organized into various groups, such as event, event class,
system, session, service, file, and tablespace metrics. These groups are identified in
the V$METRICGROUP view.

¡ö DBA_HIST views
The DBA_HIST views contain historical data stored in the database. This group of
views includes:
¡ö DBA_HIST_ACTIVE_SESS_HISTORY displays the history of the contents of
the in-memory active session history for recent system activity.
¡ö DBA_HIST_BASELINE displays information about the baselines captured on
the system
¡ö DBA_HIST_DATABASE_INSTANCE displays information about the database
environment
¡ö DBA_HIST_SNAPSHOT displays information on snapshots in the system
¡ö DBA_HIST_SQL_PLAN displays the SQL execution plans
¡ö DBA_HIST_WR_CONTROL displays the settings for controlling AWR.

×ÀÃæ->ÓÒ¼ü->ÊôÐÔ->Íâ¹Û->¸ß¼¶£­>ÏîÄ¿Ñ¡Ôñ£¨´°¿Ú£©¡¢ÑÕÉ«1£¨L£©Ñ¡Ôñ£¨ÆäËü£©½«É«
µ÷¸ÄΪ£º85¡£±¥ºÍ¶È£º123¡£ÁÁ¶È£º205£­>Ìí¼Óµ½×Ô¶¨ÒåÑÕÉ«£­>ÔÚ×Ô¶¨ÒåÑÕÉ«Ñ¡¶¨µãÈ·
¶¨£­>È·¶¨.

ÕâÑùËùÓеÄÎĵµ¶¼²»ÔÙÊÇ´ÌÑ۵İ׵׺Ú×Ö£¬¶øÊǷdz£ÈáºÍµÄ¶¹É³ÂÌÉ«£¬Õâ¸öÉ«µ÷ÊÇÑÛ¿Æ
ר¼ÒÅäÖõģ¬³¤Ê±¼äʹÓûáºÜÓÐЧµÄ»º½âÑÛ¾¦Æ£Àͱ£»¤ÑÛ¾¦.

A baseline is created with the CREATE_BASELINE procedure. A baseline is simply
performance data for a set of snapshots that is preserved and used for comparisons
with other similar workload periods when performance problems occur. You can
review the existing snapshots in the DBA_HIST_SNAPSHOT view to determine the
range of snapshots that you want to use. For example:
BEGIN
DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE (start_snap_id => 270,
end_snap_id => 280, baseline_name => 'peak baseline',
dbid => 3310949047);
END;
/

The pair of snapshots associated with the baseline are retained until you explicitly
drop the baseline. You can drop a baseline with the DROP_BASELINE procedure. For
example:
BEGIN
DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE (baseline_name => 'peak baseline',
cascade => FALSE, dbid => 3310949047);
END;
/

In the example, peak baseline is the name of baseline and FALSE specifies that only
the baseline is dropped. TRUE specifies that drop operation should remove the pair of
snapshots associated with baseline along with the baseline.

For example:
BEGIN
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( retention => 43200,
interval => 30, topnsql => 100, dbid => 3310949047);
END;
/

setting affects how often in minutes that snapshots are automatically
generated. The RETENTION setting affects how long in minutes that snapshots are
stored in the workload repository. The TOPNSQL setting affects the number of Top SQL
to flush for each SQL criteria (Elapsed Time, CPU Time, Parse Calls, Shareable
Memory, and Version Count).

You can drop a range of snapshots using the DROP_SNAPSHOT_RANGE procedure. To
view a list of the snapshot Ids along with database Ids, check the
DBA_HIST_SNAPSHOT view. For example, you can drop the following range of snapshots:
BEGIN
DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE (low_snap_id => 22,
high_snap_id => 32, dbid => 3310949047);
END;
/

In the example, the range of snapshot Ids to drop is specified from 22 to 32. The
optional database identifier is 3310949047. If you do not specify a value for dbid,
the local database identifier is used as the default value.

Active Session History data (ASH) that belongs to the time period specified by the
snapshot range is also purged when the DROP_SNAPSHOT_RANGE procedure is called.

You can manually create snapshots with the CREATE_SNAPSHOT procedure if you
want to capture statistics at times different than those of the automatically generated
snapshots. For example:
BEGIN
DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ();
END;
/

In this example, a snapshot for the instance is created immediately with the flush level
specified to the default flush level of TYPICAL. You can view this snapshot in the
DBA_HIST_SNAPSHOT view.

Some pitfalls are discussed in the following sections:
¡ö Hit ratios
¡ö Wait events with timed statistics
¡ö Comparing Oracle statistics with other factors
¡ö Wait events without timed statistics
¡ö Idle wait events
¡ö Computed statistics

CPU : sar, vmstat, mpstat, iostat
Memory : sar, vmstat
Disk : sar, iostat
Network : netstat

Measure the normal performance of the I/O system; typical values for a single block
read range from 5 to 20 milliseconds, depending on the hardware used. If the
hardware shows response times much higher than the normal performance value, then
it is performing badly or is overworked. This is your bottleneck. If disk queues start to
exceed two, then the disk is a potential bottleneck of the system.

Õý³£µÄ´ÅÅ̶ÁÈ¡µ¥¸öÊý¾Ý¿éÔÚ5-20ºÁÃëÖ®¼ä.
Èç¹ûdisk queues³¬¹ý2¸ö,ÄÇô´ÅÅÌÓпÉÄܳÉΪϵͳµÄÆ¿¾±

Operating system statistics include the following:
¡ö CPU Statistics
¡ö Virtual Memory Statistics
¡ö Disk Statistics
¡ö Network Statistics

On an Oracle data server system, where there is generally only one application
running, the server runs database activity in user space. Activities required to service
database requests (such as scheduling, synchronization, I/O, memory management,
and process/thread creation and tear down) run in kernel mode. In a system where all
CPU is fully utilized, a healthy Oracle system runs between 65% and 95% in user
space.
The V$OSSTAT view captures machine level information in the database, making it
easier for you to determine if there are hardware level resource issues. The
V$SYSMETRIC_HISTORY view shows a one-hour history of the Host CPU Utilization
metric, a representation of percentage of CPU usage at each one-minute interval. The
V$SYS_TIME_MODEL view supplies statistics on the CPU usage by the Oracle
database. Using both sets of statistics enable you to determine whether the Oracle
database or other system activity is the cause of the CPU problems.

µ±cpuÈ«ÀûÓõÄʱºò,½¡¿µµÄOracleϵͳÓõ½Óû§¿Õ¼äµÄ65%-95%
V$SYSMETRIC_HISTORYÊÕ¼¯ÁËcpuÒ»¸öСʱµÄÀûÓÃÇé¿ö

¡ö 1 - User
¡ö 2 - Redo
¡ö 4 - Enqueue
¡ö 8 - Cache
¡ö 16 - OS
¡ö 32 - Real Application Clusters
¡ö 64 - SQL
¡ö 128 - Debug

²»Ã÷°×ÎÒ×Ô¼º»úÆ÷ÉÏ»¹ÓÐclassΪ40,72µÄÊÇʲôÒâ˼

The data present in ASH can be rolled up on various dimensions that it
captures, including the following:
¡ö SQL identifier of SQL statement
¡ö Object number, file number, and block number
¡ö Wait event identifier and parameters
¡ö Session identifier and session serial number
¡ö Module and action name
¡ö Client identifier of the session
¡ö Service hash identifier

»ð¾æ´«µÝ´Ó³¤É³ÊÐÔÀ´ÇøµÄ¶«·½ºì¹ã³¡³ö·¢Ïȵ½°®Ííͤ£¬ÔÙÓÉ°®Ííͤµ½ÔÀ´ÊéÔº£¬¾­Â´É½Â·
¿ÚÏò±±ÖÁÐÂÃñ·µ½ÐÂÃñ»á¹Ý£¬ÔÙÓÉÐÂÃñ»á¹Ýµ½Í¨³ÇÉÌÒµ¹ã³¡Ïò¶«¹ýéÙ×ÓÖÞ´óÇŵ½Æ½ºÍÌã¬ÔÙ
ÑØ»ÆÐË·Ïò±±µ½ÖÐɽͤ£¬ÔÙÏò¶«¾­²ÌïÉ·¡¢Ï洺·ÉÏÑؽ­·ç¹â´ø£¬µ½¿ª¸£Â·¿ÚÔÙÏò¶«¾­¿ª¸£
ËÂÏòÄÏÉÏܽÈØ·£¬ÖÁÓªÅÌ·¿ÚÏò¶«¾­ÇåË®ÌÁ·ÉÏ°Ëһ·£¬´©¹ý°Ëһ·ÔÙÏò¶«¾­Ô¶´ó·ÏòÄÏÉÏ
Íò¼ÒÀö·£¬ÑØÍò¼ÒÀöÖÁÀͶ¯¶«Â·ÏòÎ÷µ½¶«ÌÁ£¬ÔÙÓɶ«ÌÁÉÏÉØɽ·ÏòÄϾ­¹ýÖÐÄÏ´óѧÌúµÀѧԺ
¡¢Å®×Ó´óѧÏòÎ÷ÉÏÏ渮·£¬ÔÙÏò±±ÉÏܽÈØÄÏ·ÑØܽÈØÄÏ·¾­Ê¡Õþ¸®µ½ºî¼ÒÌÁ£¬ºî¼ÒÌÁÔÙÏòÎ÷
ÉÏÀͶ¯Î÷·µ½°×ɳ·£¬¾­°×ɳ¾®ÉÏÊéԺ·£¬ÊéԺ·Ïò±±¾­µÚһʦ·¶ÔÙÏòÎ÷ÉÏÀͶ¯Î÷·µ½Ñؽ­
·ç¹â´ø£¬Ïò±±¾­¶Å¸¦½­¸óÏò¶«ÉÏÈËÃñ·£¬ÔÙ¾­ÈËÃñ·ÏòÄÏÉϽ¨Ïæ·£¬ÖÁÌìÐĸóÏò¶«ÉϳÇÄÏ·
¡¢³ÇÄÏ·ÔÙÏòÄÏÉÏܽÈØ·×îºóµÖ´ïÖÕµãºØÁúÌåÓý³¡¶«¹ã³¡£¬È«³Ì52.7¹«Àï¡£

This statistics represents
the total time spent in database calls and is a indicator of the total instance workload.
It is calculated by aggregating the CPU and wait times of all sessions not waiting on
idle wait events (non-idle user sessions).

DB time is measured cumulatively from the time that the instance was started.
Because DB time it is calculated by combining the times from all non-idle user
sessions, it is possible that the DB time can exceed the actual time elapsed since the
instance started up. For example, a instance that has been running for 30 minutes
could have four active user sessions whose cumulative DB time is approximately 120
minutes.

¿É´ÓV$SESS_TIME_MODEL»òÕßV$SYS_TIME_MODEL¶¯Ì¬ÊÓͼÖлñµÃʱ¼äÀàÖ¸±êµÄͳ¼ÆÊý¾Ý.

V$SESS_TIME_MODEL displays the session-accumulated time for various operations.
The time reported is the total elapsed or CPU time (in microseconds). Any timed
operation will buffer at most 5 seconds of time data. Specifically, this means that if a
timed operation (such as SQL execution) takes a long period of time to perform, the
data published to this view is at most missing 5 seconds of the time accumulated for
the operation.

The time values are 8-byte integers and can therefore hold approximately 580,000
years of time before wrapping. Background process time is not included in a statistic
value unless the statistic is specifically for background processes.

To enable easier high-level analysis of the wait events, the events are grouped into
classes. The wait event classes include: Administrative, Application, Cluster, Commit,
Concurrency, Configuration, Idle, Network, Other, Scheduler, System I/O, and User
I/O.

The wait classes are based on a common solution that usually applies to fixing a
problem with the wait event. For example, exclusive TX locks are generally an
application level issue and HW locks are generally a configuration issue.
The following list includes common examples of the waits in some of the classes:
¡ö Application: locks waits caused by row level locking or explicit lock commands
¡ö Commit: waits for redo log write confirmation after a commit
¡ö Idle: wait events that signify the session is inactive, such as SQL*Net message
from client
¡ö Network: waits for data to be sent over the network
¡ö User I/O: wait for blocks to be read off a disk

¾Ý·ÖÎö,2007Äê,ÖйúÒƶ¯Óû§ÊýΪ38660Íò»§,ÌúͨÓй̶¨µç»°Óû§2079Íò»§ºÍ475Íò»¥ÁªÍøÓû§,ºÏ²¢ºóÓû§×ÜÊý³¬¹ý4.11ÒÚ.ÕâÊÇÐÂÒƶ¯µÄ¿Í»§×ÊÔ´.

2007Äê,ÖйúÁªÍ¨CDMAÓû§ÓÐ4192.6Íò»§,ÖйúµçÐŹ̶¨µç»°¼ÓСÁéͨÓû§¹²ÓÐ2.26ÒÚ»§.ºÏ²¢ºóÓû§×ÜÊý¿ÉÒÔ´ïµ½2.67ÒÚ»§.´ËÍâ,ÖйúµçÐÅ»¹ÓÐ3817Íò»§»¥ÁªÍø¿í´ø½ÓÈëÓû§,Óû§Êý³¬¹ý3¸öÒÚ.

2007 Äê,ÖйúÁªÍ¨GSMÓû§ÓÐ12056.4Íò»§,ÖйúÍøͨ¹Ì¶¨µç»°¼ÓСÁéͨÓû§ÓÐ11878Íò»§,µç»°Óû§×ÜÊý¿ÉÒÔ´ïµ½23934Íò»§,¼´Ô¼Îª2.39ÒÚÓû§.´ËÍâ,ÖйúÍøͨ»¹Óл¥ÁªÍø¿í´øÓû§2600¶àÍò,ºÏ²¢ºóÓû§Êý³¬¹ý2.6ÒÚ.

You can modify, drop columns from, or
rename a temporary table. However, for a temporary table you cannot:
¡ö Add columns of nested table type. You can add columns of other types.
¡ö Specify referential integrity (foreign key) constraints for an added or modified
column.
¡ö Specify the following clauses of the LOB_storage_clause for an added or
modified LOB column: TABLESPACE, storage_clause, logging_clause,
allocate_extent_clause, or deallocate_unused_clause.
¡ö Specify the physical_attributes_clause, nested_table_col_
properties, parallel_clause, allocate_extent_clause, deallocate_
unused_clause, or any of the index-organized table clauses.
¡ö Exchange partitions between a partition and a temporary table.
¡ö Specify the logging_clause.
¡ö Specify MOVE.

²ÎÔÄ

http://www.orafaq.com/node/1902

ÔÚ Windows XP ϵͳÏ£¬Çë°´ÒÔϲ½ÖèÔÚ¡°ÍøÂçÁ¬½Ó¡±ÖÐжÔØ NetWare ·þÎñ¡£
¿ØÖÆÃæ°å |ÍøÂçÁ¬½Ó |±¾µØÁ¬½Ó |ÊôÐÔ | Ñ¡ÖÐ ¡°NetWare ¿Í»§¶Ë·þÎñ¡± µã ¡°Ð¶ÔØ¡± ³öÏÖÌáʾ£º¡°È·ÊµÒªÐ¶ÔØ¿Í»§¶Ë·þÎñÂ𣿡±£¬µã ¡°ÊÇ¡± ³öÏÖÌáʾ£º¡°ÒªÊ¹ÐÂÉèÖÃÉúЧ£¬±ØÐë¹Ø±Õ²¢ÖØÆô¼ÆËã»ú£¬ÒªÁ¢¼´ÖØÆô¼ÆËã»úÂ𣿡±£¬µã ¡°·ñ¡± .

http://luckysea.itpub.net/post/5481/323246
cache buffers chainsµ±Ò»¸öÊý¾Ý¿é¶ÁÈësgaÇø£¬ÏàÓ¦µÄbuffer header»á±»·ÅÖõ½hashÁбíÉÏ,ÎÒÃdzÆÆäÕâhash chains,chainÔÚÖÐÎĵÄÒâΪÁ´Ìõ»ò´®µÄÒâ˼£¬±í´ï¾ÍÊǹØÁ¬ÐÔ.Èç¹ûÒ»¸ö½ø³ÌÏë·ÃÎÊ»òÐÞ¸Ähash chainÉϵÄblock,ËüÊ×ÏÈÒª»ñµÃ"cache buffers chains" latch¡£

cache buffers chains latchµÈ´ý¸ß´óÌåÓÐÁ½¸ö·½Ã棺

1¡¢Ð´µÄ±È½Ï²îµÄsql
cache buffers chains latchºÜ´ó³Ì¶ÈÓëÂß¼­¶ÁÓйأ¬ËùÒÔÒª¹Û×¢v$sqlÖÐBUFFER_GETS/EXECUTIONS´óµÄÓï¾ä¡£
ͬʱÿһ¸öÂß¼­¶ÁÐèÒªÒ»¸ölatch get ²Ù×÷¼°Ò»¸öcpu²Ù×÷£¬ÕâÑùµÄsqlÒ²»áºÜºÄcpu×ÊÔ´¡£

2¡¢ÈÈ¿é
¼´¶à¸ö½ø³Ì¶Áͬһ¸ö»ò¼¸¸öblockµÄ×´¿ö£¬ÕâÒª¿¼ÂÇÓ¦ÓõÄÉè¼ÆÁË£¬ÎªÊ²Ã´»á³öÏÖÕâÑùµÄÇé¿ö£¬¸ÄÉÆ¿ÉÒÔÕâÑù£º

ÁªºÏv$session_wait¼°x$bhÊÓͼÕÒµ½ÏàÓ¦µÄÈÈ¿é½ø³ÌÓÅ»¯
ʾÀýsql
´úÂë:--------------------------------------------------------------------------------
SELECT A.HLADDR, A.FILE#, A.DBABLK, A.TCH, A.OBJ, B.OBJECT_NAME
FROM X$BH A, DBA_OBJECTS B
WHERE (A.OBJ = B.OBJECT_ID OR A.OBJ = B.DATA_OBJECT_ID)
AND A.HLADDR = &P1RAW
UNION
SELECT HLADDR, FILE#, DBABLK, TCH, OBJ, NULL
FROM X$BH
WHERE OBJ IN (SELECT OBJ
FROM X$BH
WHERE HLADDR = &P1RAW
MINUS
SELECT OBJECT_ID
FROM DBA_OBJECTS
MINUS
SELECT DATA_OBJECT_ID FROM DBA_OBJECTS)
AND HLADDR = &P1RAW
ORDER BY 4;--------------------------------------------------------------------------------

¸Ä±äÈÈ¿éµÄ;¾¶¾ÍÊǾ¡Á¿ÈÃÒ»¸öblock´æÉÙһЩÊý¾Ý£¬±ÈÈç¼Ó´ópctfree²ÎÊý.ͬʱ»¯»¯Ó¦Ó÷ÖÉ¢ÈÈ¿éºÜÖØÒª¡£

cache buffers lru chain
ÕâÒ²ÊÇÒ»¸öÄÚ´æ½á¹¹£¬ÓÃÓÚ±êʶÄÄЩbuffer²Ù×÷״̬µÄ£¬±ÈÈçÄÄЩÊÇ"ÔàÊý¾Ý"ÐèÒªDBWn»Øдµ½Êý¾ÝÎļþ¡£¿ÉÒÔÊʵ±¼Ó´ó_DB_BLOCK_LRU_LATCHES¼°ÌáÉýDBWnµÄдËٶȵÃÒÔ½â¾ö¡£

cache buffers lru chain¶àÒ²ÊÇbad sqlÓï¾äµÄÒ»¸öÕ÷Õ×£¬±íÃ÷ÁËbuffer cache²Ù×÷ºÜƵ·±¡£±ÈÈç×öÈ«±íɨÃè»òÖظ´µÄɨÃèÒ»¸öÑ¡ÔñÐԺܲîµÄË÷Òý¶¼»áÔì³Écache buffers lru chainµÄ¾ºÕù¡£Í¨¹ýv$session_wait,v$session,v$sqltextÕÒµ½Ïà¹ØµÄÓï¾ä½øÐÐÓÅ»¯Ò²ºÜ±ØÒª¡£

¿ÉÒÔÔÚÏÂÁг¡ºÏÖÐʹÓãº
1. VALUES clause of INSERT statements
2. The SELECT list of a SELECT statement
3. The SET clause of an UPDATE statement

¶ø²»ÄÜÔÚÏÂÁг¡ºÏʹÓãº
¡ö A subquery
¡ö A view query or materialized view query
¡ö A SELECT statement with the DISTINCT operator
¡ö A SELECT statement with a GROUP BY or ORDER BY clause
¡ö A SELECT statement that is combined with another SELECT statement with the UNION, INTERSECT, or MINUS set operator
¡ö The WHERE clause of a SELECT statement
¡ö DEFAULT value of a column in a CREATE TABLE or ALTER TABLE statement
¡ö The condition of a CHECK constraint

¸ü¶àÏêϸÄÚÈÝÇë²ÎÔÄ:
http://chenzs19850728.blog.163.com/blog/static/762960920083710532829/

¸÷λ׼±¸ÏòÔÖÇø·îÏ×ÄúµÄ°®ÐĵÄÅóÓÑ,Çë²ÎÔÄ
http://news.xinhuanet.com/politics/2008-05/13/content_8158260.htm

×¢ÒâÌá·ÀÕ©Æ­¶ÌÐÅ.

×¼±¸ÎªÔÖÇøÈËÃñÏ×ѪµÄÅóÓѿɲÎÔÄ:

http://news.xinhuanet.com/health/2005-02/23/content_2609400.htm

»òÕßgoogleһϿ©.²»ÒªÃ¤Ä¿³å¶¯.

Çë²ÎÔÄ

http://www.yeeyan.com/articles/view/zww/7740

http://www.orafaq.com/wiki/DBMS_SCHEDULER

DBMS SCHEDULER is a more sophisticated job scheduler introduced in Oracle 10g. The older job scheduler, DBMS_JOB, is still available.
Contents
* 1 Create a job
* 2 Remove a job
* 3 Run a job now
* 4 Change job attributes
* 5 Monitoring jobs

Create a job

BEGIN
DBMS_SCHEDULER.CREATE_JOB (
job_name => 'my_java_job',
job_type => 'EXECUTABLE',
job_action => '/usr/bin/java myClass',
repeat_interval => 'FREQ=MINUTELY',
enabled => TRUE
);
END;
/

Remove a job

EXEC DBMS_SCHEDULER.DROP_JOB('my_java_job');

Run a job now

To force immediate job execution:

EXEC dbms_scheduler.run_job('myjob');

Change job attributes

Examples:

EXEC DBMS_SCHEDULER.SET_ATTRIBUTE('WEEKNIGHT_WINDOW', 'duration', '+000 06:00:00');

EXEC DBMS_SCHEDULER.SET_ATTRIBUTE('WEEKNIGHT_WINDOW', 'repeat_interval', 'freq=daily;byday=MON, TUE, WED, THU, FRI;byhour=0;byminute=0;bysecond=0');

Monitoring jobs

SELECT * FROM dba_scheduler_jobs WHERE job_name = 'MY_JAVA_JOB';
SELECT * FROM dba_scheduler_job_log WHERE job_name = 'MY_JAVA_JOB';

ͨ³£¶¼ÓÃLENGTH()»òÕßLENGTHB()º¯ÊýÀ´»ñÈ¡×ֶεij¤¶È,
µ«¶ÔLONGÁÐ×Ö¶ÎʹÓÃLENGTH()º¯ÊýµÄʱºò£¬Oracle½«¸ø³öORA-00932µÄ´íÎó¡£
¿ÉʹÓÃÈçÏ·½Ê½À´»ñÈ¡LONGÁÐ×ֶεij¤¶È:
1. CREATE TABLE T_LOB(NEW_REC CLOB);

2. INSERT INTO T_LOB (SELECT TO_LOB(<LONGÁÐ×Ö¶Î>) FROM <°üº¬LONGÁеÄÔ­±í>);
COMMIT;

3. SELECT dbms_lob.getlength(new_rec)
FROM t_lob ;

Ô­Îļû £ºhttp://www.dba-village.com/village/dvp_tips.TipDetails?TipIdA=5645

Æô¶¯µçÄÔ,´ò¿ªfirefox,ÊäÈëg.cn,È´·¢ÏÖ²»ÄÜÕý³£´ò¿ªÍøÒ³,×òÌì×ßµÄʱºò»¹ÊǺÜÕý³£°¡,
Õ¦»ØÊÂÄØ£¿
½èͬʵĵçÄÔgoogleÁËÒ»ÏÂ,ÍøÒ³http://support.microsoft.com/kb/316414¸ø³öÁ˽â¾ö°ì·¨¡£
жÔØzonealarm , ½«windows×Ô´ø·À»ðǽ¹Ø±Õ,ÖØÆôµçÄÔ . ok