6.7. PARANDO UNA BASE DE DATOS

Antes de todo hay que saber que para parar una base de datos hay que usar el comando «shutdown», y que hay 4 tipos de «shutdown»:

El primero es el normal, esto quiere decir que Oracle no permite nuevas sesiones en la base de datos y que espera a que todos los usuarios salgan de su sesión de forma voluntaria, esta opción nunca es utilizada ya que si un usuario por algún motivo está horas sin salir de la sesión, la base de datos no se apagará hasta pasada esas horas y el usuario salga de su sesión.

Luego tenemos el «shutdown immediate», y lo que hace es terminar todas las transacciones, pero no las deja que termine, si una transacción está a mitad de proceso, deja la transacción tal como está y apaga la base de datos, por ejemplo, si una transacción actualiza un millón de registros y hacemos el «shutdown immediate» cuando solo lleve la mitad de los registros actualizados, Oracle termina la transacción con la mitad de los registros actualizados y la otra mitad no.

Todas las transacciones terminadas con el «shutdown immediate», serán echadas hacia atrás, cuando la base de datos vuelva a ser arrancada, es decir, la transacción anterior dejó la mitad de los registros actualizados y la otra mitad no, pues Oracle, al volver a arrancar la base de datos lo que hace es un «rollback» sobre los registros actualizados, dejándolos con el valor que tenían antes de ser actualizados.

Esta es una de las propiedades de Oracle, si una transacción no termina correctamente, nunca se puede dejar a medias, automáticamente realizará un «rolback» sobre ella, para volver a dejar los datos tal como estaban.

Por ejemplo si fuéramos a sacar dinero del banco y se actualizara nuestra cuenta con la retirada del dinero y al dárnoslo se produjera un error, no se puede permitir que en nuestra cuenta salga que hemos retirado el dinero, por lo que se hace un «rollback» sobre la operación y se deja tal como estaba antes de hacer la operación de retirada. El error no se ha solucionado, pero los datos están correctos en todos los sitios.

Por tanto cuando se hace un «shotdown inmediate», al arrancar la base de datos, se hace un «rockball» sobre las transacciones que no estaban confirmadas.

El tercer «shutdown» es el transaccional, y lo que lo diferencia del «inmediate», es que sí permite terminar las transacciones. Con el ejemplo anterior, permitiría que la transacción terminara de actualizar todos los registros y una vez terminadas todas las transacciones, se apaga la base de datos.

Y por último tenemos el «shutdown abort», esto lo cierra todo de golpe, equivale a un apagado de luz, por lo que al volver a arrancar la base de datos vamos a necesitar un «recovery», que es una recuperación de la base de datos.

Por ejemplo cuando estamos con el «Windows» y se va la luz, cuando volvemos a arrancarlo, nos muestra un mensaje con un porcentaje indicando que el sistema se está recuperando; pues con el «shutdown abort», ocurre lo mismo, la base de datos tiene que ser recuperada y además esta recuperación no suele se rápida, puede durar hasta horas.

Todas estas recuperaciones se realizan de forma automática, pero cuantas más operaciones sin terminar estén afectadas, más tiempo se tardará en recuperar.

1. Indicaciones para probar cada uno de los «shutdown»

Teniendo en cuenta todo esto, por lo general siempre haremos un «showdown inmediate», aunque después sea necesario realizar un «rollback» sobre las transacciones, porque las otras opciones implican tardar mucho en el apagado, tiempo que generalmente no nos dan; o apagar de forma brusca cosa que nunca debemos hacer aunque tengamos la opción de recuperación.

Tenemos que recordar que antes de conectarnos a una base de datos tenemos que configurar las variables de entorno y que si queremos hacer operaciones de arrancado o apagado de una base de datos tenemos que hacerlo con el usuario sys. Por lo que tecleamos punto espacio «oraenv» y ponemos el nombre de la base de datos con la que queremos trabajar que es «orcl».

Ahora vamos a ejecutar el «sqlplus», por lo que tecleamos «sqlplus», pulsamos «intro» y como vamos a proceder a apagar la base de datos pues escribimos el nombre del usuario sys y en contraseña vamos a meter la contraseña. En este caso no se muestran los caracteres porque al ejecutar el «slqplus» no se indicó el usuario, por lo que se ejecuta de esta forma, una vez introducida la contraseña, no se nos puede olvidar, teclear as «sysdba», porque si no nos dará un error.

