Database Reference
In-Depth Information
Availability
Failure of a smaller component or subcomponent is acceptable in most cases compared to failure of the entire system.
When a service fails, recovery of resources is much faster and independent because only a subset of functional users
are affected, and this prevents restarting of the entire application stack. When several services fail, recovery can also
happen in parallel. When the failed instances are brought online, the services that are not running (services that are
not configured for failover) start immediately, and the services that failed over can be restored/relocated back to their
original instance.
Performance
Prior to Oracle Database 10g, performance tuning was based on the statistics collected either at the system level or at
the session level. This means that irrespective of the number of applications running against a given database, there
was no instrumentation to provide any performance metric at the application or component level. With services
and the enhancements to the database, performance metrics can now be collected at a service level, meaning more
finite component-level troubleshooting. By grouping sessions performing similar kinds of activity on the database
to connect using the same service name, they can be offered on a subset of instances, which helps limit the amount
of cache transfers among instances. When services are configured to access only a single instance, this provides
performance benefits by reducing block transfers and allowing object affinity to take place.
Services offer another level of troubleshooting the system when analyzing performance statistics. Apart from
looking at statistics at the session level (
V$SESSSTAT
) and or the system level (
V$SYSSTAT
), using services provides
an opportunity to measure the performance and metrics of a group of sessions connecting using the same service
(
V$SERVICE_STATS
and
V$SERVICEMETRIC
). Using the
DBMS_MONITOR
, package tracing and stats collection can be
enabled for a service, and trace files generated across multiple instances can be consolidated using the
trcess
utility.
Types of Services
Services can be broadly classified based on their usage and ownership into two main categories: application services
and internal services.
Application Services
Application services are normally business related and are planned to describe business applications, business
functions, and database tasks. These services can be either data dependent or functional dependent.
•
Data-dependent services are based on database or data-related key values. Applications are
routed to these services based on keys. Such services are normally implemented on databases
that are shared by multiple applications and are associated with data partitioning. When
meaning is based on the key values, the application will attach itself to a specific partition in
the database server. This could be either a set of instances or a section of the database within
an instance. Defining services for a specific area of the application and connections could be
routed to one or more instances in the cluster depending on where the service is currently
configured and could implement data-dependent services. Transaction monitors such as
Tuxedo from BEA Systems (now Oracle) also support data-dependent services; and this type
of service is called “data-dependent routing.”
Search WWH ::
Custom Search