Como buen DBA chapado a la antigua que soy, uso SQL*Plus. Nada de herramientas externas como SQL Developer, Toad o cualquier otra herramienta gráfica.
¿Las he usado? – Sí.
¿Me han sacado alguna vez de un apuro? – También.
Pero no son mis herramientas de trabajo habituales.
Creo que este truco que descubrí hace algún tiempo, te puede ayudar a ganar tiempo en SQL*Plus y a mirar esa pantallita negra con otros ojos. Quizá hasta te parezca un poco más atractivo. 😋
A mi me fastidiaba mucho, escribir una consulta, y a mitad de camino equivocarme.
Ya entra en juego la configuración de tu cliente SSH y la de la shell que estás usando. Unas no te dejan borrar, otras te muestran símbolos extraños al pulsar la tecla retroceso, etc.
Total, que al final, siempre me tocaba reescribir la consulta completa, o ir copiando y pegando fragmentos del código para intentar sacar la consulta adelante sin perder demasiado tiempo.
Te voy a enseñar dos soluciones a tus problemas.
Leer artículo completo
Hoy estoy trabajando con una base de datos Oracle. Está en versión 11.2.0.4 bajo un sistema Solaris 10 Sparc.
Tras unos cambios que estoy haciendo, tenía la necesidad de reiniciarla. La parada ha ido bien, pero al intentar arrancarla…
🤡 ¡SORPRESA! 🤹🏼♂️ La base de datos no arranca. Nos arroja un error ORA-27102: out of memory.
¿Qué puede estar pasando? ¿Se habrá quedado el servidor sin memoria?
Si yo no he tocado los parámetros de memoria… ¿a que se debe ahora este error?
Leer artículo completo
Ayer me tocó afrontar una tarea sencilla, de las del día a día. Algo que para cualquier DBA es de primero de primaria. Borrar unas filas de una tabla.
Aparentemente, algo muy sencillo.
- Primero, una select para ver lo que hay en la tabla
- Segundo, montamos una select para seleccionar lo que vamos a borrar y estar seguros antes de ejecutar el delete.
- Tercero, como uno es inseguro por naturaleza, hace una copia de la tabla por si acaso (create table NOMBRETABLA as select * from TABLAORIGEN).
- Cuarto, ya preparados y asegurados, ejecutamos el delete.
- Quinto, un commit, que confirme bien que hemos borrado los registros.
- Sexto y último paso, volver a hacer el primer select para verificar que hemos borrado los datos.
Fácil no? Una tarea rápida, de las que a veces se agradecen para descansar un poco la cabeza y no tener que pensar demasiado.
Hoy, me dicen si realmente he ejecutado el borrado, que parece que los registros no se han borrado, que siguen ahí.
What? Como es posible? 😱 Juro y perjuro que los he borrado.
Compruebo, y efectivamente, ahí están. NO ES POSIBLE. Los registros siguen en la tabla. 😡
Repito el mismo procedimiento, vuelvo a montar las consultas (porque algo tan simple, para qué lo iba a guardar?) ejecuto todo, vuelvo a comprobar, y los datos, efectivamente, ya no están.
Antes de confirmar de nuevo que los he vuelto a borrar, he preferido ser más conservador y esperar.
TACHÁN!! Al esperar un rato, vuelvo a comprobar, y ahí están de nuevo, los registros han vuelto a aparecer en la tabla.
Leer artículo completo
Esta semana, a raíz de estar trabajando en una migración mediante mecanismo de TTS (Transport Tablespaces) de una versión 11.1.0.7 a 19c nos hemos topado con un error que no había ocurrido anteriormente en otras migraciones del mismo tipo.
El Error
released channel: ch00
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 08/28/2024 13:05:21
ORA-19870: error al restaurar parte de la copia de seguridad /home/oracle/MIGRATE/BBDD/INCREMENTAL_LAST_bbdd_fs33h9ng_1_1
ORA-19638: el archivo /oracle/base_datos/datos01/datafile01.dbf no es lo bastante actual para aplicar esta copia de seguridad incremental
ORA-19642: el SCN de inicio de la copia de seguridad incremental es 13503408614611
Leer artículo completo
