Ver el código de «Curso de Oracle básico»

Estos son los apuntes que fui cogiendo durante el curso Básico de Oracle que me dieron en Sunion Gesfor. Estos cursos eran gratuitos promovidos por CEIM.

Habrá muchas faltas de ortografía, debido a que los tomé muy rápido y a que yo soy un desastre. :-)

=INTRODUCCIÓN A BASE DE DATOS=

==Trabajando con el lenguaje sql==

Agrupación de sentencias

*DQL (data query languaje): Consultas de base de datos (SELECT)
*DML (data manipulation languaje): Manipulación de datos (DELETE, UPDATE, INSERT, MERGE)
*DDL (data definition languaje): Definicion (CREATE, DROP, ALTER, TRUNCATE)
*DCL (data control languaje): Control de datos (GRANT, REVOKE)
*DVL (data validation languaje): desacer o validar transacciones (COMMIT, ROLLBACK, SAVE POINT)

Una transaccion es un conjunto de operaciones de DML que se agrupan. Una transacción acaba cuando se hace commit o se haga rollback y la siguiente empieza inmediatamente después.

Una transacción tiene que cumplir estas cuatro cosas:

* Atomica: o se hace todo o nada 
* Coherente: que matenga integridad
* Permanente: que se quede registrada en la base de datos
* Aislable: a quien afecte la transaccion lo decida yo

SET TRANSACTION ISOLATION LEVEL {READ COMMITED || SERIALIZABLE}

