ALTA DISPONIBILIDAD

REAL APPLICATION CLUSTERS
Installing Oracle Database 10g with Real Application Cluster (RAC)

To install the RAC database and the instances on all RAC nodes, OUI has to be launched on only one RAC node. In my example I will run OUI on rac1pub.

Use the oracle terminal that you prepared for ssh at Automating Authentication for oracle ssh Logins, and execute dbca. But before you execute dbca, make sure that $ORACLE_HOME and $PATH are set:
oracle$ . ~oracle/.bash_profile
oracle$ dbca

- Welcome Screen: Select "Oracle Real Application Clusters database"
Click Next
- Operations: Select "Create Database"
Click Next
- Node Selection: Click "Select All". Make sure all your RAC nodes show up and are selected!
If dbca hangs here, then you probably didn't follow the steps as outlined at
Automating Authentication for oracle ssh Logins
Click Next
- Database Templates: I selected "General Purpose".
Click Next
- Database Identification:
Global Database Name: orcl
SID Prefix: orcl
Click Next
- Management Option: I selected "Use Database Control for Database Management".
Click Next
- Database Credentials:
I selected "Use the Same Password for All Accounts". Enter the password and
make sure the password does not start with a digit number.
Click Next
- Storage Options: I selected "Automatic Storage Management (ASM)", see
Installing and Configuring Automatic Storage Management (ASM) and Disks
Click Next
- Create ASM Instance:
Enter the SYS password for the ASM instance.
I selected the default parameter file (IFILE):
"{ORACLE_BASE}/admin/+ASM/pfile/init.ora"
Click Next

At this point DBCA will create and start the ASM instance on all RAC nodes.
Click OK to create and start the ASM instance.

An error will come up that oratab can't be copied to /tmp. I ignored this error.

If you get "ORACLE server session terminated by fatal error", then you probably
didn't follow the steps at Setting Up the /etc/hosts File

- ASM Disk Groups: - Click "Create New"

Create Disk Group Window:
- Click "Change Disk Discovery Path".
- Enter "ORCL:VOL*" for Disk Discovery Path.
The discovery string for finding ASM disks must be prefixed with "ORCL:",
and in my example I called the ASM disks VOL1, VOL2, VOL3.
- I entered an arbitraty Disk Group Name: ORCL_DATA1
- I checked the candidate: "ORCL:VOL1" and "ORCL:VOL2" which have
together about 60 GB space in my configuration.
- Click OK.

- Check the new created disk group "ORCL_DATA1".
- Click Next
- Database File Locations:
Select "Use Oracle-Managed Files"
Database Area: +ORCL_DATA1
Click Next
- Recovery Configuration:
Using recovery options like Flash Recovery Area is out of scope for this article.
So I did not select any recovery options.
Click Next
- Database Content: I did not select Sample Schemas or Custom Scripts.
Click Next
- Database Services: Click "Add" and enter a Service Name: I entered "orcltest".
I selected TAF Policy "Basic".
Click Next
- Initialization Parameters:
Change settings as needed.
Click Next
- Database Storage: Change settings as needed.
Click Next
- Creation Options: Check "Create Database"
Click Finish
- Summary: Click OK

Now the database is being created.

The following error message came up:
"Unable to copy the file "rac2pub:/etc/oratab" to "/tmp/oratab.rac2pub".
I clicked "Ignore". I have to investigate this.


Your RAC cluster should now be up and running. To verify, try to connect to each instance from one of the RAC nodes:
$ sqlplus system@orcl1
$ sqlplus system@orcl2
$ sqlplus system@orcl3

After you connected to an instance, enter the following SQL command to verify your connection:
SQL> select instance_name from v$instance;

Referencia: http://www.puschitz.com/InstallingOracle10gRAC.shtml



DATA GUARD

UN MOTIVO MAS PARA CONSIDERAR A ORACLE COMO LA BASE DE DATOS MAS SEGURA Y DISPONIBLE


