You are on page 1of 6

CURSO ORACLE Madrid, 7 de abril de 2010 (Antonio) Huelva, 13 de abril de 2010 (Godo) Arquitectura y conceptos - Base de datos: Compuesta

de DATAFILES, CONTROL FILES y REDOLOGS. - Instancia/SGA: Conjunto de procesos y memoria asignada en una máquina. Una base de datos es el conjunto de ficheros de datos. A esos ficheros de datos se puede acceder desde una instancia o desde varias, y desde un servidor o desde varios. Una instancia sólo puede estar asociada a una base de datos. Pero a una base de datos se puede acceder desde distintas instancias, por ejemplo usando RAC. Hay que conocer bien el gráfico de la arquitectura para la certificación. Métodos de configuración de la instancia - Dedicated: Recursos dedicados para cada conexión. Se crea un proceso de servidor por cada conexión y dicho canal permanece siempre abierto para dicha conexión. Método más seguro y estable para pocas conexiones. - Shared: Recursos compartidos para todas las conexiones. Se crean los procesos servidores que hemos definido para gestionar todas las conexiones. Los canales de cada proceso de servidor son compartidos entre los clientes. Método menos seguro y menos estable pero adaptado a aceptar mayor números de conexiones concurrentes. PGA: Area de memoria donde se crean los procesos de servidor. Ver los procesos de servidor: SQL> show parameter shared # ps -ef | grep ora_s000_INSTANCIA Ver los dispatcher (max_dispatchers suele ser el 10% de los procesos de servidor): SQL> show parameter dispatcher # ps -ef | grep ora_d000_INSTANCIA Gestión de la instancia Usuario: SYS / SYSDBA

la manera de ejecutarlas. Lo que hagas de forma dinámica desde SQL. Si esto no funciona. conlleva posibles inconsistencias. si usas init_SID. a que terminen todas las operaciones pendientes.ora. Arranque de la base de datos: startup nomount: Levantamos procesos en memoria y leemos configuración del pfile/spfile. Parámetros de memoria a tener en cuenta . no los datos.ora: sí es dinámico con algunos parámetros. startup open: Abrimos los ficheros de datos (datafile) para interactuar con ellos. - - Parada de la base de datos: shutdown normal: Espera a que las conexiones activas se cierren. Hace falta vaciarla si queremos que ORACLE analice de nuevo el camino a tomar si han habido grandes cambios en las tablas que vamos a consultar. Estos planes de ejecución son analizados automáticamente por ORACLE. A no ser que vaciemos esta cache. podemos copiarlo a pfile (initSID. spfile_SID. En caso contrario. Luego quitamos el spfile para que ORACLE lea del initSID. la base de datos levantará sin problemas pero nos quedaremos con inconsistencia en los datos. teniendo sólo la opción de RMAN para recuperar los datos. ORACLE no forzará a un nuevo análisis del plan . los cambios desde SQL de forma dinámica puedes guardarlo opcionalmente en el spfile_SID.ora necesitas meterlo a mano en el fichero. shutdown abort: Mata los procesos (kill) sin confirmar ni comprobar nada.ora: nunca es dinámico.ora para que lo lea en el siguiente reinicio de la instancia.Ficheros de inicio: init_SID. shutdown immediate: Cierra las conexiones y hace rollback de las transacciones pendientes sin confirmar con commit. aunque no es aconsejable. Esto siempre que no puedas levantar la instancia con nomount y no puedas usar el comando: CREATE PFILE FROM SPFILE. cambiarlo y reiniciar la instancia. Debemos estar seguros de tener acceso a todos los datafiles cuando hacemos el mount. startup mount: Enlaza los procesos de memoria con los ficheros (datafiles) leyendo de los controlfiles. Si alguna vez no levanta la base de datos por errores en los parámetros de inicialización del spfile. Podemos cambiar parámetros de iniciación en pfile/spfile.ora) y quitar los carácteres binarios. necesitas editarlo.Shared Pool: Guarda los planes de ejecución de las últimas consultas. podemos hacer un kill 9 de los procesos pmon/smon. hace un commit y cierra las sesiones.