(ejemplo de la agencia de viajes con dos sucrusales, en las cuales quedan dos plazas par aun viaje, en una va una pareja y compra las dos plazas pero no las pagan, mientras no han pagado en lao tra sucrusal compran los dos billetes...

si es read commited los segundo podrán comprar los billetes
si es serializable, en la segunda compra le dirá que no puede devolverle los datos hasta que los otros hayan cerrado la operación

==MODELOS QUE INTERVIENEN EN EL ESTUDIO DE LOS DATOS==

* MODELO CONCEPTUAL (INFORMACIÓN): Define la información que hace falta
* MODELO LÓGICO (Tablas lógicas): Fase de diseño, definición de las tablas y los datos. Con esto se hace un cuaderno de carga.
* MODELO FÍSICO (Implementación): pasar a SQL

Modelo entidad relación, cogemos los datos y los llevamos a papel. Hay que crear unos graficos donde aparecen las relaciones y de ahí se pasa a crear las tablas lógicas para después crear las sentencias de base de datos. Durante la tercera fáse, que suele ser trabajo del DBA, se puede analizar que tablas son candidatas para hacer optimización de la base de datos.

==PRINCIPALES OBJETOS DE UNA BASE DE DATOS ORACLE==

* Tablas
* Indices
	* B-tree
	* Bitmap
* Clusters
* Vistas
* Vistas materializadas
* Sinónimos
* Procedimientos
* Funciones
* Paquetes
* Trigers
* Secuencias

=INTRODUCCIÓN AL GRID COMPUTING=

Se trata de aprovechar los ciclos de cpu de diferentes máquinas para ejecutar tareas más rápido. 

Esta forma de compartir las aplicaciones debe ser:

* Seguro
* General
* Transparente

Los beneficios son:

* Integrar sistemas y dispositivos heterogeneos. Pej. integrar Mac, con pc, etc
* Mejorar el coste efectivo en Entornos Operativos: no se cambian máquinas, se añaden nuevas.
* Aumentar fiabilidad: no habrá un servidor central, las operaciones son compartidas.
* Potencia ilimitada
* Tener acceso a superordenadores virtuales, el computo global.

Se basa en un software denominado middleware que se encargfa de las comunicaciones transparentes entre los dispositivos. Uno de los elementos que aparecen es el motor de búsqueda que hace las siguientes tareas:

* Buscar datos que necesite un usuario
* Utiliza las herramientas para analizar los resultados
* Dispone de una potencia de cálculo (que procesadores puede usar)
* Unifica una respuesta.

Los estandares de GRID son desarrollados por OFG (open grid Forum)

Hay una implementacion libre desarrolada por GLOBUS PROJECT en java, que proporciona librerías servicios web y apis para implementar un grid, basado en java.

==ORACLE EN EL GRID==

Oracle 10g es la primera infraestrucutra grid que apareció (de un fabricante propio). Sigue todo el estandar de OGF. Dentro de 10G se puede encontrar

Oracle database 10g
Oracle Application server 10g
Enterprise manager 

Tambien otras aplicaciones externas se pueden integrar dentro del grid de oracle 10g.

No viene de serie con la base de datos, hay que bajarselo de la web. Gestor de GRID. Se llama Enterprise Grid computing.

Puede trabajar con un gran número de elementos. La forma de creación de egc se basa en dos elementos básicos:

*ONE from MANY: coordina un conjunto de máquinas (oracle lo llama cluster de máquinas) bajo una entidad única. Permite distribuir el trabajo a través de cada una de las máquinas, colcando ratios, ponderaciones, etc. Da la posibilidad de añadir quitar o cambiar cualquier tipo de elemento en plan online: servidor, almacenamiento, etc siempre y cuando sea compatible.

*manage MANY as ONE: manejar muchos como uno. Desde una sola consola puedo manejar todos y cada uno de los elementos que tiene este entorno: máquinas, discos, etc. 

==FRAMEWORK DE GESTION==

1. Instancia (de db, de servidor de aplicaciones,...)
2. Listener
3. Interfaces de gestión

3. Pueden ser de 2 tipos:

* OEM GRID CONTROL: para poder trabajar de forma unificada. Es la consola de trabajo de un entorno grid
* OEM DATABASE CONTROL: para trabjar con una instancia, de lo que sea, db, aplicacion, etc.

El em es el OEM DATABASE CONTROL de oracle database 10g.

Si montaramos el grid computing lo que habría que hacer para trabajar con todo el grid es usar el OEM GRID CONTROL.

En este curso solo vamos a usar el OEM DATABASE CONTROL.


=ARQUITECTURA DE ORACLE 10G=

* instancia y base de datos
* Arquitectura de la instancia
* Memoria
* procesos
* Ficheros

La arquitectura de oracle se divide en tres partes: Memoria, Procesos y Estructrura de disco. Lo que oracle llama instancia es el conjunto de procesos más memoria. Base de datos es pues, las estructuras de disco (los ficheros)

Estos tres elementos no pueden ir por separado. La relación es que una instancia va a trabajar con una base de datos. La excepción es cuando se trabaja con RAC. En rac n instancias pueden trabajar con una base de datos, y rac es eso, es decir, que controla las escrituras de los procesos de las diferentes instancias para que no se pisen.

La instancia, con su memoria y sus procesos proporciona los mecanismos para acceder a la base de datos. Pueden ser mecanismos de muchos tipos. Desde ahí se arranca y para la db. Una DB no puede ser accedida si no está levanta la instancia. No se puede trabajar con una instancia a la vez por base de datos, a excepcion de rac. Los procesos de la instancia se llamana procesos de background, y son los procesos que trabajan con los ficheros (base de datos)

Cuando se levanta una instancia tiene cierta cantidad de memoria que necesita, si esta cantidad de memoria no está disponible la instancia no se levanta. En las instancias no se incluyen ningún tipo de ficheros, ni db, ni redolog, ni ficheros de control... ningún fichero.

Lo que hay en cada una de las partes:

MEMORIA
	Area de sw + kernel de oracle
	Area global del sistema SGA
	Area global de procesos PGA

PROCESOS
	Procesos Oracle
	Conexiones
	Sesiones
	Procesos de usuario

ESTRUCTURA DE DISCO
	Ficheros de datos
	Ficheros de control
	Ficheros Redo Log


==MEMORIA==

Esta se utiliza para que oracle guarde información de elementos utilizados dentro de la DB. Ahí se guardan datos sobre las sentencias ejecutadas, sesiones, resultados, etc. Todo se intenta hacer en memoria. 

La memoria la divide en cuatro partes. Cuando levanta una instancia la memoria que tiene que coger lo dice el fichero de configuración. Si no puede coger la memoria especificada da error y no levanta.

La primera parte es una parte general, la de kernel, solo se coge una vez.

Después cge una cona SGA

La zona PGA

Y la work Area

El tamaño de cada una de estas zonas está definido en el fichero de configuración de la instancia. Por cada instancia habrá una SGA, una PGA y una work Area.


===SGA===

Es una zona de memoria básica, porque es donde estan todos los datos obtenidos por consultas por escrituras por updates de todas las sesiones de esa instancia. Además va a contener toda la información de la base de datos.

Por lo tanto, la configuración de esta memoria es primordial para tener buenos o malos rendimientos. Por cada instancia hay una zona de SGA y en cada zona habrá las siguientes subzonas:

* shared pool
* streams pool
* large pool
* java pool
* Database buffer cache
* Redo log 
* ¿? todavía no lo ha contado...


El tamaño máximo que puede coger una sga es el indicado el fichero de arrance por el parametro sga_max_size. Este parámetro no se puede cambiar en caliente. Si hay que cambiarlo hay que parar la instancia, ir a los ficheros de inicialización modificarlos y levantar la instancia. Esto es lo que se llama un cambio estatico

Como saber el tamaño de la SGA actualmente? consultando la vista v$sga

SGA_TARGET, es un nuevo parámetro que hay en la verisón 10g y que le dice el tamaño máximo que puede gestionar el oracle para el SGA de forma automática. Esto es más bien para la gestión automática del tamaño de las subzonas que tiene SGA. Por norma general el tamaño de esta variable es igual al parametro SGA_MAX_SIZE. Si el valor es difernte de cero la gestión la hace él, si es cero la gestionamos nosotros.

El SGA_TARGET solo afecta a cutaro de las subzonas de memoria de la SGA, que son data buffer cache, shared pool, large pool y java pool, que son las zonas que se pueden camiar en caliente. En cambio, no afecta a log buffer, db_keep, db_recycle, stream, others,... solo a esas cuatro.

El parametro SGA_TARGET hace cambio dinámico, es decir, que no hace falta para la instancia para hacer la modificación.

Ejemplo:

SGA_TARGET=400mb
SGA_MAZ_SIZE=400mb

y tenemos definidos los siguientes parámetros

log_buffer=1mb
db_keep_cache=100mb

El tamaño real que va a gestionar oracle de forma autmática son los 400mb menos la suma de los parametros de las subareas estáticas, como las que hemos definido en los parámetros. 

Si el SGA_TARGE fuera cero tendríamos definir los parametros para cada subarea, y si no es así fallaría al levantar la instancia.

Cuando se trabaja con la gestión automática (sga_target > 0) los valores de los tamaños de los buffers y pool modificables aparece en cero.

Hay una vista para saber los tamaños reales que tiene cada una de las zonas de memoria. Esta vista es v$sga_dynamic_components. Ahí está almacenado de forma dinámica el tamaño que tienen los cuatro elementos modificables de forma dinámica.

El tamaño para determina la SGA, esas zonas, se trabaja con los siguientes parámetros:

db_cache_size
log_buffer
shared_pool_size
large_pool_size
java_pool_size
streams_pool_size
db_block_size

El tamaño de esos parametros, la suma, es el tamaño mínimo para asignar al tamaño total de SGA.

====CARACTERISTICAS DE LA SGA====

Las zonas que aparecen en la sga son:

4 de ellas son obligatorias, y el resto son prescindibles. Las obligatorias son:

data buffer cache
redo log buffer
shared pool
others (mezcla de informaciones)

las opcionales:

large pool
java pool
streams pool

Desde oracle 9i se pueden cambiar algunas de estas zonas de tamaño en caliente. En oracle 10g las que se pueden cambiar en caliente son:

data buffer cache
shared pool
large pool
java pool

El tamaño máximo de esas zonas viene determinado por el parámetro SGA_MAX_SIZE, si el SGA_TARGET está definido a cero (gestión automática de memoria)

====Zonas de la SGA====

·DATA BUFFER CACHE

En esta zona se tiene una copia de todos los bloques que oracle ha consultado en los ficheros, de todas las sessiones de la base de datos. Como esta zona es finita, en algún momento hay que vaciarla, para lo cual gestiona esos datos mediante un algoritmo LRU, los datos menos usados se borran.

En realidad dentro de este buffer hay una serie de bloques, donde va guardando datos de tablas, segmentos, etc. Estos minibuffers "se mueven de dereccha a izq". si un dato es consultado ese minibuffer se mueve a la zona de datos más usados, y desplaza al resto. De esa forma, los bloques menos accedidos se eliminan más rápidamente. 

En esta zona se trabaja siempre con bloques del tamaño que se especifica en las variables de inicio de la instancia. El parametro es el db_block_size. Este parametro no se puede cambiar más que cuando se crear la base de datos. Dependiendo del tipo de uso que vamos a hacer de la base de datos habrá que dar un tamaño de bloque, OLTP bloques pequeños 8kb, datawharehouse bloques grandes 32kb.

para cambiar el tamaño del data buffer cache se usa la siguiente instrucción:

alter system set db_cache_size=X[k|m|g]

Si lo haces más pequeño libera la memoria directamente. 

·REDO LOG BUFFER CACHE

Contiene la información de todas las operaciones realizadas en la base de datos. Es un histórico de operaciones. En el se guardan cualquier operacion excepto, las de select, nologins, y las cargas masivas (en imporatciones).

La información que se guarda aqui es para recuperar la base de datos cuando hay algún fallo, sinó nunca se utiliza.

Es finito, cuando se llena, un proceso de los de oracle, lo guarda a disco, lo libera y sigue escribiendo como siempre. Esto lo hace cuanso se cumplen ciertas caracteristicas que no se han contado en este curso.

El tamaño de este buffer se define con el parámetro LOG_BUFFER, es un parámetro estatico, con lo cual hay que definirselo en el arranque, no se puede modificar en caliente. Un tamaño alto hace que las entradas a disco tarden más, pero un tamaño pequeño hace que haya muchas entradas a disco. En versiones anteriores recomendaba cuatro veces el tamaño de bloque. En la instalación que tenemos en el curso son 2m. Si hay muchas escrituras en la base de datos se puede aumentar ... 4 - 16M para que no haya muchas escrituras a disco.

·LARGE POOL

zona opcional

configurada para servidores compartidos almacena la informaicón de las conexiones entre los procesos de usuario , dispacher, servidores, rman

libera la carga de las areas shared pool

determina su tamaño por la variable LARGE_POOL_SIZE

alter system set large_pool_size=n[m/g]

es una zona que se puede cambiar en caliente.

·JAVA POOL

es una zona de memoria opcional

es un area utilizad cuando tenemos aplicaciones que van a ejecutar procedimientos JAVA.

Oracle utiliza JAVA para sus APIS, por lo que es considerada zona "obligatoria"

Su tamñao viene determinado por el parametro JAVA_POOL_SIZE

Es dinámica, se puede cambiar en caliente. Esto es algo nuevo en la versión 10g, en la 9i esto no era así.

·STREAMS POOL

Es opcional. es utilizada como zona de intermediacion entre servidores paralelos cuando estamos trabajando con streams (flujos de trabajo). Esto ya se utilizaba en 9i pero no había una zona de memoria propia. En caso de no estar definida se utiliza la shared pool para estos procesos en STREAM. 

Se define mediante el parametro STREAMS_POOL_SIZE.

Hay algunas versiones de 10g se pueden cambiar de forma dinámica (el tamaño). El profe cree que es la 10.0.3

·SHARED POOL

Contiene la información acerca de las últimas sentencias sql ejecutadas, y la definición de datos usados. Cuanso se lanza una setnencia sql o una función pl/sql ha de trabajar con una definición de datos, y esta se guarda en esta zona de memoria. 

A parte de esto se guarda tambien información sobre planes de ejecución, privilejios, constrainsts, primary keys, etc.

Ocurre lo mismo que en data buffer cache, cuando necesita guarda algo y no tiene espacio quita los datos menos usados (mas antiguos) y guarda la nueva estrcutrua que necesita para trabajar.

Esta zona tambien es dinámica en caliente, está definida con la variable SHARED_POOL_SIZE. Se modifica con:

ALTER SYSTEM SET SHARED_POOL_SIZE=n[M|G]

Dentro de la shared pool se divide en dos subzonas

*biblioteca
*Cache de diccionario de datos (antememoria del diccionario de datos)

En la primera tenemos las consultas SQL y PL/SQL que se han ejecutado. Si vemos cada una de esas consultas vemos que está dividia en dos partes, una que es el area comparitda y otra el area privada.

El area copmartida almacena la sentencia realizada y el plan de ejecución, también va a tener el tamaño en función de la sentencia.

El area privada va a tener datos como información acerca de viariables y los buffers en tiempo de ejecución. También tendrá el tiempo empleado en ejecutar la sentencia.

En segunda subzona de la shared pool, la cache de diccionario de datos, se almacena la estructura de la tabla sobre la que hacemos consulta, insertamos, modificamos, etc. Son los objetos utilizados o referenciados por las diferentes sentencias de sql o pl/sql. Esto es así para saber que usuario ha lanzado la tabla, que datos tiene que recuperar, si el usuairo tiene privilegios, etc... 

El algoritmo de liberación de memoria de estas dos subzonas son diferentes, los LRU, así que puede suceder que tengamos en la cache de la biblioteca una sentencia cuyos objetos referenciados no estén en la cache de diccionario de datos. Esto es una de las cosas que en tuning hay que evitar.

EL DICCIONARIO DE DATOS son todos las tablas o vistas que hay en la base de datos. Este diccionario, dependiendo de que usario, tendrá más o menos objetos. Hay muchas tablas o vistas del diccionario de datos, como son USER_TABLES, ALL_TABLES y DBA_TABLES.

Una curiosa es la sys.syscatalog que que contiene un registro por cada tabla o vista del sistema. Asi, si quisieramos buscar una tabla de gestión de usuarios, podriamos hacer:

select tname from sys.syscatalog where tname like '%USER%';

La diferencia en estas tablas USER_ ALL_ Y DBA, es que:

USER: todas los objetos del usuario que está haciendo la consulta
ALL: todas los objetos del usuario más los objetos de otros usuarios que son públicos o que tiene permisos
DBA: todo lo anterior más los objetos propios del sistema.

·OTHERS

Es una zona de memoria donde se van a almacenar diferentes objetos. Guarda objetos para la cual no tiene una zona de memoria definiza. Se guardan estrcuturas que entre si no tienen nada que ver pero que en algun sitio hay que almacenarla. Esta no es dimensionable.


===PGA (Proces Global Area)===

Es el area de memoria donde se almacenan los procesos. En esta zona vamos a contener toda la información de control y de datos realcionados con todos los procesos que itervienen.

Los procesos que aparecen aqui pueden ser:

* procesos de servidor
* procesos de background.

Realmente, la pga no es como la sga. Aqui por cada proceso vamos a contener una parte de memoria. A la suma de todas esas partes de memoria asignada a cada proceso se le denomina PGA. Cada proceso servidor tiene su PGA. 

Los procesos de servidor, la memoria la cogen cuando es creado ese proceso, y es destruida cuando ese proceso finaliza.

Los procesos de background son propios de oracle y se crean cuando la instancia se levanta y se eliminan cuando la instancia se apaga.

Una PGA esta estructurada en:

SQL AREA
Memoria de sesion
Area de trabajo

el SQL Area contiene datos exclusivos de esta pga como información de acoplamiento(BIND), estructuras de memoria usada, etc
la memoria de session tiene los variables propias de la sesion y datos propios de la sesion
el area de trabajo puede que no esté, y es una zona interna para realizar trabajos propios de la sesión como ordenaciones, group by, bitmaps, etc. Es configurable mediante el parámetro PGA_AGGREGATE_TARGET.

Por cada usuario conectado hay un proceso de servidor con una PGA. Pero puede ser que otro cliente trabaje con el mismo proceso servidor. cuando un proceso servidor puede atender a más de un cliente se denomina p.s.compartido.

Para sacar la memoria total de la PGA se puede saber sumando el campo PGA_USED de la tabla v$process y de la tabla v$bgprocess. En esta última no viene la memoria, habría que buscar más datos en algunas tablas. Tambien un compi de curso ha encontrado la siguiente instrucción:

select  sum(value)/1024/1024 mb from v$sesstat s, v$statname n
where s.statistic# = n.statistic#
and n.name = 'session pga memory'
group by '$ORACLE_SID pga'

pero esta saca el tamaño de memoria usada de unas estadísticas.

Tambien se puede mirar este comando SELECT SUM(ALLOCATED) FROM V$PROCESS_MEMORY; esto me lo he sacado yo

===WORK AREAS===

Tiene cuatro areas

SORT AREA
HASH JOIN
BITMAP MERGE
BITMAP CREATE

la sort area se utiliza para hacer ordenaciones en memoria. Cuantas más ordenaciones parciales haga más tarda la operación (más accesos a disco)

el hash join se utiliza cuando el planificador de trabajo decide usarlo. Cuando ponemos un JOIN, para oracle, hay tres formas de realizarlo. uno de ellos es el hash join. tambien existe el merge join. Me parece a mi que hay que buscar más información sobre esto!!!

Los bitmap son para la utilización de grupos de indices bitmap. Para gestionar estos indices, en vez de hacerlo en disco, lo hace en esta zona de memoria reservada para ello.


Cuando queremos definir estas zonas se utlizan los siguiente parametros:

SORT AREA SIZE
HASH_AREA_SIZE
BITMAP_MERGE_AREA_SIZE
create_BITMAP_AREA_SIZE

Para saber la suma de estos parametros usamos:

SELECT sum(value)/1024/1024 
from V$PARAMETER 
where name='create_bitmap_area_size' 
or name='sort_area_size' 
or name='hash_area_size' 
or name='bitmap_merge_area_size'; 

Sencillo...



PROCESOS DE USUARIO

?????

PROCESOS DE SERVIDOR

Son los intermediarios entre los procesos de usuario y el servidor de oracle

Estos procesos de servidor pueden ser:

- Dedicados (a cada proceso de usuario le corresponde un proceso de servidor
- Compartido

????

Cuando estamos trabajando en un entorno compartido los procesos de servidor se llaman procesos compartidos (shared server processes)

El proceso dispacher coge peticiones, puede haber varios. El dispacher, cuando le llega una petición y la deja en una cola comun. Esa cola es común para los diferentes dispacher, aunque puede haber varias colas. Asignada a esa cola hay una serie de procesos servidores (s01,s02,...). Lo que se hace ahí es cada uno de los elementos de la cola van pasando a uno de los procesos de servidor. Esta cola de petición de dispatcher está en la SGA

Una vez que el proceso servidor coge una petición la ejecuta en la PGA. Dentro de la PGA recibirá los datos y lo dejará en otra cola, asignada a los dispacher, con la respuesta.

Cuando el dispacher detecta que en esa cola hay nuevos datos, la consulta, ve el origen de la peticion y lo envia al usuario que lo ha solicitado. Esa cola de respuesta está en la SGA tambien.

Hay una cola de respuesta para cada dispacher, pero la cola de peticiones puede ser la misma para todos los dispacher. El dispacher es un proceso que tiene pga. 

PROCESOS BACKGROUND

Entre 9i y 10g hay muchos cambios. Hay 5 procesos obligatorios que son:

-SMON recuperación de la instancia
-PMON limpieza y restauracion de procesos erroneos 
-DBwn registro de cambios en la ddbb
-DKPT Actualización de ficheros físicos. puntos de control
-LGWR Actualización de los ficheros redo logs

Los procesos opcionales, que dependen de la configuració que vayamos a montar:

-ARCH Archivado de redo logs
-RECO prevención de fallos entre ddbb distribuidas
-MMAN la gestión autática de la memoria

-MMON y MMNL obtención automática de estadísticas en el AWR   

(dispacher) no se la nomenglatura

-SNNN Procesos de servidores usados por el dispacher


EXPLICACIÓN DE CADA UNO DE LOS PROCESOS OBLIGATORIOS

DBWn (DB Writer)

es el proceso que registra los cambios que se producen en el data buffer a disco, y buscar en los discos y llevarlo al data buffer cuando es necesario.

hace una escritura diferida de forma asincrona. Cuando se valida un dato no hay porqué escribirlo de forma automática, es decir, un insert no se mete directarente a disco

Tambien se encarga de eliminar los bloques menos usuados de la data buffer cache para meter nuevos datos.

Se guarda en los ficheros de base de datos reales cuando el sistema produzca un checkpoint. Cuando el porcentaje del buffer modificado llega a un límite. También puede escribir por un tiempo de espera excesivo.

Esto no quiere decir que ya sea un dato consolidado, podría ir a un segmento de undo, que cabmios realizados pero no validados. 

Al borrar o truncar un segmento (eliminar una tabla o un indice) tambien se guardan datos.

Tambien escribe cuando se ponga un tablespace offline

Tambien cuando se hace un shutdown, excepto cuando se hace un shutdown abort.

DBWn se pone así porque pueden existir varios de estos procesos. Lo normal es uno y solamente se ponen más si hay más procesadores. Con 32 procesadores se podría poner 10dbwn.

LGWR (log writer)

Este se encarga de guardar los buffers de redo log a los ficheros de redo log. Aqui solo existe uno, y no puede existir uno. Así se garantiza la integridad de datos. Lo que se escribe se guarda en una serie de ficheros pero de forma secuencial. Además escribe de forma síncrona, si empieza guardar ya no termina hasta que esté guardados todos. Oracle en si da más importancia a los datos de red log que a los propios datos.

Cuando se haga un commit se guardan los redo log

Cuando el buffer de redo log llega a un tercio de su capacidad

Antes de que el dbwriter escriba o modifique de disco.

Si no se ha cumplido ninguna de esas cada 3 segundos. Esos tres segundos son tiempo de cpu, es decir tiempo de ejecución de proceso en la cpu, lo cual puede ser más tiempo en realidad. 

Este puede escribir en un solo fichero a la vez o en dos si está configurado en espejo

Sobreescribe en los redo log ciclicamente. Si se quiere mantener un log de los red log se puede activar el archive log

SMON (system monitor)

Es el proceso encargado de hacer la recuperación despues de un fallo de instancia. Solamente va a trabajr cuando se arranque la instancia. Es el chequeo que comprueba si la base de datos se hac errado correctamente o no. Una de las cosa que mira es que todos lso ficheros estén sincronizados. Si no lo están el proceso hace la sincronización en dos fases... se ve en el curso 2

Limpia los segmentos temporales no utilizados y fusiona el espacio libre.

PMON (process monitor)

Es el que se encarga de realizar la limpieza y la recuperación de procesos fallidos de servidor ante esconexiones anormales. De esta forma se libera memoria de procesos que no están haciendo nada. 

Periodicamente revisa los procesos de servidor y busca sesiones mal cerradas

Hace el rollback de las transacciones del proceso de usuario que se ha cerrado mal

Libera los recursos de la SGA y los bloqueos adquiridos de la SGA.

Tambien lo podemos hacer de forma manual haciendo kill session en el oracle. Bueno, en realidad, haciendo kill session llama al proceso PMON.

CKPT (Checkpoint)

Realiza la actualización del fichero de control y las cabeceras de los ficheros de datos para reflejar las últimas transacciones grabadas correctarmente (basadas en el SCN actual). coloca un numero, el scn, en el fichero de control y en la cabecera de los ficheros de datos. El scn indica la última transacción correcta.

Este se realiza cuando:

Se valida una transacción
un fichero redo se llena y antes de pasar al siguiente
se hace un shutdown sin abort.
al poner un tablespace offline
cada tres segundos de cpu
lo forzamos (alter system checkpoint)

tambien cuando definimos ciertos parametros
	log_checkpoint_interval
	log_checkpoint_timeout



EXPLICACIÓN DE CADA UNO DE LOS PROCESOS NO OBLIGATORIOS

-ARCH (Archiver)

Coge los ficheros de redo log y los copia a una ubicación diferente. Por norma general es obligatorio cuando la base de datos está en modo archive log. Si está en otro modo no es obligatorio. Esto se hace para securizar esos archivos. Copia el archivo antes de ser sobreescrito por el lgwr. Podemos tener desde uno hasta 10 archivers. Se utilizan para grabar en diferentes ubicaciones.

Para saber si está activado pondemos consultar v$database; y hay un campo log_mode. Tambien se puede mirar poniendo archivelog list como dba o viendo los procesos de v$processes.

-RECO (Recover)

Va a aparecer solamente cuando estamos trabajando con bases de datos distribuidas. Este se encarga de chequear o prevé fallos en transacciones distribuidas.

Intenta acceder a las trasnacciones dudas entre db distribuidas

El proceso slo aparecerá cuando tengamos la opción dsitribuida de Oracle (DISTRIBUTED_TRANSACTION > 0). si no vaoms a usar ningún data base link este parámetro es mejor no tocarlo.

-MMAN (Memory manager)

Procesos encargados de ajustar de forma automática la memoria sga.

-MMON (Memory monitor)

Obtención y analisis de estadísticas AWR

-MMNL (memory monitor ligth)

Obtencio´n y analisis de estadísticas AWR. Estos dos estarán funcionando mientras tengamos activadas las estadísticas.

-Dnnn (Dispatcher)

Asignación de preticiones de los clientes a los diferentes procesos servidores de la instancia.

-Snnn (Shared Server)

Procesos servidores que son copmartidos cuando estamos en entornos servidor compartido.



===FICHEROS===

Oracle los distingue dos clases de ficheros de datos

Los ficheros de base de datos están divididos en tres de base de datos en si, de redo log y de control

Los ficheros de no base de datos son ficheros que tamiben tiene relación con la base de datos pero que no son cruciales para el día a día, son ficheros de parámetros, de passwords, logs archivados, etc. Tambien está ahi incluidos los ficheros de traca, logs, etc...


** FICHEROS DE DATOS
Los ficheros de datos son los que realmente contienen los datos dentro de la base de datos de oracle. En ellos oracle define la estructura lógica. Por norma general su extensión es dbf, y como mínimo en oracle 10g hay dos ficheros de bases de datos, el correspondiente al sys y al sysaux. Otra cosa es que en la instalación se creen más, dependiendo de nuestra organización. El número máximo de ficheros de base de datos que puedo poner en mi db está definido por el parámetro MAXDATAFILES. Este numero es un parámetro de creación y no se puede cambiar después. Esta en la configuración de control que nos contará más adelante.


* FICHEROS DE REDO LOG

Es un historico de operacioines realizado en la base de datos. Estos son rellenado por el LGWR. Lo que hace es que como mínimo voy a tener dos ficheros de redo log para que vaya escribiendo en uno y cuando acabe pueda escribir en otro, y así ciclicamente. No hay un número máximo de ficheros de redo log. 

Cuando se habla de estos ficheros, en realidad se habla de grupos. En vez de crear ficheros individuales crea grupos de ficheros, en cada grupo tiene que habér uno o más ficheros. Así podemos hacer una duplicación de la información, en cada fichero del grupo se guarda lo mismo. Cada vez que escribe en un grupo escribe en todos los ficheros de ese grupo.

Su extensión suelen ser log

* FICHERO DE CONTROL

Es un fichero binario, con lo cual no se puede ver el contenido. Tenemos toda la estructura física de una base de datos correspondiente a una instancia. Tambien está ahí el SCN. Si no tengo este fichero la base de datos no se puede abrir. la instancia se puede levantar en modo nomount.

Como mínimo un fichero, pero cuando se hace un montaje automático se crean tres copias. El problema cuando se pierden estos ficheros, perdemos las ubicaciones de ficheros de datos, de redo logs, el parámetro MAXDATAFILES, etc.

Cuando se arranca la base de datos hay un parametro para indicar donde está el fichero de control para levantar la base de datos. Este parámetro es CONTROL_FILES.

la extensión normal es ctl. El numero máximo de ficheros de control es 8.


** FICHEROS DE NO DATA BASE

FICHERO DE PARAMETROS

Es el que define los parámetros de la instancia, init(sid).ora y spfile(sid).ora, por ejemplo, si la base de datos se llama yonki, los ficheros serán inityonki.ora y spfileyonki.ora.


FICHERO DE PASSWORD

Son los que están creados en la base de datos para poder hacer una admin. remota. Se crea, se añanden los usuarios que tienen permisos y se puede acceder. Este se crea por defecto siempre.

FICHERO DE INFORMACIÓN

Son ficheors que va a genera la instancia acerca de la informaciones, warnings, errores acerca de la base de datos. Lo genera la propia base de datos, los procesos background, etc. Algunos se pueden leer directamente y otros hay que utilizar programas para interpretarlos. son los .trc.

FICHEROS ARCHIVE LOG

Son copias de los ficheros redo log. Los que se están usando son los redo log online y estos son los redo log archivados. Estos tienen extensión .arc como norma general.


==DICCIONARIO DE DATOS==

Es un conjunto de tablas y vistas de solo lectura que proporcionan la información sobre la base de datos. Estas vistas y tablas son actualizadas de forma automática por Oracle... cuando se cambia la estructura, se borra algo, etc.

Podemos consultar este diccionario de datos, que se encuentra en los ficheros de daots, y más concretamente en el system (tablespace system), podemos consultarle con usuarios básicos, como desarrolladores o como dba. Cuantos más privilegios tenga más datos podré ver. Este diccionario de datos, como es la base de datos, se crea cuando se crea la base de datos, y lo crea el usuario sys, luego sys tiene todos los privilegios para ver todo.

Está dividido en dos partes:

-Tablas base
-Vistas

Las tablas base son creadas cuando creo la base de datos. El único que puede acceder a ellas es el propio gestor, no puede acceder ni los dba.

Para poder acceder a las tablas, están las vistas, que son consultas a las tablas base. Pueden ser de dos tipos:

-vistas base
-vistas dinámicas de rendimiento.

Utilizamos estas vistas para extraer información de las tablas base. Solo se consulta, no se puede hacer modificaciones.

En las vistas Base, son las X$, las vistas dinámicas de rendimiento son las v$. tenemos muchas v$, que tienen mucha información, y además tiene toda la información conjunta. Para especificar un poco más se han sacado unas vistas más sencillas, que son las USER_*, ALL_* y DBA_*. Por norma general los usuarios van a trabajar con estas últimas más sencillas.

Todas las tablas con USER_ delante van a hacer referencia a objetos propias del usuario, es decir, de los que sea owner

Todas las tablas con ALL_ delante muestr todos los objetos a los que ese usuario puede acceder bien porque sea el dueño o bien porque tiene permisos.

Todas las tablas con DBA_ delante muestra todos los objetos de esa tabla.

Para poder trabajar con DBA_* o con v$* se necesita mínimo privilegios de DBA.

En el momento de parar la base de datos, las vistas dinámicas y las vistas base desaparecen, puesto que todo está en memoria.

Para ver que vistas tenemos podemos usar la vista v$fixed_table

Para ver que vistas sencillas que tenemos las podemos consultar en la tabla sys.syscatalog.


=INSTALACIÓN DE ORACLE=

* Preparacion del sistema
* Instalación del gestor oracle 10g
	- Prerrequisitos
	- Instalación de Wizard
* Creación manual de la base de datos oracle 10g

==Preparación del sistema==

Asegurarnos de que la máquina puede gestionar Oracle

Asegurarnos de tener al menos tres recursos de almacenamiento separados
- Oracle recomienda tres discos gestionados independientemente

Configuración parámetros de entorno
ORACLE_HOME ORACLE_BASE ORACLE_SID y otros

Parar o hacer backup del resto de DB (en caso de que ya tuvieramos alguna)

Verificar que los parches sugeridos han sido instalados en el SO

==Instalación del servidor==

Antes de lanzar el instalador del gestor de oracle se realiza un chequeo del entorno para ver si cumple los requisitos mínimos

Oracle dispone de herramientas para realizar operaciones de forma más automática.

OUI (oracle universal installer): es usado para actualizar o eliminar componentes software. Está basado en java.

DBCA (Oracle Database Configuration assistant): es el asistente para la configuracion de la BBDD.. Permite crear, suprimir, configurar y gestionar plantillas de BBDD.

Durante la instalación del oracle, que se hace con el OUI, tambien accederemos al final de la instalacion del gestor de base de datos, al DBCA con el que crearemos la DB. Si queremos crear otra instancia no habrá que volver a usar el OUI, sinó que lanzaremos directamente el DBCA.

La nueva instalacion de Oracle 10g muetra mejoras respecto a la versión anterior. Se sigue usnado el OUI, deberemos concer los requermientos técnicos antes de su instalación:
-chequeo de versioin del sistema operativo
- verificación de instalación de todos los parchas en el s.o.
- verificacion de zonas de SWAP y TEMP
- Verificación de que el directorio ORACLE_HOME está vacío.

===Requsitos mínimos===

Ram de 512Mb
Swap de 1Gb
Disco duro libre de 500-2.5gb
BBDD preconfigurada de 1,2Gb
Espacio temporal de 400mb

Los componentes de la instalación están agrupados en 

- ENTERPRISE EDITION: Contiene todos lso componentes incluyendo las aplicaciones críticas
	
- STANDARD EDITION: No dipone de todos los componentes




===DBCA===

La ejecución de DBCA implica lo siguiente de forma automática

1. creacion de forma automática de tablespace sysaux
2. Implementación de procedimientos de backup y recuperacion
3. Creación de repositorios y sus servicios
4. Simplificacion de creación de la DDBB
5. habilitar el em para esta base de datos
6. Si se ha optado por asm crear y configurar una instancia asm
7. Utilizar de los parametros pro defecto pra la ddbb
8. Creacion de una DDBB clon de la ...¿?


(nota)

Para crear un usuario que tenga acceso al isqlplus dba, la contraseña inicial de admin es welcome

C:\>%ORACLE_HOME%\jdk\bin\java -Djava.security.properties=c:\oracle\product\10.2
.0\db_1\sqlplus\admin\iplus\provider -jar c:\oracle\product\10.2.0\db_1\oc4j\j2e
e\home\jazn.jar -user "admin" -password welcome -shell




==Creación manual de una base de datos==

Se puede crear con la sentencia CREATE DATABASE, pero antes habrá que configurar todo el entorno de forma manual para que funcione.

Una de las cosas principales que hay que hacer es crear el fichero de parámetros. Se puede hacer creandolo desde cero, poniendo una serie de parametros, o copiarlo de otra instancia, cambiarle el nombre y cambiar el contenido.


El DB_NAME configurará el nombre de la base de datos.Siempre el nombre debe ser una palabra, preferiblemente no más de 4 o 5 letras.

Después hay que poner el db_domain, que es el dominio en el cual se va a lanzar esta base de datos, puede ser de windows, de linux, dependiendo del entorno. si no se pone nada tampoco pasa nada

DB_BLOCK_SIZE es el tamaño con el que va a trabajar oracle en cuanto a bloque. Este es obligatorio.

contro_file es obligatorio, y ahí ponemos el path de donde van a estar ubicados los ficheros de control, y si va a haber uno o varios. 

DB_BLOCK_BUFFERS tambien es obligatorio y especifica lo que nos va a ocupar el data buffer cache.

Todo esto se guarda en un fichero llamado init<SID>.ora.

LOG_BUFFER es obligatorio y especifica el tamaño de los buffers de redo log en bytes.

Otros procesos opcionales son:

ROLLBACK_SEGMENT En 10g ya no se usa
PROCESSES numero de procesos que pueden conectasre a oracle en un momento dado
LICENSE_MAX_SESSION numero maximo de sessione que se pueden establecer
LICENSE_MAX_WARNING hace que oracle mande un aviso cuando se sobrepase este valor, debe configurase a un valor menor que LICENSE_MAX_SESSIONS
LICENSE_MAX_USERS para limitar el numero de usuarios creados en una DB


===PASOS PARA LA CREACIÓN DE UNA BBDD ORACLE===

0. Seria combeninente hacer una coipa de seguridad de las otras bases de datos que ya tiene creada el gestor de base de datos sobre la que vamos a añadir este DB

1. Vamos a dfinir el nombre de la nueva instancia mediante la variable ORACLE_SID.

2. Creación de los directorios necesarios para guardar los datos y ficheros de la instancia.

3. Creación del fichero de parametros init.ora y su modificacione (esto es lo que hemos explicado antes)

3.1. Creación de un servicio para la instancia (windows) y opcionalmente creacion del fichero de password.

4. Nos conectamos al gestor de Oracle, con un sqlplus /nolog

5. Arrancamos la instancia en un modo especial, NOMOUNT, para la creación de la BBDD

6. Una vez arrancada la instancia se crea la base de datos, con el comando CREATE DATABASE.

7. Si es necesario habría que crear los tablespaces adicionales para guardar los datos.

8. Lanzamos los scripts necesarios y opcionales, para crear las vistas, sinonimos, etc

9. Crear el segundo fichero de inicialización, spfile.ora, para que la DDBB trabaje desde ese momento con ese fichero

10. Hacer un backup de la base de datos.

==== Paso 0, backup de la base de datos ====

==== Paso 1, Decidir el id de la instancia ====

En nuestro ejemplo será ORA10, y lo unico que teneoms que hacer es declarar ORACLE_SID=ORA10

==== Paso 2, Creación de directorios ====

Siempre vamos a tener la siguiente estructura, en windows

ORACLE
	PRODUCT
		10.2.0
			admin
				ORA10
					adump
					bdump
					cdump
					dpdump
					pfile
					udump
			db_1
			flash_recovery_area
			oradata
				ORA10
Tendriamos que crear estos directorios vacíos. los que están dentro de admin y dentro de oradata.

En oradata guardariamos los ficheros de datos, control y redo log.

==== paso 3, creación del fichero de parámetros====

Crear el archivo de inicializción de parámetros de guardado en la ubiacion por defecto definida por Oracle

en Unix $ORACLE_HOME\dbs
en windows

Algunos parámetros

db_block_size=
db_cache-size=
db_file_multiblock_read_count=16 (opcional)
====================
undo_management=auto
====================
control_files=("D:\oracle\product\...\oradata\ORA10\CONTROL01.CTL",
               "...","...",...)

java_pool_size=?bytes
large_pool_size=?bytes
shared_pool_size=?bytes (48mb)

open_cursos=300(numero máximo de cursores abiertos por un usuario a la vez) no es obligatorio
background_dump_dest=d:\oracle\product\10.2.0\admin\ORA10\bdump (si algun proceso en background me da algún error o lo que sea nos lo deja ahí
core_dump_dest=D:\oracle\...\cdump
user_dump_dest=d:\oracle\...\udump (proceso de servidor que de errro por parte de la petición de un usuario lo deja ahí)

db_name=ORA10
db_domain=(no es obligatorio)

==== paso 4, crear servicio que proporciona gestión de instancia====

Solo en windows

# oradmin -new -sid ORA10 -startmode M

Si queremos crear el fichero de passwords para autenticarme de forma remota e nla db y poder administrarla:

# orapwd file=d:\oracle\product\10.2.0\db_1\database\PWD<SID>.ora password=<un_password>

La password siempre suele ser identica a la de administración interna.

La localización del fichero de password es:

Unix ORACLE_HOME/db/orapwd


====Paso 5, conectarse a la instancia====

Iniciar la instancia sin montar una DB, tipicamente esto solo se hace mientras se crea una nueva DB

STARTUP NOMOUNT pfile= c:\donde hemos dejado el init.ora

Con esto loq ue hace es cargar los procesos en background que especifico en el init.ora

====Paso 6, crear la base de datos en si====

Usamos la orden CREATE DATABASE para crear los ficheros de la base de datos. En caso de que esta orden nos diera fallo y tuvieramos que relanzarla tendremos que  borrar los ficheros que ha generado en el directorio oradata. habrá que borrar los ficheros de control, datos y redo logs.

Un ejemplo de CREATE DATABASE

CREATE DATABASE ORA10
	MAXINSTANCES 1
	MAXLOGSFILES 5
	MAXLOGHISTORY 1
	MAXLOGMEMBERS 3
	MAXDATAFILES 100

	DATAFILE "... SYSTEM01.DBF"
		SIZE ...

	SYSAUX DATAFILE "... SYSAUX.DBF"
		SIZE 10M ...

	DEFAULT TABLESPACE...

	UNDO TABLESPACE "UNDO" DATAFILE "D;\UNDO.DBF" SIZE...

	CHARACTER SET ...

	NATIONAL CHARACTER SET AL16UTF

	LOGFFILE
		GROUP 1("D:\...REDO01.DBF")
			SIZE 10M...
		GROUP 2("d:\...REDO01.DBF")
			SIZE 10M...

		...

	;


==== Paso 7, crear tablespaces adicionales====

CREATE TABLESPACE users LOGGING
DATAFILE "D:\..\.DBF" SIZE 25M REUSE AUTOEXTEND ON NEXT 1280K MAXSIZE UNLIMITED

Si no hace falta no se hace nada...

==== Paso 8, ejecutar escripts para crear vistas dinamicas y estructruas dinámicas====

catalog.sql generale diccionario de datos
catproc.sql estructruas de pl/sql

==== Paso 9, ejecutar scripts para opciones adicionales====

==== Paso 10, crear el archivo de parámetros ====

CREATE SPFILE="C:\..." FROM PFILE='C:\..."

==== Paso 11, hacer un backup en frio de la base de datos====



=MIGRACION DESDE VERSIONES ANTERIORES=

Lo primero que hay que ver es si la máquina donde estaba la versión anterior cumple con los requisitos de la versión 10g. 

Se puede hacer por dos métodos

- Directa
- Indirecta

La directa es utilizando un asistente que se llama dbua o bien haciendo una actualización manual

La indirecta es mediante la utilización de la operativa de import y export, o copiando los datos de una ddbb antigua a otra ddbb nueva. OJO, si vamos a utlizar el metodo import/export, habrá que usar siempre la misma versión, es decir, que si importar datos de una versión anterior, lo mejor es usar el export de la verisión nueva y hacer el import con la versión nueva.

Para hacer la actualización necesitamos que la máquina sea una de estas versiones:

8.1.7.4
9.0.1.4 o superior
9.2.0.4 o superior
10.1.0.2 o superior

Existe una aplicación llamadaa utlu102i.sql que nos dice si es posible la migración directa de la version anterior a la 10g.

Si no está dentro de esas versiones tendremos que aplicar los parches de actualizaciones necesarios hasta llegar a una de esas versiones.

Lo primero que hay que hacer antes de realizar la actualización es un Backup. Una vez hecho ya podemos lanzar la aplicacion dbua.

Si por cualquier motivo no puedo llevar la base de datos a una de las versiones de las que se puede hacer la migración tendremos que hacer una migración manual.

== Pasos de la migración automática==

1. Elección de la base de datos a migrar
2. Indicar donde se creará el TS.SYSAUX (mínimo de 500mb)
3. Indicar si se quiere o no recopilar los objetos erroneos después del upgrade
4. indicar si BACKUP lo hace DBUA o no
5. Especificar lugar para archivos FLASH RECOVERY
6. Indicar password para EM (SYSMAN Y DBSNMP)


=FICHEROS DE ORACLE SERVER 10G=

En esta sección nos referimos a los ficheros No DB


==FICHEROS DE PARAMETROS==

Son los que oracle utiliza para arrancar la instancia y abrir una base de datos. El arranque de la instancia lee ese fichero (el correspondiente a su ORACLE_SID) y lee los parametros para arrancar la instancia según aparezca ahí. Segun los datos que vea en ese parametro dimensiona la memoria.

Si no encuentra el fichero de parámetros no se arranca la instancia. 

Hay dos tipos de ficheros de parametros:

Estaticos (pfile)
Dinamicos (spfile)

los pfile son los comunmente denominado init.ora y el spfile es spfile.ora. El nombre comun que tienen son init<sid>.ora y spfile<sid>.ora

Para saber con que tipo de fichero a arrancado una instancia tenemos que consultar:

SHOW PARAMETER SPFILE;

si en el campo value aparece un valor (path a un fichero spfile) es que ha arrancado con un fichero dinámico, y si está vacio ha arrancado con un fichero estático


===PFILE===

Este fichero es en ascii y se puede editar con cualquier editor (que no deje caracteres extraños). Este fichero lo utiliza el dba para cambiar parámetros. El problema es que la instancia no va a tomar los nuevos valores hasta que la instancia se reinicie.Por lo tanto, siempre que quiero cambiar un valor del init<sid>.ora estoy obligado a tirar la base de datos y volver a arrancarla.

Los valores se ponen como:

parametro=valor
parametro=(valor,valor2,valor3)

Este fichero está ubicado de forma comun en:

UNIX:    $ORACLE_HOME/admin/SID o $ORACLE_HOME/dbs (mas bien la segunda, la primera es donde lo crea el gestor???)
WINDOWS: %ORACLE_HOME%/database

===SPFILE===

Este fichero de configuración empezó a usarse desde 9i. Antes se podían cambiar parametros de forma dinámica, pero no se reflejaban en el fichero de configuración. Asi, cuando hacemos cambios dinámicos quedan reflejados para que la proxima vez que levante la instancia levante con ese parametro modificado.

Una vez se crea nos olvidamos de él porque Oracle es el que lo administra. Es un fichero binario que no tenemos que tocar para nada. Cuando se hace una orden ALTER SYSTEM SET ... lo que hace es cambiar ese parametro de la memoria, y además lo guarda en el spfile.

Este fichero lo podemos encontrar en los mismos directorios donde están los init.ora (pfile) Se suele llamar spfile<sid>.ora.

Cuando hacemos la instrucción ALTER SYSTEM podemos indicar donde queremos que se haga la modificación con la clausula SCOPE. El valor puede ser mempory, spfile o both. Ejemplo:

	ALTER SYSTEM SET shared_pool_size=120M SCOPE=memory

Por defecto, si no le decimos nada, se hace un scope=both. 

Dentro de los parámetros hay muchos que no se pueden cambiar de forma dinámica, los cuales hay que decirles el SCOPE=spfile, para que solo los guarde a disco, y la proxima vez que se arranque la instancia se tendrá en cuenta.

Si queremos ver los valores que tiene el spfile, podremos consultar la vista dinámica v$spparameter.

Cuando el gestor arranca la instancia busca en el directorio que hemos dicho antes, primero usa el spfile<sid>.ora, si no lo encuentra busca un spfile.ora, si no lo encuentra un init<sid>.ora y si no encuentra este tampoco buaca un init.ora.

Si queremos saber con que fichero arrancó habra´que hacer un:

SHOW PARAMETER spfile;

Podemos hacer los siguientes comandos:

CREATE PFILE FROM SPFILE
CREATE SPFILE FROM PFILE

===FICHERO DE PASSWORD===

El fichero de password nos indica si a través de la red se puede logar sin privilegios de DBA, para administrar la instancia.

Para hacer esto cuando arrancamos la Db hay una clausula dentro del init.ora que es REMOTE_LOGIN_PASSWORDFILE que puede estar a none,shared,exclusive.

Si está en exclusive el sistema, cuando hay una petición a través de red, primero busca el fichero PWD<sid>.ora y mira dentro que usuarios se pueden conectar. Si ese usuario que ha hecho la petición está le deja conectarse.

Si es none solo deja conecatarse a los usaurios del sistema que pertenezcan al grupo oradba, pasando de lo que ponga en el fichero.

Si esta en modo shared el fichero de password lo comparten de 1 a n instancias. por norma general el fichero se llamará PWD.ora y lo abrirán todas las instancias.

Casi siempre estará en exclusive y habrá un usuario diferente por instancia.

==FICHEROS DE DATOS==
son los ficheros físico que contienen los datos actuales de la base de datos.

El tamaño de estos ficheros está realcionado con el ...

(...)


==FICHEROS DE REDO LOG==

Solo se utilizan en el momento de hacer una recuperación o en el momento de un fallo de la base de datos. Proporcionan al medio para rehacer transacciones en caso de fallo de la base de datos.

Estos contienen todos los cambios producidos en la base de datos desde un momento concreto. Esas operaciones son todos menos las operaciones "NOLOGGINS" y las cargas directas en las que se especifica que no vaya al redo log.

Cuando se están realizando transacciones todas esas operaciones se guardan en los buffers de redo log, en memoria, y cuando cumplía unas determinadas características estos buffers se guardaban a disco, por el proceso LOGWR. Este escfibe de forma síncrona, una vez que se pone a escribir lo escribe todo lo que hay en memoria.

El número mínimo de ficheros es de dos ficheros. En realidad el mínimo numero de elementos son 2 grupos, y en cada grupo tiene que haber al menos un fichero. Un grupo de redo log es un conjunto de ficheros que son tratados de la misma forma, contienen la misma información.A cada fichero de un grupo tambien se le denomina miembro.

Siempre hay un grupo activo por así decirlo, y cuando este se llena pasa al siguiente. Si solo tenemos dos grupos se alternará cada vez uno. Cada vez que pasa a uno de esos ficheros desecha los datos que había antes.

Cuando están llenos todos los grupos hay dos formas de actuar:

- Si no está en modo archive log desecha los cambios y empieza a escribir en el primer grupo machacando los datos.

- Si está en modo archive log, el proceso ARCH es guardar los datos de un grupo y los guarda en otro lugar, y después ya sobreescribe.

Estas configuraciones se determinan por los parámetros

MAXLOGFILES: numero máximo de grupos
MAXLOGMEMBERS: numero máximo de miembros en cada grupo


Para saber los redo logs que hay en una db se puede usar la vista:

MGMT$DB_REDOLOGS

El proceso LGWR escribe concurrentemente la misma información en todos los ficheros miembros de un grupo. Cada miembro de un grupo tiene el mismo LSN y el mismo tamaño. El LSN actual se almacena en el fichero de control y en la cabecera de todos los ficheros de datos. De esta forma se ordena los ficheros de redo. 

Para obtener el LSN tenemos la vista v$log, y en la columna SEQUENCE# aparece la etiquetación actual.

Todos los miembros de un mismo grupo cada miembro tiene que ser del mismo tamaño. Los grupos, según la recomendación de oracle, han de tener el mismo número de miembros, esto es opcional.Tambien recomienda oracle que el tamaño de los miembros de los grupos sean igual entre grupos.

La principal razón para poner varios miembros en un mismo grupo es para tener duplicada la información como si fuera un disco con raid 1.

como los grupos de redo log se utilizan de forma cíclica, cuanda acaba uno salta al siguiente, y cuadno llega al último salta al primero. La operación de cambiar al siguiente log se llama LOG SWITCH. Esta operacion se va a producir cuando se ha acabado el redo actual (se ha llenado) o cuando el administrador realiza una operación de LOG SWITCH manual con:

ALTER SYSTEM SWITCH LOGFILE

SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE# FIRST_TI
------------- --------
         1          1          5   52428800          1 NO  ACTIVE
       631474 23/03/09

         2          1          6   52428800          1 NO  CURRENT
       633968 23/03/09

         3          1          4   52428800          1 NO  INACTIVE
       601991 18/03/09


cuando el status se queda con active es porque no se ha cerrado con un scn, es decir, con un checkpoint, y le falta ese último scn, por eso se queda en active. El sistema no va a poder borrar ningún fichero que esté en modo current o active.

Un checkpoint es un punto de validación real, y hasta ese punto se puede realizar una recuperacion, y cada checkpoint hay un numero scn. el scn es el numero de validacion de transacciones.

El checkpoint se pone de forma automática cuando se llena el redo log. Este scn se escribe en el fichero de control, en el ficheor de redo y en las cabeceras de los ficheros de datos. En cada fichero de redo hay múltiples numeros de scn (checkpoints) a lo largo del fichero.

Para añadir más grupos red log a una base de datos

ALTER DATABASE ADD LOGFILE GROUP # ('fichero1','fichero2',...) size x M;

Para borrar grupos de redo log:

ALTER DATABASE DROP LOGFILE GROUP #

Al parecer, si tenemos una base de datos de la que podemos hacer backup en frio todos los días (es decir, parando la base de datos) se podría poner en modo NO ARCHIVELOG y podríamos dimensionar los redo log para que en todo el día no se sobreescriban, y al hacer el backup en frio decirle que vuelva a empezar por el primer grupo de redo log.

Para añadir miembros, hay que indicar el grupo. Se hace de la siguiente manera:

ALTER DATABASE ADD LOGFILE MEMBER
'fichero1' to GROUP 1,
'ficheor2' to GROUP 2,
...
'fichern' to GROUP N

El tamaño de los ficheros no se especifica ya que viene dado por la configuración del grupo.

Para borrer un miembro dentro de un grupo:

ALTER DATABASE DROP LOGFILE MEMBER 'fichero'

No se puede borrar un miembro si es el último del grupo. No se puede borrar un miembro si el grupo está current o activo. No se borran los ficheros físicamente, hay que hacerlo a mano. Si la base de datos está en modo archive log, no se puede borrar logs de ningún miembro de grupos que no hayan sido archivados.

para obtener la información de MAXLOGFILES Y MAXLOGMEMBERS:

select recordS_total from v$controlfile_record_section where type='REDO LOG'; 16 grupos como máximo
select DIMCM from X$KCCDI; 3 miembros por grupo

Para encontrar el LSN

SELECT sequence# from v$log

==FICHEROS DE CONTROL==

Son primordiales para la base de datos, si estos no están no se arranca la instancia. Estos ficheros son binarios, no son editables.

Como mínimo debe existir un fichero de control, por defecto oracle crea tres ficheros, y lo conveniente es almacenarlos en diferentes discos por si un dispositivo falla. Es creado de forma automática cuando se efectua el CREATE DATABASE. 

El fichero de control es leido antes de abrir la base de datos en el estado mount de la base de datos.

Si no disponemos de estos ficheros no se podrá encontrar los componentes físicos de la BBDD y no se podría abrir la BBDD.

Dentro de este fichero encontramos información como:

- Nombre e identificación de la BBDD
- Fecha y hora de la creación de la BBDD
- Nombre, localizaciones y tamaños de los ficheros de redo log y de datos
- Información usada para la recuperacion de la BBDD en caso de error:
	- LSN actual de los REdo logs cuando ocurre un log switch
	- Información sobre los checkpoint (SCN)
	- Información de los backups hechos con el RMAN (Recovery manager)
	- Información de los Redo logs archivados.

Disponemos de la vista v$controlfile para saber la ubicación de los ficheros de control. También podemos saberlo con show parameter control_files

Para hacer una copia online del fichero de control, en caliente podemos poner:

alter database backup controlfile to 'fichero1,fichero2,...'

Pero este fichero de control sigue siendo binario.

Para ver el contenido, podemos sacar una copia del fichero de control en texto, pero en realidad lo que estamos sacando es un script que crearía el fichero de control desde cero. Para esto hacemos:

alter database backup controlfile to trace;

Esto nos mete en el directorio udump una traca en la que aparece el comando CREATE CONTROLFILE, con todos los parámetros que necesitamos para recrear el fichero de control.

En mi ejemplo es:

CREATE CONTROLFILE REUSE DATABASE "ORCL" RESETLOGS  NOARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 292
LOGFILE
  GROUP 4 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO04.LOG'  SIZE 4M,
  GROUP 5 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO05.LOG'  SIZE 4M,
  GROUP 6 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO06.LOG'  SIZE 4M
-- STANDBY LOGFILE
DATAFILE
  'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSTEM01.DBF',
  'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF',
  'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSAUX01.DBF',
  'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF',
  'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\PEDRODATA.DBF'
CHARACTER SET WE8MSWIN1252
;

Para añadir ficheros de control adicionales lo podemos hacer de dos formas:

- Dentro del fichero init.ora
- En el ficheor spfile.ora

Si lo hacemos desde el pfile, lo podemos hacer de la siguiente forma:

Hacemos un shutdown immediate
Copiamos el fichero de control a otro archivo mediante comandos del S.O.
Modficamos el parámetro CONTROL_FILES en init<sid>.ora, añadiendo el nuevo fichero
Abrimos la BBDD.

Si lo hacemos desde el spfile, será:

Con la instancia arriba todavía ejecutamos ALTER SYSTEM SET CONTROL_FILES= 'C:\...<antiguos>','C:\...\<nuevo>' scope=SPFILE
Paramos la instancia con shutdown immediate (por ejemplo)
Copiamos uno de los ficheros antiguos con el nombre que le hemos dado al nuevo
Levantamos la nueva instancia.


(((((ESTE DÍA HE FALTADO))))
Segun me cuenta mi compañera de al lado dieron como parar y arrancar instancias y ejercicios sobre ello.



=7. ESTRUCTURA LÓGICA DE LA BASE DE DATOS=

Dentro de los fichero de datos oracle da una organizacion personal de los datos. Es una organización lógica. Toda esa organización lógica es propia de oracle. No está separado fisicamente las partes que vamos a ver, sinó que está separado en estructuras de oracle

La estructura mayor es el tablespace, es una agrupación nde elementos dentro de esta estructura lógica.

Cuando se crea una base de datos (instancia) se crean por defecto los tablespaces para manejar esa instancia. Son cuatro:

system
sysaux
temporal
undo

<ver gráfico que ha incluido en la documentación>

En el system tenemos todo el diccionario de datos.

Cada tablespace es un concepto logico pero en realidad cada tablespace es uno o más ficheros.

En el sysaux (es nuevo en 10g) se utiliza para estadisticas y metadatos del sistema. metadatos de recovery manager, dataware,... Realmente es un tablespace de ayuda al system, como un agregado.

El temp es para contener datos temporales, como ordenaciones, agrupaciones, etc.

Estos tres son obligatorios, y el resto son opcionales, aunque por norma general tambien aparecen otros que son el undo, users y el example.

El undo contiene los registros de deshacer. No es obligatorio pero es recomendable.

El users, para contener los esquemas de todos los usuarios

El example aparece cuando ponemos los esquemas de ejemplo cuando cremamos una db.

Si el system o el sysaux no existen no se pueden recrear, pero el undo y el temp si se pueden recrear.

A nivel lógico cada tablespace tendrá segmentos, los segmentos tendrá extensiones, las extensiones tendran bloques. Cada uno de estos bloques coincide con un bloque físico del sistema operativo.

==TABLESPACES==

Es la unidad maxima de almacenamiento donde se van a guardar datos de la BBDD. Es una agrupación lógica. Se agrupan de forma logica para controlar los datos y para funcionalidad de almacenamiento, tener dividido de forma controlada los datos. Así en un futuro los datos de una aplicacion están en un tablespace y los de otra en otra, así si hacemos backups o cualquier tarea podemos aplicarlo solo a los datos de una aplicación en concreta.

Disponemos en cada base de datos de tres o mas tablespaces (system,sysaux,temp). Cada tablespace para guardar los datos que me den ha de tener de 1 a n ficheros. El numero máximo de ficheros de datos de la BBDD va definido a la hora de hacer el CREATE DATABASE, y no se puede cambiar después.

Cuando se crea un objeto en la base de datos ese objeto ha de pertenecer a un tablespace. No puede haber objetos que no pertenezcan a un tablespace.

Cualquier tablespace puede estar offline por un fallo de disco (o voluntariamente). Pero eso no puede pasar a los tablespace system o sysaux.

Cuando se utiliza la orden CREATE TABLESPACE tenemos muchas opciones. No es neceario poner todas, ya que ha valores por derfecto a dichos parámetros. Estos valores que definimos a los tablespace son hereditarios hacia los segmentos que posee, las tablas que hay en ella, etc.

Dentro de oracle hay dos tipos de tablespace: los de sistema y los de no sistema. Simplemente para diferenciar los que son muy críticos y los que no lo son, para el funcionamiento del sistema

===TABLESPACE DE SISTEMA===

Son el system y el sysaux, y son críticos. Tanto uno como otro trabajan siempre con el tamaño de bloque logicoestandar de la base de datos. 

Son necearios para Oracle 10g y son creados e nel momento de la creación de la base de Datos (CREATE DATABASE)

No pueden ponerse en modo OFFLINE pues supondría la detenccion de la base de datos.


====SYSTEM====

Contiene el diccionario de datos. Corresponde normalmente con el fichero system01.dbf. Están todas las tablas base, los paquetes, las funciones, los procedimientos, etc... Internamente tambien contiene los segmentos de roll back, pero son usados solamente por el gestor, ni el dba puede acceder a ellos.

Para crear este tablespace se crea mediante la clausula DATAFILE del CREATE DATABASE, y solamente se crea durante la creación de la base de datos. Lo que si podemos hacer es añadir más ficheros o quitar ficheros para el tablespace SYSTEM.

====SYSAUX====

Es un nuevo tablespace de 10g que hace de ayuda al tablespace system. Tiene datos de las estadisticas automáticas WR, de RMAN, de RAC, de JOBS, STATSPACK... etc

Debe definirse con unas determinadas caracteristicas:
ONLINE
PERMANENT
READ WRITE
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENTE LOCAL

En este tablespace, como dba, podemos guardar cosas en este tablespace, pero no es recomendable.

Se puede crear el momento de la creación de la base de datos con la clausula SYSAUX DATAFILE pero tambien se puede crear cuando hacemos una migración de versiones 9 a versiones 10.

Por norma genera tambien vamos a tener un fichero llamado sysaux01.dbf

Dentro de sysaux disponemos de una vista llamada v$SYSAUX_OCCUPANTS. Ahí estarán los componentes que sean propioes de metadatos o de alguna aplicacion en concreto. Si hemos metido datos en sysaux con esta vista podriamos ver que objtos están en el sysaux

SQL> select  occupant_name, schema_name, space_usage_kbytes from v$sysaux_occupa
nts order by 3;

Tambien tiene un campo interesante que es el move_procedure, es un procedimiento para coger ese objeto y poder moverlo a otro tablespace.

SQL> select occupant_name, schema_name, move_procedure from v$sysaux_occupants w
here occupant_name='LOGMNR'
  2  ;

OCCUPANT_NAME
----------------------------------------------------------------
SCHEMA_NAME
----------------------------------------------------------------
MOVE_PROCEDURE
----------------------------------------------------------------
LOGMNR
SYSTEM
SYS.DBMS_LOGMNR_D.SET_TABLESPACE


NOTAS ACERCA DE SYSAUX:

Los ficheros que se añaden al tablespace tanto system como sysaux han de ser de tipo small. No se puede poner ni offline y borrarlo y renombrarlo. Si queremos obtener información de sysaux o de las estadísticas disponemos de un script que se llama awrinfo.sql.


===TABLESPACE DE NO SISTEMA===

El resto de tablespaces

Utilizados para agrupar logicamente la información de la BBDD, para optimizar rendimientos

Premiten el control de espacio asignado a los usuarios. Tambien permite agrupar o diferenciar datos en función a las necesidades de las aplicaciones:

UNDO
TEMPORAL
USERS
Tablespace Aplicaciones
Tablespace Indices.

Para saber los tablespace que tenemos creado disponemos de una serie de vistas:

DBA_TABLESPACES: Indica datos de cada tablespace que tenemos
v$tablespaces
DBA_DATA_FILES: Indica datos de cada fichero de datos y con que tablespace se corresponde.


===Creacion de tablespaces===

CREATE TABLESPACE Nombre
DATAFILE 'file_spec‘ SIZE n [K | M]
[AUTOEXTEND ON NEXT n [K | M] MAXSIZE UNLIMITED | n [K | M] ]
[MINIMUM EXTENT n [K | M]]
[LOGGING | NOLOGGING]
[ONLINE | OFFLINE]
[DEFAULT (storage_clause)]
[PERMANENT | TEMPORARY]
[EXTENT MANAGEMENT
[ DICTIONARY |
LOCAL [ AUTOALLOCATE | UNIFORM [SIZE n [ K | M ] ] ]
[SEGMENT SPACE MANAGEMENT MANUAL | AUTO]:


· Extent Management, es para decirle si el espacio lo gestionar oracle o lo gestionamos manualmente.Hay de dos tipos, dicctionary o local. Esto tiende a desaparecer, porque la gestion de diccionario es la gestion de 7,8 y 9. La gstión local aparece en 9i. Se mantienen la dos por compatibilidades de versiones y migraciones.

La gestión local de extensiones es que cuando hace falta espacio cojo las extenisones que me hagan falta. Para gestionar lo hace a través de mapas de bit. Cada bit es una extensión, si está a cero esta libre y si está 1 está ocupada. Esto se lleva en memoria. Como estoy trabajando en memoria con ese mapa de bit lo primero que hace es reducir la contención en la base de datos, no accede para nada a las tablas del diccioanrio de datos. No requiere agrupar extensiones libres, porque entre todas busca ceros y unos. En el metodo antiguo tenía que buscar extensiones libres. Tampoco requiere escritura en el ts undo. En la versión 9i ya es la opción por defecto.

Con autoallocate se especifica que el tamaño de las extensiones es variable. cuando neceiste una serie de extensiones, oracle siguiendo unos algoritmos, asignara esas extensiones con un tamaño determinado dependiendo de las necesidades. Si le ponemos UNIFORM le especificaremos un tamaño de extensión que será siempre el mismo.

·Gestión a través del diccionario de datos, en vez de tener la gestión de los extents libres en memoria lo tiene en tablas del diccionario de datos, y cada vez que se guarda algo habrá que cambiar esa tabla. Eso relentiza mucho, pero tambien es verdad que es más flexible ya que cada segemteno se puede almacenar con difernetes especificaciones. Neceista fusion de extensiones contiguas y tambien utiliza escrituras en tablespace undo. Si el tablespace system es de tipo local ningún otro tablespace se puede configurar como dictionary.

·Se puede cambiar de una gestión local a una de diccionario y viceversa a través de un paquete: DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL y DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_FROM_LOCAl Se puede hacer con cualquier ts salvo el system y sysaux. El TO_LOCAL se ejecuta bien sin ningún prerequisito pero el otro si que hay que cumplir varios requisitos

·Los tablespaces TEMP no pueden ser definidos como LOCAL AUTOALLOCATE
·Los tablespaces UNDO no pueden ser definidos como LOCAL UNIFORM

·Segment space managemnt es lo mismo que antes. Un segemento es un conjunto de extensiones donde va un ojbeto.

===CREACION DE TABLESPACES TEMPORALES===

Son utilizados para hacer ordenaciones que en momoria no cabe. Realmente lo guarda en los segementos temporales. Dentro de este tablespace no se puede llevar nada, el sistema lo lleva de forma automática. No se puede guardar ningun tipo permanente, como una tabla.

Algunos s.o. no guardan espacio para estos ficheros físicos hasta que se utilizan.

Caracteristicas por defecto de un ts temporal:

· Se definen como no loggins
· No se pueden poner como RO, siempre son RW
· No se puede cambiar el nombre del tablespace temporal.
· No se puede poner una gstion Local Auto, siempre tiene un tamaño uniforme de extents
· Cuando se hace un backup de la db no se hace del tempo
· Aunque la DB este en modo lectura necesita ts temporal.

se pueden crear de dos formas, en la creación de la base de datos y después.

En la creación de la base de datos con la clausula DEFAULT TEMPORARY TABLESPACE.

Si le queremos añadir despues habrá que cambiar el comando CREATE TABLESPACE para añadir la clausula TEMPORARY y cambiar DATAFILE por TEMPFILE

CREATE TEMPORARY TABLESPACE TEMP1
TEMPFILE 'fichero' SIZE tamaño;

Siempre tiene que existir en el sistema un tablespace temporal por defecto. 

Restricciones:

Para poder borrar un TS temporal definido como por defecto tiene que existir otro y liberar a este de esa funcion

ALTER DATABASE DEFAUTL TEMPORARY TABLESPACE nombre';

En 10g hay una historia que se llama grupos de tablespaces temporales... MIRAR ESTO!!!!!!

Solo el TS System y el Temporal pueden ser definidios como TS temporales por defecto

No se puede poner en OFFLINE el TS por defecto.

para saber tablespace temporal por defecto

SELECT PROPERTY_VALUE FROM DATABASE_PROPERTIES WHERE PROPERTY_NAME='DEFAULT_TEMP_TABLESPACE';

==== CREACIÓN DE TABLESPACES UNDO====

Caracteristicas de los ts undo

Solo puede estar un ts undo activo a la vez

Los segementos de undo crecen y decrecen de forma automática y de forma circular

La información relacionada con los segementos totales existentes en tablespaces UNDO  lo podemos encontrar en las vistas

DBA_ROLLBACK_SEGS: Activos y no activos
v$rollname: Activos
v$transacction: RElacion entre transacciones y Segmentos
v$undostat: Estadísticas relaccionadas con segemtenos de Undo.

El segmento del undo ts system es el segmento usado por el mismo gestor. Del 1 al 10 son los que van a usar los difernetes usuarios, procesos, etc de la instancia. Si aparecen el 11 y el 12 son segmentos usados como ayuda al segmentos system. Son ayuda para el gestor. A partir de ahí el resto que aparazcan están asociados tambien al procesos, usuarios, etc de la instancia.


=== BORRAR UN TABLESPACE ===

Para borrar un tablespace tenemos que usar el DROP TABLESPACE, y le podemos poner una serie de opciones

DROP TABLESPACE nombre_ts
[INCLUDING CONTENTS
[AND DATAFILES]
[CASCADE CONSTRAINTS]]

En teoria para borrar un tablespace hay que ponerle en offline. Si ponemos INCLUDING CONTENTS borra antes todo el contenido del tablespace y después borra el tablespace. Si hay alguna relaccion entre una tabla de otro tablespace y el de este no dejará a no ser que pongamos CASCADE CONSTRAINT. 

Por defecto el drop tablespace no borra ficheros físicos, solo borra de la parte lógica, así que tendremos que borrar los ficheros físicos a manos o bien ponemos la clausula DATAFILES. En unix funciona bien y en windows a veces tarda en borrar solo los ficheros.

Si un tablespace tiene trasacciones activas tampoco se va a poder borrar, así que lo que hay que hacer es poner le ts offline de forma inmediata y después se borra.

=== GESTION DE ESPACIO EN LOS TARBLESPACES ===

Los problemas típicos asociados al crecimiento de datos es:

- Crecimiento desmesurado
- Infrautilización del espacio

Cuando se neceista más espacio hay dos métodos, que es añadiendo otro fichero al tablespace o cambiar el autoextend para que el fichero pueda crecer más. Tambien se puede hacer un resize de un fichero de datos de tablespace.

==== Añadir ficheros a tablespaces ====

Para añadir un nuevo fichero se usa:

ALTER TABLESPACE nombre ADD
DATAFILE 'C:\...'
SIZE n M;

El máximo nunmero de un tablespace es ilimitado pero ahy que tener en cuenta que hay un numero de ficheros límite sumando todos los tablespaces que viene configurado por el parámetro MAXDATAFILES durante el CREATE DATABASE.

==== Configurar el autoextend ====

Para configurar el crecimiento automático de ficheros utilizamos  para que los ficheros aumentnen de forma automática cuando haga falta, con la clausula AUTOEXTEND:

==== Cambio manual del tamaño de los ficheros ====

Esto lo podemos hacer mediante la clausula RESIZE. Con ella se recupera el epsacio dinámicamente:

ALTER DATABASE DATAFILE ['C:\...'|FILE ID] RESIZE n M;

El problema es que no sabemos donde están los datos dentro de esos ficheros, así que cuando decrecemos el fichero solamente va a liberar desde la parte final del fichero hasta el último bloque que ha escrito, así que es posible que no decrezca hasta el tamaño que le hemos dicho.

==== Quitar fichero de un tablespace ====

Si queremos quitar un fichero usamos

ALTER TABLESPACE nombre DROP DATAFILE 'fichero';

Esta operación es muy complicada, ya que en ese ficheor que hemos quitado puede haber datos que no queremos que desaparezcan. Lo que se suele hacer es un backup con datapump del tablespace, recrear el tablespace con un fichero e importar los datos del backup.

=== TABLESPACE A READ ONLY ===

Para hacer esto hay que usar lo siguiente:

ALTER TABLESPACE nombre READ ONLY

Si queremos que se puede vovler a escribir

ALTER TABLESPACE nombre READ WRITE

OJO, porque poner un tablespace a read only no impide poder hacer un drop de un objeto, ya que la definiciones de objetos están en el diccionario de datos. Se puede hacer drop de un objeto que se ha creado sobre un tablespace, ya que en ese tablespace solo están los datos. La estructura está en el diccionario de datos.

Lo que no podemos hacer es un create table, ya que cuando creamos una tabla a parte de crear la definicion de la tabla en el diccionario de datos tambien asigna un espacio pequeño en el tablespace de datos. Si este está en modo read only nos dará un error con lo cual no se creará la tabla. Tendra´que estar en el modo READ WRITE.

=== TABLESPACE EN OFFLINE O ONLINE ===

ALTER TABLESPACE nombre [ONLINE|OFFLINE [NORMAL|TEMPORARY|IMMEDIATE]

Hay veces que interesa que los usuarios no puedan acceder a un tablespace en concreto porque igual queremos hacer un backupa o cualquier accion administrativa, para ello ponemos el tablespace a OFFLINE. Es equivalente a poner umount /dev/xxx a un volumen en un sistema unix.

Hay tres formas para pasar un ts de online a offline

NORMAL: esperará a que el sitema pueda realizarlo. Escribe puntos de control sobre los ficheros del ts
TEMPORARY: Marca puntos de control de los ficheors online, y los ficheros offline pueden requereir recuperación. Echa a los usuarios y si hay transacciones las elimina.
IMMEDIATE: Lo pone a offline inmediatamente sin realizar checkpoint y requiere recuperación.

El último solamente se utiliza cuando vemos que hay datos erroneos, o bloques, en el tablespace que voy a parar.

Cuando levantamos de nuevo el tablespace con online el SMON va a mirar si tiene que hacer alguna recuperación de datos.

=== ASIGNACION DE USUARIOS A TABLESPACES ===

·Tablespaces por defecto:

ALTER USER usuario DEFAULT TABLESPACE nommbre_ts;

Cuando un usuario cree un objeto lo hará en ese tablespace por defecto

·Tablespace temporal:

ALTER USER usuario TEMPORARY TABLEPSACE nombre_ts;

·Se puede asignar cuotas de almacenamiento  para cada usuario:

ALTER USER usuario QUOTA 100k ON nombre_ts;

no podrá usar más del espacio asignado para ese tablespace.


=== INFORMACIÓN SOBRE TABLESPACES ===

Inforamcion sobre tablespaces:

DBA_TABLESPACES
V$TABLESPACE

información sobre los ficheros de datos

DBA_DATA_FILES
V$DATAFILE

información sobre los ficheros temporales

DBA_TEMP_FILES
v$TEMPFILE

Tambien tenemos la vista DBA_FREE_SPACE y ahí aparece el espacio libre que hay en la base de datos.


==SEGMENTOS, EXTENSIONES Y BLOQUES==

Cada uno de los tablespaces se divide en un elemento lógico inferior.

Cada Tablespace se compone de N Segmentos

Cada segemento está dividido en n extensiones

Cada extensión esta dividido en n bloques lógicos de Oracle

Cada bloque se divide en n bloques físicos de Oracle.


===SEGMENTOS===

Un segemento es una división lógica donde se van a guardar los diferentes datos de un tablespace. Dependiendo de que se vaya a guardar en ese segmento será de un tipo diferente. Este se crea cuando se crea un objeto (tabla, indidce, etc).El tamaño del segmento dependerá del tipo de segmento. 

Cuando se crea un segmento todo el tamaño de ese segmento tiene que estar en un tablespace. El tablespace puede estar compuesto de uno o varios ficheros, el segmento se puede encontrar en uno o varios de esos ficheros del tablespace. Si cuando creamos una tabla no especificamos nada oracle crea ese segmento segun carácteristicas propias del objeto que estamos creando o podemos parametrizar las caracteristicas del segmento que estamos creando.

Cuando creamos un segmento del tipo que sea, se subdivide en extensiones. Por ejemplo, el segmento de tipo dato se crea con 4 extensiones (4 subdivisiones). En la primera extensión de cada segmento se va a reservar vació. Como mínimo se va a crear una extensión. Cuando se va llenando la extensión va cogiendo mas extensiones. 

Tenemos muchos tipos de segmentos, algunos de ellos como usuario no se pueden crear y son reservados para el sistema gestor.

table
index
cluster
rollback (no controlamos)
lobsegment
cache/bootstrap (no controlamos)
table partition
index partition
temporary (no controlamos)
deferred rollback (no controlamos)
lobindex

Los que no controlamos los gestiona directamente el sistema.

Cada vez que creamos un objeto el tamaño de segemento que va a coger es por defecto el predeterminado para cada ojbeto por oracle a no ser que le digamos otra cosa.

En general, las caracteristicas que no especifiquemos a la hora de creación de un segmento, las cogera de los parámetros que hemos definido en el tablespace, y si no se han defido en el ts se cogeran de los parametros por defecto del gestor de base de datos oracle.

Cuando creamos un segmento (una tabla) el tamaño inicial será de una extensión, cuando se llene esa extensión se le asigna otra extensión. 

La extensión que se ha creado nueva ha de tener por lo menos una extension y esa extensión ha de tener mínimo 5 bloques lógicos de oracle. Si el tamaño de bloque logico es de 8k (suele ser habitual) el tamaño mínimo de un segmento es de 40k: 5bloques de 8k.

(Los segmentos de UNDO y los segementos TEMPORALES tiene un tratamiento especial) ¿?

El primer bloque logico de oracle de la primera extensión de un segmento es conocido como cabecera del segmento y contiene información sobre el propio segmento, como por ejemplo numero de extensiones, tamaño de extensiones, datos bloqueados, sesiones sobre el segmento, etc.

(LEER SOBRE LA FREELIST).

===EXTENSIONES===

CARACTERISTICAS

Disponemos de un numero máximo de extensiones superior a 2 billones por cada segemento.

Una extensión solo está en un fichero.

La gestion de estas extensiones se puede hacer mediante local o diccionario.

Las extensiones dentro de un segmento pueden ser contiguas o no.

Como norma general cuando a un segmento se le asigna una nueva extensión, esa extensión queda ligada para siempre a ese segmento, se utilize o no.

* Cuando se añaden extensiones:

En operaciones de CREATE (se añaden unas extenssiones indicadas en los parámetros)
En Operaciones de ALTER (se añaden extensiones al ampliar los segmentos)
Cuando el segmento se llena y no ha llegado al máximo del tamaño total del fichero que lo contiene.

Puede darse el caso que un segmento crece y crece, y después se hacen deletes. Aunque nosotros borramos los datos que hay en una extensión completamente, la extensión sigue ligada al segmento.

* cuando se eleminan extensiones:

En operaciones de DROP /borra la estructura del objeto y los datos asociados liberados alas extensiones)
Operaciones ALTER (se eleminan extensione sal reducir un segmento)
Operaciones TRUNCATE (Elimitan los datos y liberan las extensiones asociadas al segmento)


===HIGH WATER MARK===

Esta forma de actuar se da en las tablas y en las indices. 

Cuando borramos los datos y liberamos bloques, la extensión sigue asociada al segmento. 

Segun se van cogiendo extensiones se va modificando todas las extensiones y se deja una marca en la que se dice cual es la última extension que se ha añadido. Esto es un pequeño gran problema.

Cuando accedemos a la tabla mediante una orden de full scan (select * from tabla) oracle se va a la primera extensión hasta la HWM, haya o no haya datos.

Esto se solucionaría moviendo la HWM. Se puede hacer de varias formas

* truncate table, con eso se mueve la hwm al estado inicial, claro que me calzo los datos
* Puedo coger la tabla con muchos extents sin usar, y la muevo a otro tablespace

ALTER TABLE T1 MOVE TABLESPACE nuevo ts

Esto tiene un pequeño problema, que si la tabla tiene algún índice asociado este queda inválido y habría que hacer una recostrucicón de los indices, porque los rowid de cada fila cambia al volver a move la tabla al tablespace original. Los índices funcionan por el rowid de la tabla.

* ALTER TABLE t1 DEALLOCATE UNUSED

Con esto devolvemos la extensiones no usadas y las devolvemos al sistema, pero solamente las extensiones que esten libre desde el final de la lista de extensiones hasta la primera que encuentre. Si hay extensiones libres que están mezcladas entre extensiones usadas no se liberarán.

* Para la versión 10g se han creado los siguientes comandos

ALTER TABLE T1 SHRINK

ALTER TABLE T1 ENABLE ROW MOVEMENT (permite a oracle mover las filas a su antojo)
ALTER TABLE T1 SHRINK SPACE COMPACT (ordena las extensiones de forma secuencial)
ALTER TABLE T1 SHRINK SPACE (libera la extensiones libres al final)

después se debería poner una disable row movement, pero muchas veces se deja.

(tpdp esto se ha de hacer con el tablespace offline o con una session restrictiva) ¿?


===BLOQUES LÓGICOS DE ORACLE (BLO)===

Es la unidad mínima de la estructura lógica de oracle. Esta definido en el db_block_size durante la crecación del base de datos, y como recomendación debe ser un múltiplo del bloque del sistema operativo.

Oracle siempre trabaja con un bloque físico y lógico fijo. Aunque oracle permite que dentro de una base de datos se trabaje con mas de un tipo de tamaño de bloque, para compativilidades cuando se quieren mezclar bases de datos con difernte db_block_size. Siempre hay una base, la que definimos en la creación de la base de datos, pero después además se puede trabajar con otros tamñaos de bloques.

Es conveniente usar este multiple db_block siz cuando me he equivocado o cuando queremos traer datos de otra instancia que está en otro tamaño de bloque.

Podeoms definir hasta 4 tamaños de bloque difentes aparte del db_block_size. En nuestro caso tenemos un tamñao de bloque de 8k y podemos trabajr tambien con 2, 4, 16 y 32k. 

Para hacer esto lo podemos definir en la creación del tablespace, pero esto no vale, definimos el bloque del almacenamiento, pero tendremos que definir en memoria las herramientas para poder gestionar ese tamaño. Esto se hace con la clausula block_size del comando tablespace.

Para gestionar en memoria los diferentes bloques con los uqe estoy trabajando se usan las subcaches. Tendremos que definir un parámetro:

db_16k_cachesize= valor

Todo el almacenamiento asociado a tamaño de bloque de 16k lo va a llevar a ese area de memoria.

ejemplo: alter system set db_16k_cache_size=2M;

El bLO es donde se van a encontrar físicamente los valores de las filas de las tablas.

Oracle tiene la posibilidad de gestionar de forma automática estos bloques y eso se hace mediante la clausula SEGMENT SPACE MANAGEMENT

Si lo ponemos en auto dejamos en manos de oracle la gestión de los bloques lógicos, las características de los bloques lógicos...

====GESTION DE LOS BLOQUES====

GESTION AUTOMÁTICA

Por cada bloque que contiene este segmento le asocio un bit, que está guardado en memoria, el BMB

Cuando ponemos el SEGMENT SPACE MANAGEMENT AUTO trabajamos con estos parametros PCTUSED, FREELIST de forma automática, pero si lo ponemos en manual tendremos que definirlo nosotros.

GESTION MANUAL

Se utiliza para configurar el uso del epsacio de forma manual, transaciones en listas de bloquews

Permite configura manualmente los parametro spctused, pcfree, freelist, etc

Existe en oracle 10g para comaptivilidad  con versiones anteriores


====

Cada bloque siempre va a tener tres partes, la cabecera, los datos, y zona libre.

La cabezera es la parte inicial del bloque. Contiene las filas que tiene el bloque y transacciones activas de las filas de ese bloque. Tiene más cosas que de momento no vaoms a complicar. Ahí nos dice los rowid de las flias que contiene este bloque.

En la parte final del bloque aparecen los datos, que son ni más ni menos que las filas. Esto crece desde la parte final hacia la inicial.

En la parte central del bloque hay una parte libre, que está para el crecimiento inicial de la cabecera o de las filas...

El primer bloque de la primera extensión del segmento no tiene esa estructura, puesto que es la que tiene la información de la cabecera del segmento. Es la unica excepción a la estructura que se está expliacando en esta sección.

Tenemos una serie de parametros que nosotros podemos indicar y que afectan a la configuracion del bloque. Estos son los parametros que podemos gestionar de forma manual si ponemos SEGMENTE SPACE MANAGEMENT MANUAL.

Estos son parametros que lso pongo en la creacion del objeto, y afectan a como voy a gestionar los bloques. Si yo voy a crear una tabla y meto cosas de estas le decimos que gestione los bloques de esa forma y si no lo decimos le estamos diciendo que oracle haga una gestión automática de los bloques.

INITRANS por defecto 1 para datos y 2 para indices: Indica el numero de transacciones que estén actualizando el bloque. Se definen para definir el tamaño de la cabezera. Si ponemos 5 definimos que 5 transacciones a la vez pueden estar modificando los datos de este bloque. Por norma general cuando son tablas grandes con pocos usuarios concurrentes son numeros bajos, y al contrario son valores altos.

MAXTRANS en oracle 10g no vale para nada: por defecto 255. Indica el numero máximo de transacciones que pueden trabajar con ese bloque, tanto de lectura, escritura, actualizacion.

PCTFREE Y PCTUSED: son parametros usados para modificar el comportamiento de oracle frente a insert y a updates.

El PCTFREE es el porcentaje mínimo que debe quedar en un bloque de oracle para que pueda hacer actualizaciones de las filas que lleva dentro. Ese porcentaje se toma en relacion a el espacio libre + es el espacio de datos, la cabecera no se tiene en cuenta.

Con esto se trata de evitar filas migradas o encadenadas, cuando se intenta actualizar una fila y no hay espacio en el bloque y hay que mover la fila a otro bloque o encadenar los datos de una fila en un bloque con otro bloque.

Cuando se están insertando datos en un bloque, cuando queda el 10% libre, marca el bloque como no apto para nuevas inserciones y se insertan en otro bloque. Así aseguramos espacio para los updates.

Si se borran filas de un bloque y queda espacio libre mayor que el pctfree, sigue marcado como no apto para insertar nuevas filas, hasta que el espacio usado sea menor que lo que le hayamos especificado en PCTUSED.

Extensiones usadas DBA_EXTENTS
extensiones libres dba_free_space
segementos dba_segments
ficheros dba_data_files
tablespaces dba_tablespaces


= CREACIÓN DE TABLAS =


CREATE TABLE tabla
(campo_1 tipo restriccción_integridad_referncial,
...
...
campo_n tipo restricción_integridad_referncia)

STORAGE(
	INITIAL K
	NEXT K
	MAXEXTENTS N
	MINEXTENTS N
	PCTINCREASE N
	PCTFREE N
	PCTUSED N
	INITRANS )



INITIAL: El tamaño de la primera extensión del segmento. El tamaño no debe ser menor de 40k.
NEXT: La segunda extensión se crea con ese tamaño.
MAXEXTENTS: Numero máximo de extensiones que permite este segmento. Si no se le pone nada se considera que es unlímited.
MINEXTENTS: numero mínimo de extensiones que han de ser cogidas cuando es creado el segmento. 
PCTINCREASE: Es un porcentaje, y es el porcentaje de crecimiento con respecto a la última extensión. Si le ponemos un cero siempre serán del mismo tamaño.
PCTFREE: 20% 
PCTUSED: 40%
INITTRANS: 1

GESTION DE TABLAS

*REorganizacion (en tablas no particionadas)

· Para una tabla de un TS a otro o liminar las filas encadenadas:

ALTER TABLE nombre_tabla MOVE TABLESPACE nombre_ts

· Después de mover hay que reconstruir los índices asociados

*Asignación manual de extensiones

· Para evitar la extensión dinámica de las tablas ante una carga masiva de datos

ALTER TABLE nombre_tabla ALLOCATE EXTENT (SIZE n M DATAFILE nombre)

*Truncado

. Borra TODAS las filas y libera espacio
· tUNCA LOS ÍNDICES ASOCIADOS 

TRUNCATE TABLE nombre_tabla

Cuando hacemos un truncate liberamos todas las extensiones y solamente deja las extensiones iniciales con las que se creo el segmento. Tambien trunca los índices. No conlleva entradas en los UNDO.



==TABLAS EXTERNAS==

En versiones anteriores teníamos herramientas para hacer cargas masivas en el sistema, lo malo de estos es que teníamos que hacer el fichero, usare el sql loader, etc.

En 10g disponemos de las tablas externas. Es un fichero de texto que está en la máquina real, con un formato determinado y al cual oracle desde la db puede acceder como si se tratase de una tabla interna. Esto es bueno por ejemplo si diariamente nos llega un informa y lo tenemos que pasar a una tabla de oracle. Con esto podemos dejar el informe en una ubiciacion de la máquina, crear la tabla externa y cada vez que pongamos un nuevo fichero se actualizarán los datos de esa tabla externa.

En este tipos de tabla solo se puede leer, no se puede indexar ni ejecuar ordenes dml. Lo más complicado de este tipo de tablas es saber delimitar bien los campos para la tabla.

===CREACIÓN DE UNA TABLA EXTERNA===

Lo primero es crear una estructura de oracle que se llama directorio. Esta referencia un directorio físico del sistema.

CREATE DIRECTORY DIR_COMENTARIOS AS 'c:\comentarios';

Despues habrá que crear la tabla pero con la clausula ORGANIZATION EXTERNAL 

CREATE TABLE sugerencias (columnas... ) ORAGANIZATION EXTERNAL...

Con esto podemos acceder a la tabla como si fuera una más




EVALUACIÓN DEL CURSO: Juan Carlos Manzanares (916533100) Para preguntas sobre el curso o sugerencias.




=INDICES=

Se crean para acceder a los datos de forma más rápida para columnas de búsquedas.

Todos los índices de oracle se almacena de una forma de estructura de arbol invertida. Es como una tabla en la cual aparece dos campos, en una columan tenemos el dato indexado y en la otra columan, asociado al dato de la columna aparece el rowid de donde comienza la fila. Esto es una simplificacion real de un indice, porque realmente tiene estructura de arbol invertido. Crea una serie de nodos intermedios y una serie de nodos finales (hojas) los nodos finales, las hojas, son los que tiene el rowid.

Todos los índices siguen esa estructura, sea bitri, bitmap, inverso, etc. La única diferencia es el contenido de los nodos finales (hojas)

Cada índice es un segmento de tipo index. Al ser un segmento independiente puede estar en el mismo o no tablespace que la tabla a la que referencia. Lo normal es que estén en diferentes tablespaces. 

Hay dos tipos de indices:

B-tree
Bitmap

son arboles binarios, es decir, que el padre solo tiene dos hijos. Hace la historia esta de crear valores intermedios para saber a que sitio ir. Ejemplo de saber en 7 pasos un numero del 1 al 100. Realmente no se hace con arboles binarios puros, puesto que el rendimiento sería bestial ... imaginar un arbol binario de 10000000000 valores... así que en realidad cada nodo no tiene solo dos valores... (estoy sería bueno mirarlo mejor)

Los arboles b-tree: En cada hoja apareceran varias valores, la cabezera, la longitud de la columna y el valor, y al final aparece el rowid al que corresponde la fila fisicamente. Después aparece un puntero al siguiente elemento y un puntero al anterior. 

La cabecera: almacena el numero de columans y informacion obre los bloqueos
pares de claves: tantos pares como columnas correspondan al indice. Formados por lds valores 
rowid: ¿?

El unico parametro que no se puede cambiar es el pctused, el resto de los parametros del segmento se pueden configurar igual que una tabla. No se guardan los nulos en los indices, si hacemos una busqueda por un valor nulo en una tabla que tiene un indice pasará del indice y hará un full scan.

Cuando creo un índice está muy bien para búsquedas, para select, pero puede bajar el rendimiento cuando hago operaciones de DML

INSERT: Inserta una entrada de indice en el bloque
DELETE: bORRA LA ENTRADA DEL INDICE DE BLOQUE CORRESPONDIENTE. eL ESPACIO LIBERADO NO PODRA Vover a ser reutilizado hasta que se borren las entradas del bloque.
UPDATE:La actualizacion de los campos calve de un indice .... el borrado y la inserccion de una nueva entrada.

Si la uperacion DML es superior al 20% de las filas de la tabla es recomendable borrar el índice y volver a crearlo después.

Los arboles bitmap: 


(...)


Se utiliza un indice bitmap cuando la columna sobre la que se va a indexar tenga una cardinalidad sea baja, o lo que es lo mismo, cuando los valores se repiten mucho.Los valores que haya en la columna sea bastante elevados.

Como saber la cardinalidad es alta o baja, oracle recomiendoa que sea un 1% del total de las filas. POr ejemlo... en una tabla de 1000000 de registro que solo haya 10000 tipos de valor.

Cuando tenemos una columna que no tiene tanta cardinalida, pero hacemos mucha consultas con la clausula or, ya que hace las sumas del mapa de bits y lo hace muy rápida. Casi siempre se utilizan estos indices en dbs de tipo warehouse, porque suelen muchas consultas pero pocas modificaciones.

para cualquier otro elemento usamos btree.

Se crea con:

CREATE BITMAP INDEX on TABLA(COL1,COL2,...)

Podríamos definir el pctfree pero no podemos usar el pctused, porque lo usa el oracle internamente.

Con estos índices se trabaja en memoria, si trabajamos con muchos índices bitmap lo bueno sería crear el bitmap_area_size, para guardar los índices bitmap cuando son utilizados por el gestor. Por norma general tiene un tamaño de 8Mb.

====ALGUNAS OPERACIONES QUE SE PUEDEN AHCER CON LOS INDICES=====

Se puede gestionar los segmentos de un indice para optimizar su uso.

Antes de hacer una inserccion se puede preparar el índice para empezar a indexar datos. Podemos usar ALTER INDEX nombre ALLOCATE EXTENT (SIZE... DATAFILE...);

Con esto facilitamos al sistema que la operacion de insertado sea más rápida. Si nos hemos pasado asignando memoria y sobra mucho podeoms hacer despues:

ALTER INDEX nombre DEALLOCATE UNUSED;

Un truncado de la tabla implica un truncado de los índices, es decir, que se liberan los segmentos usados por el indice.

Todos los parametros que poniamos a la hora de crear una tabla para la gestion del almacenamiento valen para la creación de los indices, salvo el pctused, que se puede especificar pero no le hará caso.

Igual que ocurre con las tablas cuando hacemos muchas insercciones o actualizaciones, la tabla por dentro se van quedando libres bloques y extensiones y la tenemos desfragmentada. Para solucionar esto podemos reconstruir el índice y a la vez organizar ese índice. Contra ménos fragentado esté el índice más rendimiento vamos a sacar.

Aqui tenemos dos opciones: REBUILD y COALESCE. Las dos reorganizan el índice pero de formas diferentes. Siempre podemos hacer un borrar el índice y volver a crearlo tambien.

Con Rebuild le podemos decir que nos recree el indice a otro tablespace.

ALTER INDEX nombre REBUILD TABLESPACE nombre_ts

Tambien se puede reconstruir en el mismo tablespace!!

Tambien podemos hacer un:

ALTER INDEX nombre REBUILD ONLINE

Esto lo que hace es crear un indice nuevo con el misom nombre en un lugar diferente. Esto se usa cuando tenemos un índice correcto, que solo está fragmentado, y conseguimos que sin perder el servicio del indice se reconstruya. Este es más lento que un rebuild normal.

Con COALESCE hace lo mismo que el REBUILD ONLINE pero reutilizando el espacio donde está el índice. este es aun más lento que el rebuild, y además el índice está disponible tambien

El resultado de cualquiera de estos comandos es el mismo.

==== INDICES EN EL DICCIONARIO DE DATOS====

DBA_INDEXES
DBA_IND_COLUMNS: informaicoln de las columnas indexadas en un indice
DBA_IND_EXPRESSIONS: para ver los indices basados en funciones
INDEX_STATS:para recoger estadisticas de los indices.




=SEGURIDAD EN LA BASE DE DATOS=

La seguridad de oracle se base en un uusario y una contraseña. a nivel de seguridad disponemos de diferentes tipos: de acceso a base de datos (quien puede acceder, si pueden crear o acceder a los ts, a los objetos en general, a la session de usuario, si pueden hacer transacciones), y la seguridad de los objetos de la base de datos (que pueda acceder a una tabla, a una columna, objetos en concreto... ) y finalmente la seguridad de acceso a los comandos.

ESQUEMA

Un esquema es el conjunto de objetos propiedad de un usuario. Cuando me conecto a la base de datos voy a utilizar un esquema. Un usuario siempre tiene un esquema asignado y un esquema siempre tiene un usuario.

Que puede haber dentro de un esquema:

tablas
restricciones
indices
vistas
secuencias
sinonimos
programas almacenados (procedimientos, funciones y paquetes)
disparadores
tipos de datos definidos por el usuario
enlaces a BBDD
...

USUARIOS

Antes de dar de alta un usuario lo priemro que hay que saber es si va a crear algun objeto donde lo va a crear. Por defecto en 10g lo crea en el ts user (antes era en el system). Cuando creo un usuario tiene libertad para crear objetos en cualquier tablespace, para lo cual tenemos que asignar cuotas sobre cada uno. Lo normal es que el ssytem tenga cuota 0, el sysaux tambien, y el users x Megas.

En la creación le tenemos que asignar con el tablespace por defecto de trabajo, y el tablespace temporal. si no decimos nada es el user y el temp.

Después de crear el usuario habrá que conceder privilegios al usuario.

CREACIÓN DE UN USUARIO:

CREATE USER nombre
		IDENTIFIED {BY clave | EXTERNALLY}
		DEFAULT TABLESPACE tablespace	
		TEMPORARY TABLESPACE tablespace
		QUOTA {entero | UNLIMITED} ON tablespace
		PASSWORD EXPIRE
		ACCOUNT {LOCK | UNLOCK}
		PROFILE perfil;

IDENTIFIED BY podemos poner por clave o bien con EXTERNALLY que la identificacion no la hace oracle sino que queda en manos del sistema operativo.

QUOTA, el numero de megas, o ilimitado, sobre un tablespace, se puede repetir el comando tantas veces como sea necesario.

PASsWORD EXPIRED, la primera vez que se conecte tiene que cambiar la passwrod

ACCOUNT  para decir si está bloqueada o no

PROFILE le asigna un perfil especifico al usuario.


La creación de los usuarios solo la puede hacer el DBA o los usuarios que tengan privilegios de CREATE USER.

Si no defino el teblespace por defecto o el tablespace temporal por defecto son users y temp.

Debo especificar la quota separada por tebalespace

PROFILE es el conunto de parametros sore los recuros que el DBA puede especificar para los usuarios para limitar el uso del servidor.



Después de crear el usuario hay que concederle roles a los usuarios. Por ejemplo, el primer rol que se suele asignar es el de CONNECT, que hace que permita al usuario conectarse a la base de datos.

Esto se hace con GRANT "CONNECT" ON "PMB";


Para borrar un usuario:

DROP USER username;

Para borrar un usuario este no ha de estar conectado a la base de datos. 


select * from v$session where username=usuario

Si está conectado hay que bloquearle la cuenta o cambiar la password, después habrá que matar la sesión del usuario y después borrar la cuenta de usuario.

Si el usuario ha creado objetos no puede ser borrado con la orden drop user nombre, porque hay objetos dependientes de ese esquema. Para poder borrarlo podeoms poner drop user nombre cascade. Con eso se borran todos los objetos del usuario y el usuario. Si queremos conservar los objetos habrá que hacer antes un export de borrarlo.

=== PARAR UNA SESION ===

ALTER SYSTEM KILL SESSION sid;


==PRIVILEGIOS==

Se usan las sentencias GRANT Y REVOKE.

Se pueden dar dos tipos de privilegios:

SISTEMA (crear tablas, crear sinonimos, crear vistas, crear ... )

OBJETO (se dan a un objeto en concreto).

Un rol es un conjunto de privilegios.

Para dar privilegio de sistema

GRANT privilegio TO usuario|rol|public WITH ADMIN OPTION

WITH ADMIN OPTION hace que el usuari pueda conceder a su vez el privilegio a otros usuarios o roles

La palabra reservada ANY en el privilegio indica que ese privielgio es concedido en cualquiero esquema


Revocacion de privilegios

REVOKE privilegio FROM usuario|rol|public

REVOKE solo puede revocar priviegios que han sido conecdidos directqamente con el comando GRANT
Si hay objetos dependientes pueden quedar invalidados

No tiene efectos en cascada, es decir que si al usuario 1 le quito los permisos y 1 dio permisos a 2, 2 seguira teniendo dicho permiso.

PRIVILEGIOS SOBRE OBJETOS

GRANT privilegio(columna)|ALL PRIVILEGES ON objeto
TO usuario|rol|public
WITH GRANT OPTION

WITH GRANT OPTION hace que el usurio pueda conceder a su vez el privilegios a otros usuarios

Para la revocación 

REOVKE privilegio|ALL PRIVILEGES ON objeto
FROM usuario|rol|public
CASCADE CONSTRAINTS


REVOKE solo puede revocar privilegios que han sido concedidos directamente con el comando GRANT
CASCADE CONSTRAINTS borra cualquier restricción de integridad referencial que se haya definido usnado los priviegios REFERENCES o ALL
Tiene efectos en cascada, si 1 dio permisos a 2 y se lo quito a 1 tambien se quita a 2

===ROL===

Es un conjunto de privilegios

CREATE ROLE nombre


Despues se asignan permisos a esos roles, y a un usuario se le puede meter en un rol

Hay muchos roles ya predefinidos:

El connect da los permisos necesarios para que un usuario se pueda conectar a la base de datos
El resource posibilita crear objetos.
dba
exp_ful_database
imp_ful_database

TABLAS DEL DD para información sobre roles:

DBA_ROLE_SYS_PRIVS
ROLE_TABS_PRIVS
USER_ROLE_ROLE_PRIVS
DBA_SESSION_ROLES


Para asignar un rol por defecto a todos los usuarios

Perfiles

se le pueden asignar difernetes recursos para los usuarios

Espacio de ocupacion de tablas y tablespaces
tiempo de cpu por sesion /llamada
lecturas por sesion /llamada
tiempo de conexioin
...

La ocupacion se limta a crear o modifcar el usuario. E resto de parametros se ajusta mediante la asginacion de un perfil