Es la funcionalidad de la base de datos Oracle que brinda la mayor y más efectiva disponibilidad, protección y recuperación ante desastres de los datos, ya que provee la administración, el monitoreo y la automatización de una o más bases de datos standby para proteger a los datos ante fallas, desastres, errores o corrupción. .
Tanto sea que las bases standby estén ubicadas en un sitio de recuperación ante desastres a varios kms del sitio de producción o en el mismo edificio, esta funcionalidad asegura que si la base de datos de producción sale de servicio, sea de manera planeada como imprevistamente, Data Guard switchea automáticamente la base standby al rol de base de producción, minimizando el tiempo de la caída y previniendo la pérdida de datos.
Data Guard brinda confiabilidad, ya que eladministrador siempre conoce el estado de las bases standby que pueden, en solo segundos, asumir el rol primario
Principales beneficios
a)Recuperación ante desastres y alta disponibilidad
Mediante un failover automático y fácil de administrar que en segundos cambia el rol de las bases de standby a producción
b)La base standby database también provee una salvaguarda efectiva contra la corrupción de los datos y los erroresde los usuarios
Ya que daños físicos en la base de datos primaria no se propagan a la standby
c)La base standby puede ser utilizada para backups y reportes de sólo lectura
Reduciendo la carga de trabajo de las bases productivas ahorrando ciclosde CPU y de E/S.
d)Flexibilidad en la protección de los datos
Balancea la disponibilidad con los requerimientos de performance
e)Protección ante fallas de comunicación
Si la conectividad de la red se pierde, por lo que no se pueden transmitir los datos entre las bases productivas y las standby, luego cuando se reestablece la misma, los datos perdidos son automáticamente detectados porData Guard y los logs de los archivos son transmitidos a las bases standby, lasque se resincronizan con las bases primarias, sin intervención manual del administrador.
f)Administración simple y centralizada
La funcionalidad Data Guard Broker automatiza la administración y el monitoreo detodas las bases de datos
g)Economía
Ya que Data Guard está disponible como una característica integrada de la versión Enterprise Edition sin costo adicional.
Referencia: http://www.kit.com.ar/boletines-a.php?id=0000035


TECNOLOGIA ORACLE FLASHBACK

According to many studies, 40% of application outages are caused by operator or user errors. Part of being human is making mistakes. But these errors are extremely difficult to avoid and can be particularly difficult to recover from without advance planning and the right technology. Such errors can result in "logical" data corruption, or cause downtime of one or more components of the IT infrastructure. While it is relatively simple to rectify the failure of an individual component, detection and repair of logical data corruption, such as accidental deletion of valuable data, is a time consuming operation that causes enormous loss of business productivity. Typical user-errors may include accidental deletion of valuable data, deleting the wrong data, and dropping the wrong table.
Guarding Against Human Errors
The Oracle Database architecture leverages the unique technological advances in the area of database recovery due to human errors. Oracle Flashback Technology provides a set of new features to view and rewind data back and forth in time. The Flashback features offer the capability to query historical data, perform change analysis, and perform self-service repair to recover from logical corruptions while the database is online. With Oracle Flashback Technology, you can indeed undo the past!
Oracle9i introduced Flashback Query to provide a simple, powerful and completely non-disruptive mechanism for recovering from human errors. It allows users to view the state of data at a point in time in the past without requiring any structural changes to the database.
Oracle Database 10g extended the Flashback Technology to provide fast and easy recovery at the database, table, row, and transaction level. Flashback Technology revolutionizes recovery by operating just on the changed data. The time it takes to recover the error is now equal to the same amount of time it took to make the mistake. Oracle 10g Flashback Technologies includes Flashback Database, Flashback Table, Flashback Drop, Flashback Versions Query, and Flashback Transaction Query.
Flashback technology can just as easily be utilized for non-repair purposes, such as historical auditing with Flashback Query and undoing test changes with Flashback Database. Oracle Database 11g introduces an innovative method to manage and query long-term historical data with Flashback Data Archive. This release also provides an easy, one-step transaction backout operation, with the new Flashback Transaction capability.