DDL: Son operaciones de definición contra el diccionario de datos: create. No se puede forzar a que una consulta permanezca en memoria. Hay muchas opciones de configuración. Una vez que se hace un commit. con el fin de poder ofrecer mayor velocidad a las consultas más usadas ya que mientras quepan en la caché serán guardadas en memoria. Solamente las DML son transaccionales. Hasta que la misma session que realiza la operación no hace un commit o un rollback. Se puede lanzar un proceso de checkpoint manual con: SQL> alter system checkpoint. . la primera en entrar es la primera en salir siempre que no se vuelva a usar. drop & truncate. Existe un proceso que se encarga de pasar los commit a los ficheros de datos llamado CHECKPOINT. sólo podríamos restaurar con RMAN o con ARCHIVELOGS. otra session no verá los cambios hasta que se realice el commit. alter. que son segmentos del tablespace UNDO. se pueden definir tablas que no pasen por el buffer. no se pasa esa información a los ficheros de datos.de ejecución de la consulta que vamos a lanzar. Con lo cuál. En la SHARED POOL entrarían consultas. update & delete. Este proceso es casi instantáneo.DML: Son operaciones de manipulación de datos: insert.Database Buffer Cache (DB_CACHE_SIZE): Caché donde se almacenan los bloques de datos que se han leído en disco. . a no ser que la carga sea muy alta. etc. En realidad. conforme van entrando van saliendo. cursores. cuando se hace el commit las operaciones se marcan como “aprobadas” en los segmentos de rollback y el proceso de CHECKPOINT se encargará de pasarlas a los ficheros de datos. procedimientos. En esta caché sí se guardan los datos obtenidos en las últimas consultas. . esta se guarda en los segmentos de rollback. la estancia es secuencial. se pasan los cambios a los REDO y a partir de ese momento es imposible realizar un rollback. Modo transaccional Cada vez que se realiza una operación DML a la base de datos. Tipos de operaciones .

que a su vez están compuestos de extensiones. El diccionario de datos contiene la estructura de todos los objetos: tablas. Un . Es como el crontab para ORACLE. que a su vez están compuestos de bloques. Este usuario puede o no puede tener objetos. La estructura lógica la componen los tablespaces. usuarios. Cuando un usuario posee objetos. vistas. Diferencia entre usuario y esquema Un usuario se usa para poder acceder a la instancia con un nivel concreto de permisos o privilegios. Jobs: Tareas que ejecutan algo de forma automática cada cierto tiempo. Se suelen usar para pasar datos entre diferentes procedimientos o funciones. Se diferencian con los procedimientos en que éstas devuelven un valor y los procedimientos no suelen devolver nada. etc. Una extensión son grupos de segmentos contiguos. sólo ejecutan. tablas. Son los ficheros o dispositivos de almacenamiento que componen los tablespaces.Estructura física y lógica La estructura física la componen los datafiles. ya tiene automáticamente un esquema. Dentro de cada tablespaces pueden haber diferentes objetos: usuarios. Los segmentos son grupos de bloques contiguos. esquemas. Objetos Paquete: Es un contenedor de procedimientos y funciones. etc. Procedimientos: Son ejecuciones de código que se guardan en la base de datos para ejecutarse en cualquier momento con: SQL> EXEC user. y puede o no puede realizar una serie de cosas. el nivel más alto de la estructura lógica. que a su vez están compuestos de segmentos. Hay un tablespace SYSTEM donde se guarda el diccionario de datos.procedure. Se puede ejecutar antes o después de dicho evento. Funciones: Son ejecuciones que devuelven algún valor. Triggers: Ejecutan algo cuando se recibe algún evento.

Pero los dispositivos RAW no puede variar de tamaño. ni siquiera acceder a la instancia. y podemos crear los que queramos siempre que tengamos espacio en el volumen. Para matar una session necesitamos el SID y el SERIAL: SQL> alter system kill session ‘SID. Cuando creamos un usuario. Debemos dar permisos a cada acción que queramos para dicho usuario: SQL> show user SQL> conn / as sysdba SQL> grant create session to USER. sólo dispone de privilegios para realizar una serie de acciones. ctime from v$lock where block > 0. SQL> select * from v$session where logon_time > SYSDATE -1. SQL> conn USER/PASS SQL> show user Un tablespaces se puede repartir entre distintos datafiles con el fin de crecer en tamaño o repartir entre distintos dispositivos para ganar en velocidad y rendimiento. Estos dispositivos pueden ser ficheros físicos. Para aumentar un tablespace que use dispositivos RAW necesitamos un nuevo dispositivo RAW para añadir a tablespace. SQL> grant connect to USER. SQL> select sid. executions from v$sql where cpu_time > 200000. Vistas de rendimiento dinámico: SQL> select sql_text. Los ficheros físicos pueden variar de tamaño.esquema es algo parecido a una vista dinámica de los objetos de un usuario. no dispondrá de esquema. ya que son dispositivos enteros. SQL> grant resource to USER. SERIAL’ immediate. en caso contrario usaría el tablespace SYSTEM (no recomendado). se guarda siempre en el diccionario de datos. Al momento de crear un usuario. éste no puede hacer nada. Podemos tener un tablespace en modo lectura: SQL> alter tablespace TABLESPACE read only. . SQL> grant create table to USER. SQL> alter tablespace TABLESPACE read write. al igual que la creación de algún objeto. dispositivos RAW o instancia +ASM. éste es guardado en el diccionario de datos. Si un usuario no tiene ningún objeto. Un usuario se puede crear asignándole por defecto un tablespace.

Cambiar password de usuarios de sistema: SQL> conn / as sysdba SQL> passw system SQL> conn system/passw SQL> passw sys Crear configuración del EM dbconsole: # emca -repos create # emca -config dbcontrol db # emctl start dbconsole # emctl stop dbconsole # emctl status dbconsole https://redhat:1158/em .