Thursday, September 28, 2017

BCA & PGDCA Students : Chapter 10 - Database Resource Management and Task Scheduling


--------------------------------------------------------------------------------------------------------------------------
Prepared By :  Uday Shah - HOD(IT)
Contact No : 7600044051
Email : rupareleducation@gmail.com

·       Automated Database Maintenance Tasks

Oracle Database has automated several common maintenance tasks typically performed by database administrators.

These automated maintenance tasks are performed when the system load is expected to be light.

You can enable and disable individual maintenance tasks, and can configure when these tasks run and what resource allocations they are allotted.

Automated maintenance tasks are tasks that are started automatically at regular intervals to perform maintenance operations on the database.
An example is a task that gathers statistics on schema objects for the query optimizer. Automated maintenance tasks run in maintenance windows, which are predefined time intervals that are intended to occur during a period of low system load.
You can customize maintenance windows based on the resource usage patterns of your database, or disable certain default windows from running.
You can also create your own maintenance windows.
Oracle Database has three predefined automated maintenance tasks:
Automatic Optimizer Statistics CollectionCollects optimizer statistics for all schema objects in the database for which there are no statistics or only stale statistics. The statistics gathered by this task are used by the SQL query optimizer to improve the performance of SQL execution.
Automatic Segment Advisor — Identifies segments that have space available for reclamation, and makes recommendations on how to defragment those segments.  You can also run the Segment Advisor manually to obtain more up-to-the-minute recommendations or to obtain recommendations on segments that the Automatic Segment Advisor did not examine for possible space reclamation.
Automatic SQL Tuning AdvisorExamines the performance of high-load SQL statements, and makes recommendations on how to tune those statements. You can configure this advisor to automatically implement SQL profile recommendations.

·       About Oracle Database Resource Manager

Oracle Database Resource Manager (the Resource Manager) enables you to manage multiple workloads within a database that are contending for system and database resources.

When database resource allocation decisions are left to the operating system, you may encounter the following problems with workload management:

Excessive overhead

Excessive overhead results from operating system context switching between Oracle Database server processes when the number of server processes is high.

Inefficient scheduling

The operating system deschedules database servers while they hold latches, which is inefficient.

Inappropriate allocation of resources

The operating system distributes resources equally among all active processes and cannot prioritize one task over another.

Inability to manage database-specific resources, such as parallel execution servers and active sessions

 

·       Oracle Scheduler Concepts

Oracle Database includes Oracle Scheduler, an enterprise job scheduler to help you simplify the scheduling of hundreds or even thousands of tasks.

Oracle Scheduler (the Scheduler) is implemented by the procedures and functions in the DBMS SCHEDULER PL/SQL package.

The Scheduler enables you to control when and where various computing tasks take place in the enterprise environment.

The Scheduler helps you effectively manage and plan these tasks. By ensuring that many routine computing tasks occur without manual intervention, you can lower operating costs, implement more reliable routines, minimize human error, and shorten the time windows needed.

The Scheduler provides sophisticated, flexible enterprise scheduling functionality, which you can use to:

Run database program units

Run external executables, executables that are external to the database

Schedule job execution using the following methods:

Time-based scheduling

You can schedule a job to run at a particular date and time, either once or on a repeating basis.

Event-based scheduling

You can start jobs in response to system or business events.

Dependency scheduling

You can set the Scheduler to run tasks based on the outcome of one or more previous tasks.

Prioritize jobs based on business requirements.

Controlling Resources by Job Class

Controlling Job Prioritization based on Schedules

Manage and monitor jobs

Execute and manage jobs in a clustered environment



·       Scheduling Jobs with Oracle Scheduler

You operate Oracle Scheduler by creating and managing a set of Scheduler objects.

Each Scheduler object is a complete database schema object of the form schema.name.

Scheduler objects follow the naming rules for database objects exactly and share the SQL namespace with other database objects.

Follow SQL naming rules to name Scheduler objects in the DBMS SCHEDULER package.

By default, Scheduler object names are uppercase unless they are surrounded by double quotes. For example, when creating a job, job_name => 'my_job' is the same as job_name => 'My_Job' and job_name => 'MY_JOB', but different from job_name => '"my_job"'.

These naming rules are also followed in those cases where comma-delimited lists of Scheduler object names are used within the DBMS_SCHEDULER package.

 

You create one or more jobs using the DBMS SCHEDULER.CREATE JOB or DBMS SCHEDULER.

CREATE_JOBS procedures or Enterprise Manager. You use the CREATE JOB procedure to create a single job.

This procedure is overloaded to enable you to create different types of jobs that are based on different objects.

You can create multiple jobs in a single transaction using the CREATE JOBS procedure.

Administering Oracle Scheduler

You must have the SCHEDULER_ADMIN role to perform all Oracle Scheduler administration tasks. Typically, database administrators already have this role with the ADMIN option as part of the DBA role. For example, users SYS and SYSTEM are granted the DBA role. You can grant this role to another administrator by issuing the following statement:

SQL> GRANT SCHEDULER_ADMIN TO username;

Because the SCHEDULER_ADMIN role is a powerful role allowing a grantee to execute code as any user, you should consider granting individual Scheduler system privileges instead. Object and system privileges are granted using regular SQL grant syntax. An example is if the database administrator issues the following statement:

SQL> GRANT CREATE JOB TO scott;

After this statement is executed, scott can create jobs, schedules, programs, file watchers, and credentials in his schema. Another example is if the database administrator issues the following statement:

SQL> GRANT MANAGE SCHEDULER TO adam;

After this statement is executed, adam can create, alter, or drop windows, job classes, or window groups. He will also be able to set and retrieve Scheduler attributes and purge Scheduler logs.

Wednesday, September 27, 2017

BCA & PGDCA Students : Concurrency Control Using Lock in Oracle


--------------------------------------------------------------------------------------------------------------------------
Name : Uday J Shah , HOD (IT)
Contact No : 7600044051
Email : rupareleducation@gmail.com

Oracle Chapter : 6

What is locking?

Locking is a mechanism to ensure data integrity while allowing maximum concurrent access to data. It is used to implement concurrency control when multiple users access table to manipulate its data at the same time.
A lock is used to access a database concurrently for multiple users. This prevents data from being corrupted or invalidated when multiple users try to write to the database. Any single user can only modify those database records (that is, items in the database) to which they have applied a lock that gives them exclusive access to the record until the lock is released.

Locking Issue ::

There are many issue that while locking in Database.  Locking is strategy that prevent data lose and Data Corrupt. Locking issue describe as Under.

Lost Update

A lost update occurs when two different transactions are trying to update the same column on the same row within a database at the same time. Typically, one transaction updates a particular column in a particular row, while another that began very shortly afterward did not see this update before updating the same value itself. The result of the first transaction is then "lost," as it is simply overwritten by the second transaction.

Pessimistic locking

Which was the default locking in Oracle. This means that the row is locked in advance once one of  its attribute is changed through a call to setAttribute() method. If anyone else attempts to acquire a lock of the same row during this process, then it will be forced to wait until the first transaction has completed. This is achieved by using the familiar SELECT…FOR UPDATE syntax. This is the safest locking mode because two transactions will never make inconsistent change to the same row.

Optimistic Locking

Optimistic locking assumes that multiple transactions can complete without affecting each other. Oracle recommends using optimistic locking for web applications. instead of locking a row as soon as it is changed, under optimistic locking, it waits until changed row is posted before attempting to acquire a lock. An exception is not thrown until the conflicting transactions attempt to post their changes to the database.


Blocks

Simply put, a thread of control is blocked when it attempts to obtain a lock, but that attempt is denied because some other thread of control holds a conflicting lock. Once blocked, the thread of control is temporarily unable to make any forward progress until the requested lock is obtained or the operation requesting the lock is abandoned. Its Called Blocks

Deadlocks

A deadlock occurs when two or more threads of control are blocked, each waiting on a resource held by the other thread. When this happens, there is no possibility of the threads ever making forward progress unless some outside agent takes action to break the deadlock.

Lock Escalation

Lock escalation occurs when numerous locks are held at one level of granularity, such as rows, and a database raises the locks to a higher level of granularity, like table. For example, if a single user locks many rows in a table, some databases automatically escalate the user's row locks to a single table. The number of locks is reduced, but the restrictiveness of what is being locked is increased.

DML Locks

A DML lock, also called a data lock, guarantees the integrity of data accessed concurrently by multiple users. For example, a DML lock prevents two customers from buying the last copy of a book available from an online bookseller. DML locks prevent destructive interference of simultaneous conflicting DML or DDL operations.
DML statements automatically acquire the following types of locks:
·        Row Locks
·       Table Locks

DDL Locks

The two basic types of locks are DML (table) locks, and DDL (dictionary) locks. A DDL lock protects the definition of a schema object while the object is referenced in a DDL operation. Oracle automatically acquires a DDL lock to prevent other DDL operations from referencing or altering the same object. If a DDL lock is requested on an object that already has a DDL lock on it, the lock request will wait. DDL lock contention is rare because they are usually held only briefly.
There are three types of DDL locks: exclusive, shared, and breakable parse locks.

What are Latches?

Latches are a close cousin to lock mechanisms in Oracle that provide concurrency functions and protect data integrity for Oracle data structures.
Latches are a type of locking device that are quickly acquired and released. They prevent multiple processes from running the same application code in the database more than once at the same time, thus making available a serialization mechanism to provide data integrity for transaction management with Oracle database environments.
Latches are the lightweight serialization mechanisms that are held and quickly released for shorter durations of time as opposed to locks which are held for longer durations of time within Oracle.  Just as one would lock a door with a deadbolt heavy-duty lock to prevent entry into one's home, use a lock to protect long running transactions. Conversely, when one just wants to close the door for a short period of time, latch a transaction to keep it protected for a briefer period of time than a lock would do.

Manual Locking and User-Defined Locks

With Oracle Database Lock Management services, you can define your own locks for a specific application. For example, you might create a lock to serialize access to a message log on the file system. Because a reserved user lock is the same as an Oracle Database lock, it has all the Oracle Database lock functionality including deadlock detection. User locks never conflict with Oracle Database locks, because they are identified with the prefix UL.

The Oracle Database Lock Management services are available through procedures in the DBMS_LOCK package. You can include statements in PL/SQL blocks