¿QUE ES UN INDICE BITMAP EN ORACLE?

Son efectivos para columnas simples con poca cardinalidad, esto es muchos valores distintos. Son más rápidos que los B*-Tree en entornos de read-only y almacenan valores de 0 ó 1 en el ROWID.

Ejemplo:
create bitmap index person_region on person (region);

fuente: www.knol.google.com/k/jess-armand-calejero-romn/ndices-en-oracle/2lfzfow3ogkw0/8#

¿QUE ES UN INDICE B-TREE EN ORACLE?

Se estructura como un árbol cuya raíz contiene múltiples entradas y valores de claves que apuntan al siguiente nivel del árbol.

Nivel 0.
tablas pequeñas de datos estáticos.
Nivel 1.
Indexa tablas dinámicas con el valor único de los identificadores de columna.
Nivel 2.
Indexa largas tablas o con poca cardinalidad.

fuente: www.knol.google.com/k/jess-armand-calejero-romn/ndices-en-oracle/2lfzfow3ogkw0/8#

¿QUE ES UN INDEX?

Un índice es una estructura de memoria secundaria que permite el acceso directo a las filas de una tabla (esté o no agrupada). Aumenta la velocidad de respuesta de la consulta, mejorando su rendimiento y optimizando su resultado. Su manejo se hace de forma inteligente. Es el propio Oracle quien decide qué índice se necesita.

Tipos de Índices.

Hay tres tipos de índices en Oracle.

* Lectura/Escritura

o B-tree (árboles binarios)

o Function Based

o Reserve key

* Sólo lectura (read only)

o Bitmap

o Bitmap join

o Index-organized table (algunas veces usados en lectura/escritura)

o Cluster y hash cluster

* Domain (muy específicos en aplicaciones Oracle)

fuente: www.knol.google.com/k/jess-armand-calejero-romn/ndices-en-oracle/2lfzfow3ogkw0/8#

¿QUE ES Y PARA QUE SIRVE UN TABLESPACE DEL TIPO UNDO (UNDO TABLESPACE)?

Nuevo problema en nuestras bases de datos, y nuevamente debido a una mala gestión por nuestra parte en el proceso de postcreación de la base de datos. En este caso estamos en un entorno de pruebas, por lo que el problema no es tan serio, pero hay que solucionarlo cuanto antes. Estamos trabajando con un cluster de dos nodos Oracle 10g (10.2.0.3) que contienen dos bases de datos. Los tablespaces de undo de una de ellas (una base de datos solo puede tener un tablespace de undo activo en un momento determinado; pero al estar en un entorno RAC, tenemos un tablespace de undo para cada instancia) se han ido de madre: han crecido más de la cuenta y nos han llenado el disco. El problema es similar al que tuvimos con el del tablespace temporal que creció hasta los 32 Gb; se nos coló el autoextend sin límite en la creación de la base de datos.
Tenemos localizado el proceso responsable: se trataba de un Import Data Pump (impdp) sobre datos de una nueva aplicación que se iba a situar en este entorno. De modo que, el primer paso es simple: eliminar el esquema importado, que de momento no se está usando, para liberar espacio en el disco, dejarme a mi una zona en la que poder arreglar el desaguisado, y permitir que el resto de aplicaciones sigan funcionando sin problemas.

