Blog

Etiqueta: bases de datos

Reparar una base de datos corrupta en Sql Server (Parte I)

Publicado en Sistemas TI en Abril 25, 2012 10:28 am

Debido a múltiples circunstancias como cortes eléctricos inesperados, problemas de espacio en disco, fallos de hardware, que hayas borrado el archivo de log (.ldf), etc. Una bbdd puede corromperse, normalmente la mejor manera de solucionar esto es recurrir a la última copia de seguridad pero como puede ocurrir en estos casos no hay copia o la que tenemos disponible es ya algo vieja. En esos casos quizá aún podamos recuperar la información.

Una bbdd puede tener estos estados:

  • ONLINE: La base de datos está disponible para su acceso. El grupo de archivos principal está en línea, aunque la fase de deshacer de la recuperación puede no haberse completado.
  • OFFLINE: La base de datos no está disponible. Una base de datos pasa a estar sin conexión por la acción explícita del usuario y permanece sin conexión hasta que el usuario toma otra acción. Por ejemplo, la base de datos puede desconectarse para mover un archivo a un nuevo disco. La base de datos se vuelve a poner en línea una vez completado el traslado.
  • RESTORING: Uno o varios archivos del grupo de archivos principal se está restaurando, o uno o varios archivos secundarios se están restaurando sin conexión. La base de datos no está disponible.
  • RECOVERING: Se está recuperando la base de datos. El proceso de recuperación es un estado transitorio, la base de datos se pone automáticamente en línea si la recuperación tiene éxito. Si la recuperación no tiene éxito, la base de datos pasa a ser sospechosa. La base de datos no está disponible.
  • RECOVERY PENDING: SQL Server ha encontrado un error relacionado con un recurso durante la recuperación. La base de datos no está dañada pero pueden faltar archivos o bien limitaciones de recursos del sistema pueden estar impidiendo que se inicie. La base de datos no está disponible. Se necesita una acción adicional por parte del usuario para resolver el error y permitir que se complete el proceso de recuperación.
  • SUSPECT: Como mínimo un grupo de archivos principal es sospechoso y puede estar dañado. La base de datos no se puede recuperar durante el inicio de SQL Server. La base de datos no está disponible. Se requiere una acción adicional por parte del usuario para resolver el problema.
  • EMERGENCY: El usuario ha cambiado la base de datos y ha establecido el estado en EMERGENCY. La base de datos está en modo de usuario único y se puede reparar o restaurar. La base de datos está marcada como READ_ONLY, el registro está deshabilitado y el acceso está limitado a miembros de la función fija de servidor sysadmin. EMERGENCY se utiliza principalmente para solucionar problemas. Por ejemplo, una base de datos marcada como sospechosa se puede establecer en el estado EMERGENCY. Esto puede permitir al administrador del sistema acceso de sólo lectura a la base de datos. Sólo los miembros de la función fija de servidor sysadmin pueden establecer una base de datos en el estado EMERGENCY.

Cuando se corrompe la tendremos seguramente en Online, Recovery pendingSuspect.

Puedes ver el estado de la BD utilizando esta consulta (sustituye blackslotdb por la bd a consultar):

SELECT state_desc FROM sys.databases WHERE name = ‘blackslotdb’;

Si la bd está en estado ONLINE, lo más fácil es intentar un checkdb con la opción REPAIR_ALLOW_DATA_LOSS.

DBCC CHECKDB (MAGIC, REPAIR_ALLOW_DATA_LOSS)WITH NO_INFOMSGS

Más info en http://technet.microsoft.com/es-es/library/ms188422.aspx

En la segunda parte de este post comentaremos como reparar si la bd se encuentra en alguno de los otros 2 modos o no se puede adjuntar.

Copiar tablas de una bd SQL Server a otra

Publicado en Sistemas TI en Noviembre 11, 2011 4:01 pm

Tenemos una base de datos en producción y queremos disponer de una copia de esos datos para desarrollo, sólo necesitamos algunas tablas.

Cómo para todo existe la forma de hacerlo mediante script, sin embargo en esta ocasión utilizaremos el Wizard.

1) Seleccionamos la base de datos destino e importamos (Tasks > Import Data…)

image

2) Empieza el wizard.

image

3) Indicamos el nombre de servidor, en nuestro caso cómo es localhost podemos poner un punto. La autenticación mediante Windows o Sql y finalmente si los datos son correctos nos dejará seleccionar la base de datos de origen, en nuestro caso BLACKSLOT_PROD.

image

4) De la misma forma, en este paso indicamos el destino. Para nosotros BLACKSLOT_DEV. Si no tuviésemos la base de datos de destino ya creada, podemos darle a “”New…” para crearla.

image

5) En el siguiente apartado dejamos la primera opción marcada.

image

6) Ahora nos mostrará las tablas y vistas que podemos importar, en nuestro caso sólo existe una tabla (T_Servidores_Cloud) que es la que hemos creado a modo de ejemplo. Cómo en el destino no existe la tabla, automáticamente nos la creará con el mismo nombre y los mismos campos.

image

7) Si necesitamos que el nombre sea otro, también podemos editarlo. Si además queremos controlar los campos de destino podemos pinchar en el botón “Edit Mappings…” y nos mostrará todas las posibilidades.

image

8) Finalmente tenemos un resumen de lo que se va a hacer y podemos darle a “Finish”.

Couchbase y el esfuerzo por la consolidación NoSQL

Publicado en Desarrollo web Novedades en Febrero 9, 2011 12:48 am

CouchOne, la empresa creadora de CouchDB, y Membase, la empresa madre de Membase Server y Memcached, se han fusionado para crear una nueva iniciativa denominada Couchbase. Desde la fusión, cada una de ellas continuará asistiendo y apoyando sus respectivos proyectos CouchDB, Membase y Memcached, pero han querido crear este nuevo proyecto de código abierto que busca unir esfuerzos en la dirección de la normalización de las bases de datos no relacionales.

Ahora, la nueva compañía tendrá por CEO al que lo ha estado siendo en Membase, Bob Wiederhold. El cofundador y CEO de CouchOne, Damien Katz, será el CTO de la misma. Y, casualidades de la vida, antes de la fusión, Membase estaba buscando un CTO mientras que CouchOne andaba detrás de incorporar un nuevo CEO.

Esta operación se enmarca en el nuevo escenario que muchas empresas se están encontrando en Estados Unidos, donde ya se habla y se comenta acerca de un posible avance de las bases de datos NoSQL, basándose, en parte, en las decisiones a favor de aplicaciones como FourSquare (a pesar de los problemas que llegan a la hora de escalar) o Twitter.

Por el momento, hay una larga distancia de ventaja de las bases de datos relacionales SQL por encima de las NoSQL, sobretodo en el ámbito empresarial. Y si esto es así en EEUU, aquí en España, encontramos muchos consultores y técnicos de sistemas que ni siquiera saben en qué consiste o qué es NoSQL.

Es cuestión de tiempo comprobar si verdaderamente es el paso evolutivo natural de las bases de datos ¿Qué opináis?