Grupo 4

L00276703 RAMOS VILLACIS DIEGO FERNANDOL00325826 RIVADENEYRA JARAMILLO TEODOROL00331521 SIMBAÑA SARANSIG WILSON JAVIERL00291267 ARIAS TORRES DIEGO GERMAN

ContenidoDesarrollo...........................................................................................................................................2

Conclusiones....................................................................................................................................11

Bibliografía y Webgrafía...................................................................................................................12

Blog..................................................................................................................................................13

Desarrollo

1.- En base al diagnóstico del punto 2 de la actividad interactiva 1 realizar los cambios necesarios

en la base de datos de tal forma que cuando usted genere los procesos o scripts de saturación de

la base en forma automática no sature la base de datos. Describir paso a paso los cambios

realizados y su demostración.

(Anexar los procesos o scripts de saturación)

Primero verificamos las sesiones que se encuentran en la base, además podemos verificar el número de sesiones por usuario.

También antes de ejecutar el archivo revisaremos las estadísticas mediante el Oracle Enterprise Manager.

Ejecutaremos el archivo para que se creen las sesiones.

Miramos las estadísticas después de ejecutar el archivo .bat

También observamos mediante los querys que el número de sesiones aumento.

Podemos observar el número de sesiones activas que están saturando la base de datos.

Para evitar la saturación de la base de datos se va utilizar perfiles de usuario, los cuales pueden

contener los siguientes parámetros:

PASSWORD_LIFE_TIME - Tiempo de vida en días del password.

PASSWORD_GRACE_TIME - Periodo de gracia en días para cambiar el password una vez

expirado el mismo. Empieza a partir del primer intento de logeo una vez expirado el

password.

FAILED_LOGIN_ATTEMPS - Número de intentos fallido de acceso antes del bloqueo de la

cuenta.

PASSWORD_LOCK_TIME - Número de días en que la cuenta está bloqueada después del

numero especificado de intentos fallidos.

PASSWORD_REUSE_TIME - Numero de días que deben pasar antes de que un password

pueda ser reusado.

PASSWORD_REUSE_MAX - Numero de veces que un password puede ser reusado.

CPU_PER_SESSION - Total de tiempo de CPU medido en centésimas de segundos.

SESSIONS_PER_USER - Numero de sesiones permitidas para un usuario.

CONNECT_TIME -Tiempo transcurrido de conexión medido en minutos.

IDLE_TIME - Periodos de tiempo de inactividad medido en minutos.

LOGICAL_READS_PER_SESSION - Numero de data blocks (lecturas físicas y lógicas).

PRIVATE_SGA - Espacio privado en la SGA medido en bytes (Para Shared Server

solamente).

CPU_PER_CALL - Tiempo de CPU por llamada en centésimas de segundos.

LOGICAL_READS_PER_CALL - Numero de Data Blocks que pueden ser leídos por llamada.

Para este caso en concreto donde se quiere evitar la saturación de la base de datos por sesiones

de usuario se utiliza el parámetro “sessions_per_user”.

Como primer paso se procede a observar el perfil por defecto con el siguiente comando:

Aquí se observa que las sesiones por usuario en perfil por defecto son “Ilimitadas”.

Ahora se crea un nuevo perfil con los siguientes comandos:

Se verifica el perfil creado:

Asignamos el perfil “PROFILE_ESPEPAC” al usuario “ESPE_PAC” con el siguiente comando:

Para que los cambios tomen efecto se debe utilizar la siguiente declaración para alterar

dinámicamente la instancia de base de datos.

En el perfil espe_pac se especifica hasta 3 sesiones por usuario.

Una vez asignado el perfil al usuario procedemos a ejecutar de nuevo el archivo bat. En esta

ocasión el mensaje de error al querer iniciar más de 3 sesiones con el mismo usuario es el

siguiente.

Al consultar las sesiones por usuario directamente en la base de datos el resultado es el siguiente:

Como se puede observar las sesiones del usuario espe_pac son 3 lo que indica que el archivo bat

ya no tiene la capacidad de saturar la base de datos.

2.- Desarrollar una simulación de pérdida de la base de datos e indicar paso a paso su

recuperación. La simulación se basara en la pérdida física de la base de datos que reside en un

disco.

La pérdida de una base datos se puede dar por algunas razones éntrelas más comunes tenemos

daño físico del disco duro donde se almacena la base de datos, o que no estén bien definidos los

permisos a los usuarios hacia el servidor y este borre el archivo de la base de datos.

Para ello es recomendable tener respaldos de la base de datos así como también tener sistemas

