Oracle services were a feature introduced in Oracle 10g. Their function is to simplify workload management by allowing you to group applications that share traits such as thresholds, priorities and attributes.
The Oracle database is presented as a service and so you always have at least one service running. It is good practice to create at least one more service for application workloads and not to use the default Oracle service as it cannot by changed and will always allow connections.
One instance of a RAC database can support multiplke services and one service can spoan multiple instances. One service can support many applications, one or even a subset of one appliation.
You can create a service to accommodate batch users and another to deal with online users. Alternatively, you could assign a service to handle a particular application, application type or parts of an application etc.
It is recommended that you use a service to connect applications to the database and you do this by specifying the service name in the application’s connection string.
The resource manager is tightly integrated with services and you can control how and when services can run in an instance with it. It also allows scheduler jobs to tun as a service which allows you greater flexibility about how and when they run.
Oracle ASM keeps redundancy quite simple by providing only 3 options. you can choose to have no redundancy or mirroring provided by the ASM instance. This is the ‘External’ option and assumes that you are handling mirroring somewhere else perhaps through hardware raid on your storage network.
You can chose ‘normal’ 2 way mirroring r ‘High’ for 3 way mirroring.
This option is set for each disk group and can be different for every one.
Basically, the redundancy level determines how many disks you can afford to have fail before the disk group is dismounted or data loss occurs. With external mirroring, you can’t afford to lose any disks whereas with 3 way mirroring, you could lose 2 disks and there would still be one copy available.
With normal RAID, the level of mirroring is set for the disk (or disk group). ASM gives you a more granular level of control. For example, it is possible to set different mirroring levels for different files on a single disk group.
When data is created or an extent is allocated, ASM creates a primary copy and a mirrored copy. these copies are distributed across failure groups so that losing a failure group completely would not in and of itself cause the loss of any data.
You cannot change the redundancy levels of a disk group once it is created. If failure groups are not specified, ASM places each disk into its own failure group (unless the disk group contains Exadata cells.
The process for modifying a votedisk that is stored on ASM differs from the process when the votedisk is stored on some other medium.
When your voting disks are stored on ASM you can move them off to non ASM storage with the replace command:
$ crsctl replace votedisk [path_to_new_votedisk]
(this can be done from any node.
The opposite is much the same and you can move all of the disks when they are not on ASM , to ASM with the replace command:
$ crsctl replace votedisk +[asm_diskgroup]
When you are not using ASM storage for your voting disks, the procedure is much the same but there are differences because, where ASM handles the replication of voting disks (you specify one disk and it is replicated depending on the protection level of your ASM disk group), when you are not using ASM, you need to manually create disks to handle replication.
You add a voting disk with the command:
$ crsctl add css votedisk [path to vote disk]
you can also delete a votedisk with the following command:
$ crsctl delete css votedisk [path the votedisk]
The only slightly more complicated option is if you want to replace the votedisk. in this case, you need to create a new one and delete the old one in one command. this is done with the ‘purge’ option which deletes the disk.
$ crsctl add css votedisk [path to votedisk] -purge
An ASM instance forms and presents is the underlying structure for an ASM dynamic volume.
ASM provides a disk group which is really a logical container for physical space. ASM is very efficient at storing data files but there are many types of files that cannot be stored on ASM and it cannot be read directly by the OS.
In order to expand the functionality of ASM, ADVM was introduced to allow more file types to be stored on ASM managed storage.
ADVM allows you to create a volume on an ASM disk that can be presented to the operating system where a file system (such as ACFS) can be created and that can store most of your database related files as well as other ‘normal’ files that you might wish to place there. The big advantage being that it is backed up by ASM.
Some kernel modules are necessary to provide this service. They are:
- oracleasm – the asm module.
- oracleadvm – the ASM dynamic Volume manager module.
- oracleoks – the kernel services module.
- oracleacfs – the ASM file system module.
You can not use ACFS (Oracle Cluster File Systems) to store:
- Oracle Base Directory.
- Oracle Grid infrastructure home that contains software for Oracle clusterware, ASM, Oracle ACFS or Oracle ADVM components.
- OS root directory
- Boot directory
An ASM instance has its own SGA but it is not the same as the SGA in a database instance.
The 4 main sections of the SGA in an ASM instance are:
- ASM Cache – this is used during rebalancing operations for reding and writing blocks.
- Large Pool – Used for Parallel Operations.
- Shared Pool – Stored Metadata information.
- Free Memory – Memory that is not currently allocated.