2. Probando el «shutdown normal»

Ya estamos conectados al «sql», y lo sabemos porque nos ha cambiado el «pront», ahora vemos que pone «sql». Si tecleamos el comando «shutdown», podríamos ejecutarlo sin indicar el tipo de «shutdown» a realizar, pero en este caso, por defecto, hará un «showdown» normal, es decir, no permite nuevas conexiones a la base de datos, pero no cierra ninguna conexión existente, por lo que hay que esperar a que todo el mundo salga.

Para ver cómo funciona podemos ir al segundo escritorio, dónde hay abierto otro terminal. Aquí vamos a imaginar que esto es otra máquina, donde un usuario se va a conectar con la base de datos, por lo cual este usuario lo primero que hará será usar el fichero «oraenv» y se conectará a la base de datos «orcl».

Luego se conectara con el «sqlplus» y como aún no tenemos más usuarios imaginemos que se conecta con el usuario «system» y después pondrá la contraseña y ya estaría conectado a la base de datos.

Si nosotros ahora hacemos un «showtdows» normal a la base de datos, ésta no se cerrará hasta que este usuario salga de su sesión y para verlo volvemos al primer escritorio. Aquí estamos con el usuario «sys», por lo que podemos ejecutar el «shutdown» y podemos ver cómo se queda parado, pues aquí se puede quedar toda la vida, hasta que el usuario del segundo escritorio salga.

Para verlo, vamos al segundo escritorio, y salimos del «sqlplus» con el comando «exit» y si volvemos al primer escritorio podemos ver como la base de datos está cerrada, y se ha cerrado de forma automática cuando hemos cerrado la sesión del escritorio 2.

Nos tenemos que fijar que para cerrar la base de datos primero la ha pasado a estado cerrado y después la ha pasado al estado desmontado y finalmente ha cerrado la instancia; estos son los pasos adecuados para apagar una base de datos.

3. Probando el «shutdown inmediate»

Ahora vamos a probar el «shutdown inmediate», por lo que tenemos que volver a arrancar la base de datos y eso se hace con el comando «startup», lo ejecutamos y aquí podemos ver el tamaño fijado, el tamaño de la estructura de «bufer database» del búfer «redo log» y aquí nos indica que la base de datos se puso al estado montado y después pasó al estado abierto, por lo que ya podemos trabajar con ella.

Antes de realizar el apagado inmediato, vamos al segundo escritorio y nos imaginamos que el usuario se vuelve a conectar otra vez por lo usamos la tecla de la fecha para arriba para mostrar el comando anterior y lo ejecutamos.

El «shutdown inmediate» termina todas las transacciones y al arrancar la base de datos hace un «rollback» de las transacciones, y para ver esto, vamos a crear una tabla con el comando «create table»; nombre de la tabla, ejemplo TABLA1; y entre paréntesis ponemos el nombre de la columna que contiene, por ejemplo valor; y el tipo de datos que va a almacenar, por ejemplo «number», y terminamos con punto y coma. Con este comando lo que estamos haciendo es crear una tabla llamada tabla1 y está formada por un solo campo llamado valor que almacena números.

Si lo ejecutamos, podemos ver cómo se nos muestra el mensaje de que la tabla ha sido creada.

Ahora vamos a insertar un registro, y con esto ya estamos creando una transacción por lo que tecleamos «insert into» nombre de la tabla que es «tabla1», «values 1», y con esto estamos insertando el valor 1 dentro de la tabla.

Y si lo ejecutamos podemos ver cómo se nos muestra el mensaje de que una fila ha sido creada. Ahora mismo si nosotros consultamos la tabla con el comando «select* from tabla1» podemos ver que tiene los datos, pero si otro usuario realiza esta misma consulta no vera este dato, este «insert»; solo lo verá cuando hagamos un «commit». Con el comando «commit» estamos indicando a Oracle que queremos confirmar todos los cambios y que queremos que sean permanentes; si por cualquier motivo, se interrumpiera la sesión, este cambio se desharía, y tendríamos que volver a realizar el «insert».