de discos redundantes para garantizar que los datos en su momento sean recuperables.

Existe una opción en las bases de datos Oracle que permite guardar log, de todos los cambios que

vaya efectuando la base de datos, con estos archivos es posible recuperar una base de datos que

sea eliminada físicamente.

1. Verificamos que la bd de datos Oracle tenga activa esta opción.

2. En caso de no estar activa la opción de log de la base de datos la activamos.

3. Se identifica el valor de la base de datos y la ubicación de la misma.

4. Se elimina la base de datos del disco.

3.- Indicar como mínimo cuatro parámetros que se deben modificar para mantener la seguridad

de nuestra base de datos principalmente cuando se utiliza los comandos sqlplus / as sysdba.

Existen dos aspectos en seguridad de una base de datos oracle que hay que considerar:

Seguridad del Sistema: Permisos del sistema tales como control de acceso y uso de la base de

datos.

Seguridad de los Datos: Mecanismos de control de acceso y uso de la base de datos a nivel de

objetos (tablas, vistas, usuarios), en general los permisos a nivel de objetos.

Los factores más importantes que se pueden limitar se resumen a continuación:

SESSION_PER_USER: El número de sesiones concurrentes que un usuario puede tener en una

instancia

CPU_PER_SESSION: El tiempo de CPU, en centenas de segundos, que una sesión puede utilizar

CONNECT_TIME: El número de minutos que una sesión puede permanecer activa

IDLE_TIME: El número de minutos que una sesión puede permanecer sin que sea utilizada de

manera activa

LOGICAL_READS_PER_SESSION: El número de bloques de datos que se pueden leer en una sesión

LOGICAL_READS_PER_CALL: El número de bloques de datos que se pueden leer en una operación

PRIVATE_SGA: La cantidad de espacio privado que una sesión puede reservar en la zona de SQL

compartido de la SGA

COMPOSITE_LIMIT: El número de total de recursos por sesión, en unidades de servicio. Esto

resulta de un cálculo ponderado de CPU_PER_SESSION, CONNECT_TIME,

LOGICAL_READS_PER_SESSION y PRIVATE_SGA, cuyos pesos se pueden variar con el comando

ALTER RESOURCE COST.

Ingreso a sqlplus como SYSDBA

Existen maneras de ingresar a SYSDBA con sqlplus sin conocer el password.

Si se dispone de un acceso via "root" al servidor de la base de datos se puede acceder de la

siguiente forma:

# su – oracle

$ whoami

oracle

Podemos ingresar a sqlplus de la siguiente forma:

$ sqlplus /nolog

$ show user

SQL> show user

USER is “”

SQL> connect /as sysdba

SQL> show user

USER is “SYS”

Para evitar esta falla de seguridad se debe realizar lo siguiente:

Hay que sacar del grupo “dba” a todos aquellos usuarios de S.O y dejar el grupo vacio. De esta

manera, al entrar a sqlplus, se nos solicitará el password.

Otra opción consiste en:

Editar el archivo “$ORACLE_HOME/rdbms/lib/config.c” y hacer referencia a un falso grupo vacío.

Posteriormente, “volver a vincular todos”, para volver a conectar todos los componentes de

software de Oracle con el nuevo “grupo vacío” Oracle DBA.

Conclusiones

La creación de perfiles de usuario es útil para varios ámbitos entre los que se incluye el

asignar a cada perfil un límite para las sesiones por usuario.

Para analizar el estado de una base de datos se puede utilizar varias herramientas como

TOAD, El mismo Enterprise Manager de Oracle o inclusive mediante querys directo a la

base.

El uso de herramientas de diagnóstico de base de datos, permite realizar pruebas que

miden el comportamiento de nuestro sistema bajo una cierta demanda concurrente de

conexiones.

La creación de perfiles por usuario nos ayuda con la seguridad y a tener el control de la

base de datos.

Bibliografía y Webgrafía

http://docs.oracle.com/cd/E11882_01/server.112/e26088/statements_6010.htm

https://www.youtube.com/watch?v=wPrw7_dNVL4

http://docs.oracle.com/cd/B19306_01/network.102/b14266/admusers.htm

http://docs.oracle.com/cd/B12037_01/server.101/b10759/statements_2013.htm

http://subway-shop.com/blogcolacios/tag/as-sysdba/

http://www.desarrolloweb.com

Blog

El trabajo realizado lo publicamos en un blog creado por nuestro grupo, la dirección de blog es la

siguiente:

http://dbespepacgrupo4.blogspot.com/