Ahora viene lo bueno. Un tablespace no se puede reducir de tamaño. Lo que voy a hacer es eliminarlo y volver a crearlo con un tamaño adecuado, añadiendo además un límite a su crecimiento. El problema que tengo ahora es que estoy tratando con un tablespace de undo, el cual tiene un tratamiento especial. No se puede poner offline (y menos aún borrar) mientras tenga segmentos activos. De modo que, lo primero es crear un nuevo tablespace de undo (las instrucciones que indico a continuación las ejecuto como usuario SYS, con lo que ¡ojo!):
CREATE UNDO TABLESPACE UNDO_TEMP DATAFILE SIZE 100M;
Ahora en la primera instancia del cluster (el orden da igual) se indica el parámetro que indica el tablespace de undo por defecto. La suerte en este caso es que se trata de un parámetro dinámico, y por lo tanto no hace falta parar la instancia:
ALTER SYSTEM SET UNDO_TABLESPACE=’UNDO_TEMP’ SID=’PRUEBA1′;

Si ahora reviso los parámetros que hacen referencia al undo en esta instancia, me encuentro con lo siguiente (show parameter undo):


NAME TYPE VALUE
——————— ———– ——————–
undo_management string AUTO
undo_retention integer 900
undo_tablespace string UNDO_TEMP

En teoría, ya puedo borrar el tablespace de undo que me estaba dando la lata. Si se diera la condición de que todos los segmentos estuvieran en estado offline, no haría ni siquiera falta poner offline el tablespace; le podría hacer un drop sin más complicaciones. El problema viene cuando hay algún segmento que no está offline; teniendo claro que no quiero hacer rollback, ni recuperar ningún tipo de transacción, y que puedo prescindir totalmente de estos datos, lo que voy a hacer es forzar el estado offline de los segmentos que no lo estén para poder borrar el tablespace de forma limpia. ¿Cómo compruebo esto? Con la siguiente select:
SELECT SEGMENT_NAME,TABLESPACE_NAME,STATUS
FROM DBA_ROLLBACK_SEGS
WHERE TABLESPACE_NAME=’UNDOTBS1′;

Que me dará un resultado como el que sigue:
SEGMENT_NAME TABLESPACE_NAME STATUS
——————– ————————- —————-
_SYSSMU13$ UNDOTBS2 NEEDS RECOVERY
_SYSSMU14$ UNDOTBS2 OFFLINE
_SYSSMU15$ UNDOTBS2 OFFLINE
_SYSSMU16$ UNDOTBS2 OFFLINE
_SYSSMU17$ UNDOTBS2 NEEDS RECOVERY
_SYSSMU18$ UNDOTBS2 OFFLINE
_SYSSMU19$ UNDOTBS2 OFFLINE
_SYSSMU20$ UNDOTBS2 OFFLINE

Cualquier status diferente de OFFLINE necesitará que le apliquemos el procedimiento que a continuación describo.

2. ¿QUE ES UN INDEX?
Los indices se usan para mejorar el rendimiento de las operaciones sobre una tabla.

En general mejoran el rendimiento las SELECT y empeoran (minimamente) el rendimiento de los INSERT y los DELETE.

Una vez creados no es necesario nada más, oracle los usa cuando es posible (ver EXPLAIN PLAN).

En oracle existen tres tipos de indices:
1)Table Index:

CREATE [UNIQUE|BITMAP] INDEX [esquema.]index_name
ON [esquema.]table_name [tbl_alias]
(col [ASC | DESC]) index_clause index_attribs
fuente: www.juanfran.wordpress.com/2007/10/26/reducir-tamano-en-el-tablespace-undo/

QUE ES UINA EXTENSION DE ORACLE?

Una serie de bloques contiguos es una extensión, que es una unidad lógica de almacenamiento. Una serie de extensiones es un segmento. Cuando un objeto es creado, se reserva una extensión en su segmento. Cuando el objeto crezca, necesitará más espacio y se reservarán más extensiones.

http://www.infor.uva.es/~jvegas/cursos/bd/orarq/orarq.html#3.3.2

QUE ES UN SEGMENTO EN ORACLE?

Los datos en la BD son almacenados físicamente en bloques Oracle: la mínima unidad de espacio físico, y es un múltiplo del bloque del SO (2 Kb usualmente). El tamaño del bloque Oracle se fija por el parámetro DB_BLOCK_SIZE del fichero init.ora. Un tamaño grande de bloque mejora la eficiencia del cache de E/S, pero el tamaño de la SGA aumentará para contener los mismos DB_BLOCK_BUFFERS, lo que significa un problema de memoria.

