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

QUE ES UN DATAFILE

Los datafiles son los ficheros físicos en los que se almacenan los objetos que forman parte de un tablespace. Un datafile pertenece solamente a un tablespace y a una instancia de base de datos. Un tablespace puede estar formado por uno o varios datafiles.

http://www.programacion.com/tutorial/oracle/3/

QUE ES UN TABLESPACE

Un tablespace es una unidad lógica de almacenamiento dentro de una base de datos oracle.

Es un puente entre el sistema de ficheros del sistema operativo y la base de datos.

Cada tablespace se compone de, al menos, un datafile y un datafile solo puede pertenecer a un tablespace.

http://ora.u440.com/ddl/create tablespace.html

ARCHIVO DE REGISTRO EN ORACLE

Los Archivos de registro (o archivos de log) son archivos que contienen mensajes sobre el sistema, incluyendo el kernel, los servicios y las aplicaciones que se ejecutan en dicho sistema. Existen diferentes tipos de archivos de log dependiendo de la información. Por ejemplo, existe un archivo de log del sistema, un archivo de log para los mensajes de seguridad y un archivo de log para las tareas cron.

concepto a cada proceso Background:

SMON:

SYSTEM MONITOR permite recuperar la instacia de la base de datos en caso de una caída fatal (cuando el sistema falla por ejemplo)

PMON:

PROCESS MONITOR es el encargado de gestionar adecuadamente los procesos que fallan. Ante caída de procesos, PMON se encarga de restaurar los datos adecuadamente

DATABASE WRITER:

Proceso encargado de escribir en los ficheros de los datos los buffers más antiguos de la memoria, para que la base de datos vaya almacenando los cambios.

LOGWRITER:

Escribe los datos a los ficheros rehacer (redo) desde la cache de archivos rehacer

CHECKPOINT:

Actualiza todas las cabeceras de los ficheros de datos para que aparezca la nueva disposicion de datos. Que ocurre cuando se regenera un nuevo punto de comprobación.

DESDE: www.orape.net/downloads-file-54.html

ARCHIVER:

¿qué es el pga - Oracle?

Área Global de Programa

El Programa Global Área es un área de memoria utilizada por un proceso Oracle. Esta zona de memoria no se puede compartir.

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

¿qué es el sga - Oracle?

Área Global del Sistema, SGA

Sirve para facilitar la transferencia de información entre usuarios y también almacena la información estructural de la BD más frecuentemente requerida.

La SGA se divide en varias partes:

Buffers de BD, Database Buffer Cache

Es el caché que almacena los bloques de datos leidos de los segmentos de datos de la BD, tales como tablas, índices y clusters. Los bloques modificados se llamas bloques sucios. El tamaño de buffer caché se fija por el parámetro DB_BLOCK_BUFFERS del fichero init.ora.

Como el tamaño del buffer suele ser pequeño para almacenar todos los bloques de datos leidos, su gestión se hace mediante el algoritmo LRU.

Buffer Redo Log

Los registros Redo describen los cámbios realizados en la BD y son escritos en los ficheros redo log para que puedan ser utilizados en las operaciones de recuperación hacia adelante, roll-forward, durante las recuperaciones de la BD. Pero antes de ser escritos en los ficheros redo log son escritos en un caché de la SGA llamado redo log buffer. El servidor escribe periódicamente los registros redo log en los ficheros redo log.

El tamaño del buffer redo log se fija por el parámetro LOG_BUFFER.

Área de SQL Compartido, Shared SQL Pool

En esta zona se encuentran las sentencias SQL que han sido analizadas. El analisis sintáctico de las sentencias SQL lleva su tiempo y Oracle mantiene las estructuras asociadas a cada sentencia SQL analizada durante el tiempo que pueda para ver si puede reutilizarlas. Antes de analizar una sentencia SQL, Oracle mira a ver si encuentra otra sentencia exactamente igual en la zona de SQL compartido. Si es así, no la analiza y pasa directamente a ejecutar la que mantinene en memoria. De esta manera se premia la uniformidad en la programación de las aplicaciones. La igualdad se entiende que es lexicografica, espacios en blanco y variables incluidas. El contenido de la zona de SQL compartido es:

o Plan de ejecución de la sentencia SQL.

o Texto de la sentencia.

o Lista de objetos referenciados.

Los pasos de procesamiento de cada petición de análisis de una sentencia SQL son:

o Comprobar si la sentencia se encuentra en el área compartida.

o Comprobar si los objetos referenciados son los mismos.

o Comprobar si el usuario tiene acceso a los objetos referenciados.

Si no, la sentencia es nueva, se analiza y los datos de análisis se almacenan en la zona de SQL compartida.

También se almacena en la zona de SQL compartido el caché del diccionario. La información sobre los objetos de la BD se encuentra almacenada en las tablas del diccionario. Cuando esta información se necesita, se leen las tablas del diccionario y su información se guarda en el caché del diccionario de la SGA.

Este caché también se administra mediante el algoritmo LRU. El tamaño del caché está gestionado internamente por el servidor, pero es parte del shared pool, cuyo tamaño viene determinado por el parámetro SHARED_POOL_SIZE.

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

¿qué es una instancia en Oracle?

La instancia es la unión de los procesos y de las estructuras de memoria, los cuales se hallan en ejecución para el acceso de los usuarios a los datos a través de diferentes aplicaciones como por ejemplo administración, desarrollo y otras aplicaciones de usuario final.

DESDE: http://www.zonaoracle.com/?q=node/2188

¿Cuáles son los roles o funciones de un administrador de base de datos?

El administrador de base de datos (DBA) es la persona responsable de los aspectos ambientales de una base de datos. En general esto incluye:

* Recuperabilidad - Crear y probar Respaldos

* Integridad - Verificar o ayudar a la verificación en la integridad de datos

* Seguridad - Definir y/o implementar controles de acceso a los datos

* Disponibilidad - Asegurarse del mayor tiempo de encendido

* Desempeño - Asegurarse del máximo desempeño incluso con las limitaciones

* Desarrollo y soporte a pruebas - Ayudar a los programadores e ingenieros a utilizar eficientemente la base de datos.

El diseño lógico y físico de las bases de datos a pesar de no ser obligaciones de un administrador de bases de datos, es a veces parte del trabajo. Esas funciones por lo general están asignadas a los analistas de bases de datos ó a los diseñadores de bases de datos.

DESDE: http://es.wikipedia.org/wiki/Administrador_de_base_de_datos#Deberes