Professional Documents
Culture Documents
Informacin necesaria durante la ejecucin del programa(por ejemplo, el estado de las consultas)
La informacin que comparten y con la cual se comunican los procesos Oracle (por ejemplo, la informacin de bloqueo)
La Cach de Datos
La memoria se puede estructurar en las siguientes partes:
rea Global del sistema (SGA), la cual se comparte entre todos los servidores y los procesos en segundo plano.
reas globales de programas (PGA), que es privada para cada servidor y proceso en segundo planos; a cada proceso
se asigna un PGA.
Memoria Virtual
Buffer del Dietario o del Registro del Rehacer (Redo Log Buffer).
La primera vez que un proceso de usuario necesita un dato concreto, este los busca en los datos almacenados en la cach de los buffers.
Si el proceso encuentra el dato en uno de estos buffers, se lee directamente de la memoria (cache hit). Si no lo encuentra, entonces
debe copiar la pgina en disco a un buffer de la cach antes de leerlo (cache miss). Acceder a los datos a travs de un cache hit es
ms rpido que hacerlo mediante un cache miss.
Antes de leer un bloque de datos dentro de la cach, el proceso debe encontrar primero un buffer libre, empezando desde el menos
usado recientemente de la lista LRU. El proceso sigue buscando hasta que encuentra un buffer libre o hasta que llega al final de la lista.
El Algoritmo LRU y la Lectura Completa de Tablas
Cuando un proceso de usuario realiza una exploracin completa de la tabla, lee cada bloque de la tabla en los buffers y los pone al final
de la lista LRU. Se hace as porque normalmente la exploracin completa se necesita brevemente, por lo que los bloques deben
sacarse rpidamente para dejar espacio en la cach a los bloques que se usan con mayor frecuencia.
Tamao de la Cach de los buffer
Oracle soporta mltiples tamaos de bloque en una base de datos. El tamao estndar de bloque se especifica mediante la configuracin
del parmetro DB_BLOCK_SIZE. Se admiten valores desde 2K hasta 32K.
Opcionalmente, tambin se puede seleccionar el tamao de dos pool de buffer adicionales, KEEP y RECYCLE,
configurando DB_KEEP_CACHE_SIZE y DB_RECYCLE_CACHE_SIZE. Estos tres parmetros son independientes entre s.
Mltiples Pools de Buffer
Se puede configurar la cache del buffer con buffer pools distintos, en los que cualquiera contiene datos, o estn disponibles para
nuevos datos tras usar los bloques de datos. Objetos particulares del esquema (tablas, clusters, ndices y particiones) se asignan al
buffer pool apropiado para controlar la forma en que los bloques de datos envejecen en la cache.
El buffer pool KEEP conserva los bloques de datos de los objetos del esquema en memoria.
El buffer pool RECYCLE elimina bloques de datos de la memoria tan pronto como dejan de ser necesitados.
El buffer pool DEFAULT contiene bloques de datos de los objetos del esquema que no son asignados a ningn buffer pool,
as como los objetos del esquema que son explcitamente asignados al pool DEFAULT.
Los parmetros que configuran los buffer pools KEEP y RECYCLE son DB_KEEP_CACHE_SIZE y DB_RECYCLE_CACHE_SIZE.
Buffer del Registro del Rehacer (Redo Log Buffer)
El redo log buffer es un buffer circular en el SGA que contiene informacin sobre cambios hechos a la base de datos, la cual se
almacena en las entradas redo. Estas entradas contienen la informacin necesaria para reconstruir, o rehacer cambios hechos en la
base de datos mediante las operaciones INSERT, UPDATE, DELETE, CREATE, ALTER o DROP y se usan para la recuperacin de la
base de datos, si fuera necesario.
Las entradas se copian por los procesos desde el espacio de memoria del usuario al redo log buffer en el SGA, ocupando
continuamente espacio secuencial. El proceso en segundo plano LGWR escribe el redo log buffer en el fichero redo log activo
(o grupo de ficheros) en disco.
El parmetro LOG_BUFFER determina el tamao (en bytes) del redo log buffer.
El Pool Compartido
Es la parte del SGA que contiene la cache de biblioteca, la cache de diccionario, los buffers para los mensajes de ejecucin paralela y
las estructuras de control.
El tamao total del Pool Compartido se determina por el parmetro SHARED_POOL_SIZE. El valor por defecto es de 8MB en plataformas
de 32-bit, y de 64MB para plataformas de 64-bit. Incrementando su valor se incrementa la cantidad de memoria reservada para el
pool compartido.
Memoria de la sesin para el servidor compartido y el Oracle XA interface (usado donde las transacciones interactan con
Procesamiento de E/S
El large pool satisface mejor las peticiones de gran cantidad de memoria que el pool compartido. Sin embargo, no posee una lista LRU.
Java Pool
La memoria java pool se usa en la memoria del servidor para almacenar todo el cdigo y datos del JVM en las sesiones. Se usa de
mdulo queda determinado por el tamao total del SGA. En la mayora de las plataformas el tamao del mdulo es 4MB si el tamao total
del SGA es menor de 1GB, y de 16MB para SGA mayores.
La base de datos puede configurar lmites sobre cuanta memoria virtual se usa para el SGA. Puede crear instancias con un mnimo
de memoria y permitir que la instancia use ms, expandiendo la memoria asignada a los componentes del SGA, hasta un mximo
determinado por el SGA_MAX_SIZE. Si el valor es menor que la suma de memoria asignada para todos los componentes, la base de
datos ignora la configuracin de SGA_MAX_SIZE.
Para un rendimiento ptimo, en la mayora de los sistemas, todo el SGA debera ajustarse a la memoria real. Si no es as, y la memoria
virtual es usada para almacenar partes del SGA, entonces el rendimiento total del sistema puede decrementarse en gran medida. La
cantidad de memoria dedicada para todas las reas compartidas en el SGA tambin influye en el rendimiento.
El tamao del SGA queda determinado por muchos parmetros, aunque son los siguientes los que tienen un gran efecto sobre el tamao
del SGA:
Parmetro
Descripcin
DB_CACHE_SIZE
LOG_BUFFER
SHARED_POOL_SI
Tamao en bytes para el rea dedicada al SQL
ZE
compartido e instrucciones PL/SQL.
LARGE_POOL_SIZ
JAVA_POOL_SIZE
El Parmetro SGA_TARGET
El parmetro SGA_TARGET refleja el tamao total del SGA e incluye la memoria para los siguientes componentes:
El log buffer
El pool compartido
El Java pool
El tamao de los bloques no estndar de las cachs de los buffer (si son especificados)
El Streams pool
Este incluye toda la memoria del SGA, en diferencia con las versiones anteriores en las que la memoria para la SGA interna y
fija se configuraba a travs de otros parmetros. En consecuencia, el SGA_TARGET da un control preciso sobre el tamao de la regin
de memoria compartida asignada por la base de datos. Si est configurado con un valor mayor que SGA_MAX_SIZE al inicio, entonces
este ltimo se usa como respaldo para el SGA_TARGET.
Nota: No configurar dinmicamente el SGA_TARGET. Debera ser configurado solo al inicio.
Limitando el Tamao de la SGA
El parmetro SGA_MAX_SIZE especifica el tamao mximo del SGA durante la duracin de la instancia. Puedes modificar
dinmicamente los parmetros que afectan al tamao de las caches de los buffers, del pool compartido, large pool, java pool, y
streams pool pero solo para controlar que la suma de estos tamaos y los tamaos de los otros componentes del SGA no exceden el
algn rea privada SQL especfica, y usarla como un recurso nombrado a travs de la ejecucin de un programa. Los cursores recursivos
de Oracle que emiten implcitamente algunas sentencias SQL tambin usan reas SQL.
La administracin de las reas SQL privadas son responsabilidad de los procesos del usuario. La asignacin y liberacin de las reas
SQL privadas dependen de en qu herramienta de la aplicacin se usan, aunque el nmero de reas SQL privadas que un proceso
de usuario puede asignar est siempre limitado el parmetro OPEN_CURSORS. El valor por defecto de este parmetro es 50.
Un rea SQL privada continua existiendo hasta que el correspondiente cursor es cerrado o la sentencia es liberada. Aunque Oracle libera
el rea de ejecucin despus de que la sentencia se complete, el rea persistente se mantiene en espera. Las aplicaciones de
desarrollo cierran todos los cursores abiertos que no van a ser usados otra vez para liberar el rea persistente y minimizar la cantidad
de memoria requerida por el usuario de la aplicacin.
Componentes del rea SQL Privada
El rea SQL privada de un cursor se divide en 2 reas cuya duracin son diferentes:
El rea persistente (Persistent Area), que contiene, por ejemplo, informacin envuelta. Es liberada solamente cuando el cursor
es cerrado.
El rea de ejecucin (Run-time Area), que es liberada cuando la ejecucin, valga la redundancia, es terminada.
Oracle crea el rea de ejecucin en el primer paso que una ejecucin es pedida. Para una sentencia INSERT, UPDATE y DELETE
Oracle libera el rea de ejecucin despus de que la sentencia ha sido ejecutada. Para las consultas, Oracle libera el rea de
ejecucin solamente cuando todas las filas han sido recorridas, o la consulta ha sido cancelada.
reas de Trabajo SQL
Para las consultas complejas, una gran porcin del rea de ejecucin es dedicada a reas de trabajo asignadas por operadores de
Hash-join
Bitmap merge
Bitmap create
Por ejemplo, un operador de clasificacin (sort operator) usa un rea de trabajo (algunas veces llamado rea de clasificacin sort area)
para la forma de distribucin de la memoria interna (in-memory) de una serie de filas. Similarmente, un operador hash-join usa un rea
de trabajo (tambin llamada rea hash) para construir una tabla hash desde su entrada izquierda. Si la cantidad de datos que deben
ser procesados por estos dos operadores no entran en el rea de trabajo, entonces los datos de entrada son divididos en piezas
ms pequeas. Esto permite que alguna de las piezas se procesen en la memoria mientras el resto son distribuidos en un disco
temporal para ser procesado luego. Aunque los operadores de bitmap no se distribuyen por el disco cuando su rea de trabajo es
muy pequea, su complejidad es inversamente proporcional al tamao de su rea de trabajo. Estos operadores se ejecutan ms rpido
en reas de trabajo ms grandes.
El tamao del rea de trabajo puede ser controlado y modificado. Generalmente, reas de bases de datos grandes pueden
mejorar significativamente el rendimiento de un operador respecto al coste de consumo de memoria. Opcionalmente, el tamao de un
rea de trabajo puede ser lo bastante grande como para almacenar los datos de entradas y las estructuras auxiliares de memoria
asignadas por el operador SQL asociado. De lo contrario, el tiempo de respuesta aumenta, porque parte de los datos de entrada deben
ser distribuidos por un disco de almacenamiento temporal. En caso extremo, si el tamao del rea de trabajo es muy pequeo
comparado con el tamao del dato de entrada, mltiples procesos se ejecutan sobre la parte de los datos. Esto puede aumentar el tiempo
pueden haber mltiples ordenaciones en una consulta. De esta forma, si otra consulta se ejecuta en paralelo, cada ordenacin puede
consumir la memoria especificada en este campo.
El SORT_AREA_SIZE tambin se utiliza para selecciones y actualizaciones en los ndices de las tablas. Seleccionar
un valor apropiado aqu, puede dar como resultado que la tabla se actualice una nica vez en cada operacin DML, pudiendo incluso
haber cambiado varias filas a la vez.
Grandes valores en este campo nos permitirn realizar mayores bsquedas en memoria. Si se necesitase ms espacio para
la ordenacin del que tenemos, los datos se dividirn en trozos y se utilizarn segmentos de disco temporales como apoyo en la ordenacin.
En ste ltimo caso, en el que los datos a ordenar no quepan en el rea de ordenaciones, se dividen en trozos que s quepan, se ordenan y
se mezclan (merge). A esto hace referencia tambin el manual de Oracle9i, que si bien lo hace en trozos separados, a continuacin se
muestran las dos referencias juntas:
Para un mejor rendimiento del SGBD, la mayora de las ordenaciones deberan tener lugar nicamente en memoria ya
que en caso de tener que escribir a disco, obtendremos un claro efecto adverso sobre ste. Si las aplicaciones que acceden a la base de
datos suelen realizar bsquedas que no caben en el rea de ordenaciones, o incluso si las aplicaciones realizan demasiadas
bsquedas innecesarias, entonces sera conveniente modificar el parmetro de SORT_AREA SIZE.
El SORT_AREA_SIZE es un parmetro que se puede inicializar y modificar dinmicamente y que especifica la cantidad
de memoria que se tiene disponible al realizar las ordenaciones. Si una cantidad importante de ordenaciones requiere acceso a disco
para almacenar segmentos temporales, entonces la aplicacin se ver claramente beneficiada al ampliar el SORT_AREA_SIZE. De
forma alternativa, en un entorno DSS, aumentar este parmetro no tiene por qu hacer que la ordenacin se realice nicamente en
memoria, pero s es cierto que dependiendo del valor actual y del nuevo elegido, se puede aumentar drsticamente la velocidad de la
ordenacin.
Por lo tanto, como conclusin, alterar este parmetro, se puede considerar como un paso importante para asegurarnos el rendimiento
en ciertas circunstancias y situaciones. Sin embargo, determinar qu valor es el ms apropiado, es por supuesto, la parte ms complicada.
De esta forma, cuando un proceso es cargado en memoria, se cargan todas sus pginas en marcos libres y se completa su tabla de
pginas.
Swapping
El Swapping es el procedimiento de mover los bloques de memoria en los que estn algunos procesos que no se estn utilizando, desde
la memoria principal a un espacio Swap dejando as hueco libre para poder cargar en memoria otros procesos que s se van a utilizar.
El espacio Swap o espacio de intercambio es una zona de disco (un fichero o una particin) que se usa para guardar las imgenes de
los procesos que no han de mantenerse en memoria fsica.
Este procedimiento es muy similar a la paginacin, con la diferencia principal de que el directorio Swap funciona exactamente igual que
la memoria RAM, por lo que puede almacenar datos privados, contraseas y todo lo que almacena sta. Sin embargo, en la
paginacin, nicamente se sacan de memoria pginas pertenecientes a procesos que no se estn utilizando, adems de que se pueden
sacar solo algunas pginas de los procesos y no stos enteros como se hace en el Swapping.
Con respecto al tamao que debe tener el directorio Swap, hay muchas discusiones sobre ello como por ejemplo la antigua creencia de
El Swap debe tener el doble de tamao que la RAM. cosa que no es vlida hoy da debido a la gran capacidad de la memoria RAM de
la mayora de ordenadores.
Como conclusin, hay que destacar que el uso de la memoria virtual por parte de Oracle, va a influir bastante en el
rendimiento, disminuyndolo drsticamente en comparacin con el uso nicamente de la memoria RAM.
rea de Cdigo de Software (Sca)
El rea de cdigo de software son zonas de memoria destinadas a almacenar el cdigo de Oracle en ejecucin o que puede ejecutarse.
Este cdigo de Oracle se almacena en una zona distinta, y ms protegida, que las zonas dedicadas a almacenar los cdigos de
programas de usuarios.
La SCA suele ser de tamao esttico, cambiando nicamente cuando el software se reinstala o actualiza. El tamao requerido para este
rea puede variar en funcin del SO. Son reas de slo lectura y pueden ser instalas de forma compartida o no compartida. Cuando
es posible, el cdigo de Oracle se comparte, por lo que todos los usuarios pueden acceder a l sin tener mltiples copias en memoria.
El resultado es un ahorro considerable de memoria y una mejora del rendimiento general.
Por otra parte, los programas de usuario tambin pueden ser compartidos o no. Algunas utilidades y herramientas de Oracle (como
ocurre con Oracle Forms y SQL*Plus) pueden ser instalados de forma compartida, pero otras no. Mltiples instancias de Oracle pueden
usar la misma SCA con diferentes bases de datos si estn corriendo en la misma mquina.
Hay que tener en cuenta que la opcin de instalar software compartido puede no estar disponible en funcin del sistema operativo,
como ocurre por ejemplo en mquinas con Windows.
Estructura de los Procesos
Cuando un usuario se conecta a una base de datos de Oracle ejecuta dos mdulos de cdigo diferentes, que adems el encargado
de gestionar estos procesos es el sistema operativo, estos dos mdulos diferentes son:
Aplicacin o Herramienta Oracle: normalmente son programas clientes que se conectan a la base de datos y permiten ejecutar
Cdigo del Servidor de Oracle: son los diferentes procesos que se han de ejecutar en el servidor para atender las peticiones del
usuario.
La base de datos Oracle es un sistema multiproceso, lo que significa que no toda la base de datos est corriendo en un mismo proceso,
si no que varias partes de la base de datos se ejecuta concurrentemente. Permitiendo a mltiples usuarios conectarse a la misma vez, y
mayor rapidez en el tiempo de respuesta, puesto que siempre que pueda va a utilizar al mximo al ordenador, por ejemplo si tiene ocho
ncleos el servidor, y resulta que una peticin se puede paralelizar se ejecutara esa peticin por partes en cada ncleo.
De los procesos que se ejecutan en el servidor podemos hacer dos grandes grupos:
Procesos de Usuarios: Cada vez que un usuario ejecuta una aplicacin, ya sea propia o de Oracle se crea un proceso, que puede
ser de dos tipos.
Conexin: Que es la va de comunicacin entre la aplicacin y la instancia de la base de datos a la que se ha conectado.
Esto permite que desde un mismo equipo se puedan conectar varios usuarios simultneamente, y que un usuario se pueda conectar
desde diferentes equipos simultneamente.
Procesos de Oracle: Son propios de la base de datos, y el usuario no tiene control sobre ellos, pueden ser de dos tipos:
Procesos de Servidor: Se crea cuando una aplicacin intenta acceder a la base de datos, para atender a las peticiones
de la aplicacin y devolver los resultados que se precisen.
Procesos de Background: Se crean cuando se inicia una instancia de la base de datos, solo hay un proceso de cada tipo de los
que especificaremos a continuacin, y no han de estar todos siempre presentes en el servidor. Se utilizan para realizar labores de
mantenimiento, y para guardar la integridad de la base de datos. Los diferentes tipos de procesos son los siguientes:
Database Writer Process (DBWn)
El (DBWn) escribe el contenido de los buffers en los archivos de datos. El proceso DBWn es responsable por la escritura de los
buffers modificados del buffer cache al disco. El proceso DBWn escribe buffers modificados al disco bajo las siguientes condiciones:
Cuando un proceso no puede encontrar un buffer limpio reusable despus de haber recorrido un nmero de determinado de buffers en
el buffer cach, ste enva una seal al DBWn para la escritura. El DBWn escribe los buffers sucios al disco.
El DBWn peridicamente escribe los buffers cuando se lleva a cabo un checkpoint. Chekpoint es una posicin en el hilo de redo (log)
donde se iniciar luego la recuperacin. La posicin en el log est determinada por el ltimo buffer sucio en el buffer cach.
Log Writer Process (LGWR)
El proceso LGWR es responsable del manejo del redo log buffer, las escrituras del redo log buffer al archivo de redo log en el disco.
El LGWR escribe todos los registros de redo que han sido copiados en el buffer desde la ltima vez que ste se escribi. El redo log
buffer es un buffer circular. Cuando LGWR escribe los registros del redo log buffer al redo log file, el proceso servidor puede copiar
nuevos registros sobre aquellos que se pasaron a disco. LGWR normalmente escribe lo suficientemente rpido para asegurar que el
espacio est siempre disponible en el buffer para nuevos registros, aun cuando la escritura al redo log file sea lenta.
LGWR escribe en porciones contiguas del buffer al disco. El LGRW escribe:
Cuando un usuario lleva a cabo una instruccin de commit, el LGWR coloca el registro de commit en el log buffer y escribe la transaccin a
disco inmediatamente en el redo log. Los cambios correspondientes a los bloques de datos en el buffer cach, son dejados hasta que se
tenga una escritura ms eficiente que hacer. Esto se denomina el mecanismo de fast commit. La escritura de un registro de redo del
commit de la transaccin es un evento atmico.
Existe un mito con respecto a la escritura en el redo log buffer, se dice que en el redo log buffer o redo log file aparecern slo las
transacciones comprometidas. En el redo log file se escriben todas las transacciones, no slo las comprometidas, es por ello que el redo
log permite rehacer los segmentos de undo del cualquier punto en el tiempo cuando se hace recuperacin incompleta (point in time
recovery).
Redo Log Files
Los Redo Log Files se agrupan en grupos de Redo Log. Todos los miembros de un Redo Log Group son idnticos, es decir contendrn
la misma informacin. Dentro de un grupo de Redo Log se "multiplexan" los archivos para evitar los puntos de fallas, es decir si se
perdiera un archivo de Redo Log habra otro que contendra la informacin y que permitiera la recuperacin de la base de datos.
Los redo log se utilizan de forma circular, mediante grupos de archivos. Por defecto la base de datos Oracle genera 3 grupos de archivos.
Se considerar el grupo current (actual) aquel donde se est utilizando para escribir las transacciones actuales de la base de datos.
Se considera un grupo active (activo), aquel que no es el actual y que posea transacciones cuyos cambios no se han hecho permanentes
en los archivos de datos e inactivo aquel que contenga transacciones que han sido completamente escritas a disco, finalmente tambin
se puede tener que un grupo de redo log est limpio porque nunca haya sido escrito.
Los archivos de redo log trabajan de forma circular porque se sobrescriben, generalmente con los tres grupos se tendr que uno de ellos
se encontrar activo, el siguiente en enumeracin ser el actual y el siguiente estar inactivo listo para que se escriba en l. Una vez
llenado el grupo actual se comenzar a escribir en el inactivo, que ahora ser el actual, el que anteriormente era el actual pasar a ser
activo si an no se han escrito todas sus transacciones a disco y eventualmente el que inicialmente estaba activo pasar a ser inactivo y
permitir que al llenarse el grupo actual se escriban las transacciones en l.
Si se llenara el grupo actual de los archivos de redo y el resto de los grupos se encontraran activos, la base de datos no permitira
ninguna transaccin hasta que se escriban todas las transacciones a disco del siguiente grupo de redo log y que este quedase
inactivo. Cuando se trabaja con una base de datos en modo ARCHIVELOG, antes de sobrescribir el archivo se hace una copia de ese
grupo de redo log al destino de los archivos.
Checkpoint Process (CKPT)
El CKPT lleva a cabo un checkpoint, entendindose como tal a la escritura parcial o completa de los buffers de memoria a disco. El CKPT
no es el responsable de escribir los bloques a disco, para ello llama al DBWn y como en esa escritura podran almacenarse en disco
buffers de transacciones no comprometidas el CKPT tambin llama al LGWR para que registre en los redo log files esta escritura que
permita generar los segmentos de undo de transacciones no comprometidas cuando se realice una recuperacin incompleta. Tambin
si en la escritura del checkpoint hay transacciones que no se haban terminado de escribir en disco se escriben, se actualiza la cola
de transacciones activas y un grupo de redo log que estaba activo podra pasar a inactivo.
Cuando un checkpoint ocurre, Oracle debe actualizar todas las cabeceras de los archivos de datos con los detalles del checkpoint, sta
es una tarea del CKPT.
System Monitor Process (SMON)
El proceso SMON lleva a cabo la recuperacin, si es necesaria, de la instancia en el inicio de la misma, es decir rehacer cualquier
transaccin comprometida en el redo log file que no haya sido escrita a disco. SMON tambin es responsable de limpiar los
segmentos temporales que no estn en uso por algn tiempo y de desfragmentar si cree oportuno alguna zona de los discos.
Process Monitor (PMON)
PMON lleva a cabo procesos de recuperacin cuando un proceso de usuario falla. Es responsable de la limpieza del buffer cach,
tambin de deshacer los cambios que se hayan hecho desde el ultimo commit y de la liberacin de recursos que el proceso estaba
usando. Por ejemplo este restaura el status de la tabla de transacciones activas, libera los locks y remueve el ID del proceso de la lista
de procesos activos, asociados a un proceso usuario que pudo haber perdido la conexin de red.
Recoverer (RECO)
Este proceso solo se observa cuando la base de datos ejecuta la opcin distribuida de Oracle. La transaccin distribuida es una en la
que dos o ms emplazamientos de datos deben mantenerse sincronizados, Por ejemplo cuando se tiene una copia de los datos en
diferentes ciudades y por fallas en una lnea telefnica se pierde una transaccin en la mitad de su actualizacin. El proceso
recuperador entonces resuelve las transacciones que hayan quedado inconsistentes en las dos ciudades.
Archiver Processes (ARCn)
El ARCn copia los archivos de redo log llenos a un espacio de almacenamiento distinto para no perderlos al ser sobreescritos. El ARCn
slo est habilitado cuando la base de datos est en el modo ARCHIVELOG. En Oracle 10g para colocar la base de datos en modo
archive basta con colocarla en modo ARCHIVELOG y especificar los destinos de "archive". En Oracle 9i se distingua entre el "archive"
manual y automtico. Con "archive" manual el DBA deba ordenar hacer la copia de los redo log a los "archives", en el modo automtico
se copiaban automticamente antes de ser sobrescritos. En Oracle 10g al poner una base de datos en modo ARCHIVELOG
automticamente se coloca en el modo automtico.
Lock (LCKn)
Es un proceso opcional, configurado para manejar los bloqueos entre bases de datos Oracle cuando estas se encuentran en distintos
computadores y compartiendo el mismo conjunto de discos (es decir en modo servidor en paralelo).
Job Queue (SNPn)
Es un proceso opcional, que se encarga de planificar los procesos que se deben ejecutar y asegurar que todos deben de terminar en
algn momento.
Oracle
512
MySQL
512
MB
MB
Memoria virtual
1024
MB
1024
MB
1.5
GB
4 GB
1 GB
Sin
limite
La regla general para determinar el tamao de la memoria virtual depende del tamao de memoria RAM instalada. Si su sistema tiene
menos de 4 GB de RAM por lo general el espacio de intercambio debe ser de al menos dos veces este tamao. Si usted tiene ms de 8
GB de memoria RAM instalada puede considerar usar el mismo tamao como espacio de intercambio. Cuanta ms memoria RAM
tenga instalada, es menos probable usar el espacio de intercambio, a menos que tenga un proceso inadecuado.
2.1.4 Instalacin del Software de Base de Datos en ModoTransaccional
Debido al constante crecimiento de datos que generan las empresas hoy en da, se ha vuelto muy necesaria la bsqueda de
nuevas plataformas para almacenar y analizar la informacin, ambientes que consuman menos recursos, que sean ms escalables y
que provean una alta disponibilidad. La solucin consiste en el procesamiento paralelo de los datos de una base de datos.
Una base de datos en modo transaccional significa que la BD ser capaz de que las operaciones de insercin y actualizacin se hagan
dentro de una transaccin, es un componente que procesa informacin descomponindola de forma unitaria en operaciones
indivisibles, llamadas transacciones, esto quiere decir que todas las operaciones se realizan o no, si sucede algn error en la operacin
se omite todo el proceso de modificacin de la base de datos, si no sucede ningn error se hacen toda la operacin con xito.
Una transaccin es un conjunto de lneas de un programa que llevan insert o update o delete. Todo aqul software que tiene un log
de transacciones (que es la "bitcora" que permite hacer operaciones de commit o rollback), propiamente es un software de BD; aqul
que no lo tiene (v.g. D-Base), propiamente no lo es. Todo software de base de datos es transaccional; si el software de la BD no
es "transaccional", en realidad NO es un "software" de BD; en todo caso, es un software que emula el funcionamiento de un
verdadero software de BD. Cada transaccin debe finalizar de forma correcta o incorrecta como una unidad completa. No puede acabar
en un estado intermedio.
Se usan los siguientes mtodos:
Y depende que base de datos uses para efectuar las operaciones pero, es la misma teora para cualquier BD.
Instalacin de MySQl en Windows 7
1. Comprobar que no existe una versin anterior, si existe desinstalarla.
2. Descargar el archivo de instalacin, en nuestro caso MySQL Enterprise.
3. Ejecute el archivo:
6. Es este punto se configura como se comportar nuestro servidor y el servicio. Adems se descargan e instalan los paquetes
necesarios.
7. Ahora proceda a configurar MySQL Workbench; es una herramienta visual de diseo de bases de datos que integra desarrollo
de software, administracin de bases de datos, diseo de bases de datos, creacin y mantenimiento para el sistema de base de
datos MySQL. Es el sucesor de DBDesigner 4 de fabFORCE.net, y reemplaza el anterior conjunto de software, MySQL GUI Tools
Bundle.
En MySQL 5.x se soporta por defecto el modo transaccional mediante el motor InnoDB
Dos recursos basados en disco muy importantes que gestiona el motor de almacenamiento InnoDB son sus archivos de datos de
espacios de tablas y sus archivos de registro (log).
Si no se especifican opciones de configuracin para InnoDB, MySQL 5.0 crea en el directorio de datos de MySQL un archivo de datos
de 10MB (autoextensible) llamado ibdata1 y dos archivos de registro (log) de 5MB llamados ib_logfile0 e ib_logfile1.
2.1.5 Variables de Ambiente y Archivos Importantes para Instalacin
Variable: Es un espacio en memoria al cual se le da un nombre Hay variables especficas que se crean al momento de entrar al
sistema, pero tambin hay variables que pueden ser definidas por el usuario. Las variables son una forma de pasar informacin a
los programas al momento de ejecutarlos.
Variables de Ambiente: Se usan para personalizar el entorno en el que se ejecutan los programas y para ejecutar en forma correcta
los comandos del shell.
Toman su valor inicial generalmente de un archivo .profile, pero hay veces en que el usuario tiene que modificar los valores de alguna
variable de ambiente cuando est tratando de instalar o ejecutar un nuevo programa
A continuacin se comentan las opciones ms utilizadas de la seccin mysqld (afectan al funcionamiento del servidor MySQL), se
almacenan en el archivo my.cnf (o my.ini)
basedir = ruta: Ruta a la raz MySQL
console: Muestra los errores por consola independientemente de lo que se configure para log_error.
datadir = ruta: Ruta al directorio de datos.
default-table-type = tipo: Tipo de la Tabla InnoDB o, MyISAM.
flush: Graba en disco todos los comandos SQL que se ejecuten (modo de trabajo, sin transaccin).
general-log = valor: Con valor uno, permite que funcione el archivo LOG para almacenar las consultas realizadas.
general-log-file = ruta: Indica la ruta al registro general de consultas.
language: Especifica el idioma de los lenguajes de error, normalmente esots archivos de lenguaje, estn bajo /usr/local/share.
log-error = ruta: Permite indicar la ruta al registro de errores.
log = ruta: Indica la ruta al registro de consultas.
long-query-time = n: Segundos a partir de los cuales una consulta que tardes ms, se considerar una consulta lenta.
og-bin = ruta: Permite indicar la ruta al registro binario.
pid-file = ruta: Ruta al archivo que almacena el identificador de proceso de MySQL.
port = puerto: Puerto de escucha de MySQL.
skip-grant-tables: Entra al servidor saltndose las tablas de permisos, es decir todo el mundo tiene privilegios absolutos.
skip-networking: El acceso a MySQL se har solo desde el servidor local.
slow-query-log = 0|1: Indica si se hace LOG de las consultas lentas.
slow-query-log-file = ruta: Ruta al archivo que hace LOG de las consultas lentas.
socket = ruta: Archivo o nombre de socket a usar en las conexiones locales.
standalone: Para Windows, hace que el servidor no pase a ser un servicio.
user = usuario: Indica el nombre de usuario con el que se iniciar sesin en MySQL.
tmpdir = ruta: Ruta al directorio para archivos temporales.
Archivos LOG en MySQL
Hay cuatro registros (logs):
Registro de Errores (Error Log): Indica cuando arranc y se detuvo el servidor. Se graba por defecto en la carpeta de datos de
MySQL (archivo host_name.err, donde host_name es el nombre del servidor), pero la variable de sistema log_error permite indicar otra
ruta si fuera necesario.
Registro General de Consultas (General Log File): Est en la carpeta de datos de MySQL, salvo que se indique la variable
general-log-file. Contiene las consultas realizadas. Es el archivo host_name.log.
Registro Binario (Binary Log): Registra instrucciones DML. Los archivos binarios se almacenan por defecto en el directorio de datos.
Sirve para intentar restaurar una base de datos en caso de desastre. Es binario, por lo que su manejo es complicado, para ver el
contenido se usa la utilidad mysqlbinlog de esta forma: mysqlbinlog archivoLOG
Registro de Consultas Lentas (Slow Query Log File): Registra las consultas que tardaron ms del tiempo mnimo establecido. El
archivo est (salvo quese especifique slow-log-file como parmetro) en la carpeta de datos de MySQL con el nombre host_name-slow.log
2.1.6 Procedimiento General de Instalacin de un DBMS
MySQL Enterprise Edition
MySQL Enterprise Edition incluye el conjunto ms completo de caractersticas avanzadas y herramientas de gestin para alcanzar los
ms altos niveles de escalabilidad, seguridad, fiabilidad y tiempo de actividad. Reduce el riesgo, costo y complejidad en el
desarrollo, implementacin y administracin de aplicaciones crticas de negocio MySQL.
El MySQL Enterprise incluye las siguientes opciones:
Backup: Realiza copias de seguridad de bases de datos MySQL en lnea, de los subconjuntos de tablas InnoDB, y la recuperacin
mediante puntos de restauracin.
Alta Disponibilidad: es proporcionada con soluciones certificadas que incluyen replicacin de MySQL.
Escalabilidad: permite alcanzar el rendimiento sostenido y la escalabilidad de cada vez mayor de usuarios, consulta, y las cargas de
datos
MySQL Enterprise Security: Proporciona listas para utilizar los mdulos de autenticacin externos para integrar fcilmente
las infraestructuras existentes de seguridad, incluyendo Pluggable Authentication Modules y el directorio activo de Windows
MySQL Enterprise Monitor: supervisa continuamente su base de datos y de forma proactiva le asesora sobre cmo implementar las
Cada vez que veo la pantalla de la GNU GPL me lleno de felicidad. No slo por las condiciones y el precio: es adems, para m, una
garanta de profesionalidad.
Una vez instalado MySQL, la siguiente fase es la configuracin del servidor en s mismo. Asegrate de que la marca Launch the
MySQL Instance Configuration Wizard est activa.
Optamos por Detailed Configuration, de modo que se optimice la configuracin del servidorMySQL.
Ha llegado un momento crucial. Dependiendo del uso que vayamos a darle a nuestro servidor deberemos elegir una opcin u otra, cada
una con sus propios requerimientos de memoria. Puede que te guste la opcin Developer Machine, para desarrolladores, la ms apta
para un uso de propsito general y la que menos recursos consume. Si vas a compartir servicios en esta mquina, probablemente
Server Machine sea tu eleccin o, si vas a dedicarla exclusivamente como servidor SQL, puedes optar por Dedicated MySQL Server
Machine, pues no te importar asignar la totalidad de los recursos a esta funcin.
De nuevo, para un uso de propsito general, te recomiendo la opcin por defecto, Multifunctional Database.
InnoDB es el motor subyacente que dota de toda la potencia y seguridad a MySQL. Su funcionamiento requiere de unas tablas e
ndices cuya ubicacin puedes configurar. Sin causas de fuerza mayor, acepta la opcin por defecto.
Esta pantalla nos permite optimizar el funcionamiento del servidor en previsin del nmero de usos concurrentes. La opcin
por defecto, Decision Support (DSS) / OLAP ser probablemente la que ms te convenga.
Deja ambas opciones marcadas, tal como vienen por defecto. Es la ms adecuada para un uso de propsito general o de aprendizaje,
tanto si eres desarrollador como no. Aceptar conexiones TCP te permitir conectarte al servidor desde otras mquinas (o desde la
misma simulando un acceso web tpico).
Hora de decidir qu codificacin de caracteres emplears, salvo que quieras empezar a trabajar con Unicode porque necesites
soporte multilenguaje, probablemente Latin1 te sirva (opcin por defecto).
Instalamos MySQL como un servicio de Windows (la opcin ms limpia) y lo marcamos para que el motor de la base de datos arranque
por defecto y est siempre a nuestra disposicin. La alternativa es hacer esto manualmente.
Adems, me aseguro de marcar que los ejecutables estn en la variable PATH, para poder invocar a MySQL desde cualquier lugar en la
lnea de comandos.
MySQL
MySQL soporta varios motores de almacenamiento que tratan con distintos tipos de tabla. Los motores de almacenamiento de
MySQL incluyen algunos que tratan con tablas transaccionales y otros que no lo hacen:
MyISAM: trata tablas no transaccionales. Proporciona almacenamiento y recuperacin de datos rpida, as como posibilidad de
bsquedas fulltext. MyISAM se soporta en todas las configuraciones MySQL, y es el motor de almacenamiento por defecto a no ser
que tenga una configuracin distinta a la que viene por defecto con MySQL.
El motor de almacenamiento MEMORY proporciona tablas en memoria. El motor de almacenamiento MERGE permite una coleccin de
tablas MyISAM idnticas ser tratadas como una simple tabla. Como MyISAM, los motores de almacenamiento MEMORY y MERGE
tratan tablas no transaccionales y ambos se incluyen en MySQL por defecto.
Nota: El motor de almacenamiento MEMORY anteriormente se conoca como HEAP.
Los motores de almacenamiento InnoDB y BDB proporcionan tablas transaccionales. BDB se incluye en la distribucin binaria
MySQL-Max en aquellos sistemas operativos que la soportan. InnoDB tambin se incluye por defecto en todas las distribuciones binarias
de MySQL 5.0. En distribuciones fuente, puede activar o desactivar estos motores de almacenamiento configurando MySQL a su gusto.
El motor de almacenamiento EXAMPLE es un motor de almacenamiento 'tonto' que no hace nada. Puede crear tablas con este motor,
pero no puede almacenar datos ni recuperarlos. El objetivo es que sirva como ejemplo en el cdigo MySQL para ilustrar cmo escribir
un motor de almacenamiento. Como tal, su inters primario es para desarrolladores.
NDB Cluster es el motor de almacenamiento usado por MySQL Cluster para implementar tablas que se particionan en varias
mquinas. Est disponible en distribuciones binarias MySQL-Max 5.0. Este motor de almacenamiento est disponible para Linux, Solaris, y
Mac OS X. Los autores mencionan que se aadir soporte para este motor de almacenamiento en otras plataformas, incluyendo Windows
en prximas versiones.
El motor de almacenamiento ARCHIVE se usa para guardar grandes cantidades de datos sin ndices con una huella muy pequea.
El motor de almacenamiento CSV guarda datos en archivos de texto usando formato de valores separados por comas.
El motor de almacenamiento FEDERATED se aadi en MySQL 5.0.3. Este motor guarda datos en una base de datos remota. En esta
versin slo funciona con MySQL a travs de la API MySQL C Client. En futuras versiones, ser capaz de conectar con otras fuentes de
datos usando otros drivers o mtodos de conexin clientes.
La versin 5 de MySQL crea por defecto tablas InnoDB que permiten el manejo de integridad referencial, transacciones. Al igual que
las tablas regulares de Oracle. Para saber si el gestor de base de datos de MySQL que tenemos las soporta es necesario ejecutar la
siguiente sentencia.
SHOW VARIABLES like '%innodb%';
Comando Describe
MySQL proporciona este comando que resulta til para conocer la estructura de una tabla, las columnas que la forman y su tipo y
restricciones. La sintxis es la siguiente:
DESCRIBE nombre Tabla.
DESCRIBE f1;
Comando SHOW TABLES y SHOW CREATE TABLE
El comando SHOW TABLES muestra las tablas dentro de una base de datos y SHOW CREATE TABLES muestra la estructura de
creacin de la tabla.
Tablas Temporales
Las tablas temporales solo existen mientras la sesin est viva. Si se corre este cdigo en un script de PHP (Cualquier otro lenguaje), la
tabla temporal se destruir automticamente al trmino de la ejecucin de la pgina. Si no especfica MEMORY, la tabla se guardar
por defecto en el disco.
CREATE TEMPORARY TABLE temporal (
ife INTEGER (13) PRIMARY KEY,
nombre CHAR (30) NOT NULL UNIQUE
);
Este tipo de tabla solo puede ser usada por el usuario que la crea.
Si creamos una tabla que tiene el mismo nombre que una existente en la base de datos, la que existe quedar oculta y trabajaremos
sobre la temporal.
Tablas Memory (Head)
Se almacenan en memoria
Una tabla head no puede tener ms de 1600 campos
Las tablas MEMORY usan una longitud de registro fija.
MEMORY no soporta columnas BLOB o TEXT.
MEMORY en MySQL 5.0 incluye soporte para columnas AUTO_INCREMENT e ndices en columnas que contengan valores NULL.
Las tablas MEMORY se comparten entre todos los clientes (como cualquier otra tabla no-TEMPORARY).
CREATE TEMPORARY TABLE temporal (
ife INTEGER (13) PRIMARY KEY,
nombre CHAR (30) NOT NULL UNIQUE
) ENGINE = MEMORY;
Modificacin
Esta operacin se puede realizar con el comando ALTER TABLE. Para usar ALTER TABLE, necesita permisos ALTER, INSERT y
CREATE para la tabla. La sintaxis para MySQL es
ALTER [IGNORE] TABLE tbl_name
alter_specification [, alter_specification] ...;
alter_specification:
ADD [COLUMN] column_definition [FIRST | AFTER col_name]
| ADD [COLUMN] (column_definition,)
| ADD INDEX [index_name] [index_type] (index_col_name,)
| ADD [CONSTRAINT [symbol]]
PRIMARY KEY [index_type] (index_col_name,)
| ADD [CONSTRAINT [symbol]]
UNIQUE [index_name] [index_type] (index_col_name,)
| ADD [FULLTEXT|SPATIAL] [index_name] (index_col_name,)
| ADD [CONSTRAINT [symbol]]
FOREIGN KEY [index_name] (index_col_name,)
[reference_definition]
| ALTER [COLUMN] col_name {SET DEFAULT literal | DROP DEFAULT}