Trabajo colaborativo 2 del plan de actualización de conocimientos ESPE.

1. TRABAJO COLABORATIVO 2
Grupo 4
L00276703 RAMOS VILLACIS DIEGO FERNANDO
L00325826 RIVADENEYRA JARAMILLO TEODORO
L00331521 SIMBAÑA SARANSIG WILSON JAVIER
L00291267 ARIAS TORRES DIEGO GERMAN

2. Contenido
Desarrollo............................................................................................................................................ 2
Conclusiones ..................................................................................................................................... 14
Bibliografía y Webgrafía.................................................................................................................... 15
Blog.................................................................................................................................................... 16

3. 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.

5. Ejecutaremos el archivo para que se creen las sesiones.
Miramos las estadísticas después de ejecutar el archivo .bat

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

7. 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.

8.  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”.

9. 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.

10. 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.

11. 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.

12. 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

13. 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:

14. 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.

15. 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.

16. 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

17. 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/