Cada segmento tiene un conjunto de parámetros de almacenamiento que controla su crecimiento:

initial: tamaño de la extensión inicial (10k).

next: tamaño de la siguiente extensión a asignar (10k).

minextents: número de extensiones asignadas en el momento de la creación del segmento (1).

maxextents: número máximo de extensiones (99).

pctincrease: Porcentaje en el que crecerá la siguiente extensión antes de que se asigne, en relación con la última extensión utilizada (50).

pctfree: porcentaje de espacio libre para actualizaciones de filas que se reserva dentro de cada bloque asignado al segmento (10).

pctused: porcentaje de utilización del bloque por debajo del cual Oracle considera que un bloque puede ser utilizado para insertar filas nuevas en él.

tablespace: nombre del espacio de tablas donde se creará el segmento.

Cuando se diseña una BD se ha de tener mucho cuidado a la hora de dimensionar la BD y prever el crecimiento de las tablas. A continuación se hacen algunas consideraciones sobre la gestión del espacio para los diferentes segmentos.

Segmentos de Datos

El espacio del diccionario de datos se suele mantener más o menos constante, aunque es crítico que tenga suficiente espacio para crecer en el espacio de tablas SYSTEM. Así, hay que tener cuidado de colocar las tablas de usuario, los índices, segmentos temporales y los segmentos de rollback en otros espacios de tablas. Además, es recomendable que el espacio de tablas SYSTEM esté al 50% o 75% de su espacio disponible. Finalmente, asegurarse que los usuarios no tienen privilegios de escritura en el espacio de tablas SYSTEM.

Las tablas crecen proporcionalmente con el número de filas, ya que se puede suponer que la longitud de las filas es constante.

Segmentos de Índice

Los índices crecen en tamaño en mayor proporción que las tablas asociadas si los datos en la tabla son modificados frecuentemente. La gestión del espacio es mejor si se mantienen los índices de tablas grandes en espacios de tablas separados.

Segmentos de Rollback

Los segmentos de rollback almacenan la imagen anterior a una modificación de un bloque. La información en el segmento de rollback se utiliza para asegurar la consistencia en lectura, el rollback (el valor en el segmento de rollback se copia en el bloque de datos) y la recuperación.

Es importante comprender cual es el contenido de un segmento de rollback. No almacenan el bloque de datos modificado entero, sólo la imagen previa de la fila o filas modificadas. La información del segmento de roolback consiste en varias entradas llamadas undo. Por ejemplo, si se inserta una fila en una tabla, el undo necesitará sólo el rowid de la fila insertada, ya que para volver atrás la insercion sólo hay que realizar un delete. En las operación de actualización, se almacenará el valor antiguo de las columnas modificadas. El segmento de rollback asegura que la información undo se guardan durante la vida de la transacción.

Un segmento de rollback como cualquier otro segmento consiste en una serie de extensiones. Sin embargo, la mayor diferencia entre un segmento de datos y otro rollback es que en este último las extensiones se utilizan de manera circular. Así, habrá que tener cuidado a la hora de fijar el tamaño del segmento de rollback para que la cabeza no pille a la cola.

Segmentos Temporales

Los segmentos temporales se crean cuando se efectuan las siguientes operaciones:

Create Index

Select con distinct, order by, union, intersect y minus.

uniones no indexadas.

Ciertas subconsultas correlacionadas.

Si las tablas a ordenar son pequeñas la ordenación se realiza en memoria principal, pero si la tabla es grande se realiza en disco. El parámetro SORT_AREA_SIZE determina el lugar donde se hace la ordenación. Incrementándole se reduce la creación de segmentos temporales.

http://www.infor.uva.es/~jvegas/cursos/bd/orarq/orarq.html#3.3.2