Por esta razón si ahora se produjera un «showtdow immediate», nos echarían de la sesión y al volver a entrar veríamos que la tabla no tendría datos. Para comprobarlo volvemos a la primera sesión y realizamos el apagado inmediato tecleando shutdown immediate, y lo ejecutamos y si esperamos un poco podemos ver que la base de datos se ha cerrado de forma correcta, primero la ha pasado al estado cerrado, después lo ha pasado al estado desmontado y finalmente ha cerrado la instancia. Pero en el otro escritorio hay un usuario conectado; y si vamos al segundo escritorio, podemos ver que nuestro usuario sigue dentro del «sql» pero verdaderamente nos han echado de la sesión. Lo podemos comprobar realizando la misma «select» anterior; y podemos ver que se nos muestra un error de conexión y esto es porque realmente ya no estamos en la sesión, por lo que para salir podemos usar el comando «exit».

Ahora volvamos a arrancar la base datos por lo que volvemos al primer escritorio y ejecutamos el comando «startup»; y vamos al segundo escritorio volvemos a conectarnos al «sqlplus» y si hacemos la consulta «select * from tabla1»; podemos ver que ya no está el registro que insertamos, y es porque el «shutdown» inmediato a terminado con la transacción y al volver, cuando se volvió a arrancar la base de datos, Oracle hizo un «rollback» sobre la transacción provocando que la tabla volvía a tener los mismos datos que antes de realizar el «insert», que en este caso no había ningún dato.

4. Probando el «shutdown transaccional»

Ahora vamos a probar el tercer «shutdown», que es el transaccional, y vamos hacer el mismo «insert» que antes; por lo que tecleamos «insert into tabla1 values (1) punto y coma»; y vemos que ya está insertado el registro y por tanto la transacción ya se ha empezado. Recordar que cualquier operación que afecte a los datos de una tabla crea automáticamente una transacción. Pues si ahora volvemos al primer escritorio y escribimos «shutdown transactional» y lo ejecutamos, vemos que está parado y esto es porque este tipo de «shutdows» espera a que se terminen todas las transacciones, por lo que hasta que no termine la transacción del escritorio 2, no se puede cerrar la base de datos.

Recordemos que el «shutdown inmediate», no espera a que termine la transacción, si no que la termina él. Para terminar la transacción vamos al escritorio 2 y tecleamos «commit punto y coma», con esto estamos indicando que queremos confirmar que los cambios sean permanentes; provocará que la transacción termine, y si lo ejecutamos, vemos como seguimos en la sesión pero si volvemos a realizar una consulta sobre la tabla se nos muestra el mensaje que la conexión está perdida y esto es porque al realizar el «commit» hemos confirmado la «transsacion» y el «shutdown inmediate» lo ha sabido y nos ha echado de la sesión. Para salir de «sql» tecleamos «exit»

Ahora si volvemos al escritorio 1, vemos como la base de datos se ha cerrado, y se ha cerrado cuando hemos confirmado la transacción del escritorio 2.

Vamos a comprobar si los datos se han guardado realmente en la tabla por lo que arrancamos la base de datos; vamos al escritorio 2 y nos conectamos al «sqlplus» y consultamos la tabla con el comando «select * from tabla 1 punto y coma» y podemos ver que tenemos el registro creado, a diferencia del «shutdown inmediate», que deshizo el «insert».

5. Probando el «shutdown abort»

Ahora para finalizar vamos hacer un «shutdown abort» por lo que volvemos al escritorio 1 y si hacemos un «shutdown abort», lo que estamos haciendo es cortar todo lo que se está realizando en la base de datos, pero no penséis que es un cierre correcto, es más que si fuese un apagón, y se queda todo mal, y si nos fijamos la base de datos ni se ha cerrado ni se ha desmontado solamente se ha cerrado la instancia.

Si ahora arrancamos la base de datos con «startup», aunque no lo estemos viendo, se está recuperando la base datos con todo lo que implica, «rockball» sin terminar, deshacer transacciones no finalizadas con el «commit», recuperaciones, etc; y esto en una base de datos real, puede tardar horas.