Error al adjuntar una BB.DD

Qué error te muestra? No te conectes a esa base de datos, sino a Master.


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Pedro Guijosa" escribió en el mensaje
news:#
Hola Carlos.
Muchas gracias por responder..
Te comento:
Cuando llego al paso 3, efectivamente me inicia como ´suspect´ pero..
Cuando abro el analizador de consultas para ejecutar el script me da un
error de inicio de sesión
He probado con el SA, con el de windows y nada de nada...
Alguna idea???
Saludos y nuevamente gracias.
"Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> escribió en el mensaje
news:%
Buscando por los artículos que tenía por ahí guardados, he encontrado lo
siguiente. Trata de seguir estos pasos:

1.- Crea la base de datos con el nombre correcto (nombre de BD y de los
MDF y LDF)

2.- Para el servicio MSSQLSERVER, sustituye los archivos mdf con los
originales

3.- Inicia el servicio, y la base de datos estará en modo 'Suspect'

4.- Abre el analizador de consultas para ejecutar el siguiente script:
use master
go
sp_configure 'allow updates', 1
reconfigure with override
go

5.- Desde el analizador ejecuta
update sysdatabases set status= 32768 where name = '<db_name>'

6.- Reinicia el servicio MSSQLSERVER, ahora la base de datos estará en
modo Emergency

7.- Reconstruye el Log. Desde el analizador ejecuta
DBCC REBUILD_LOG('<db_name>', '<full name to new log file>').

Obtendrás un mensaje parecido a
Warning: The log for database '<db_name>' has been rebuilt.

8.- Desde el analizador ejecuta
Use master
go
sp_configure 'allow updates', 0
Go

9.- Desmarca la opción 'Restrict access' de las propiedades de la base
de datos desde la consola de administración

Hay que tener en cuenta que DBCC REBUILD_LOG tratará de crear un log
para tí, pero no le importa si se queda inconsistente la base de datos. Si
no te importa tener datos inconsistentes, o verificar los datos existentes,
esta situación puede ser aceptable. Aunque también es cierto que en la
mayoría de los casos se prefiere una base de datos en un estado consistente
pero en un estado anterior que una base de datos inconsistente


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Pedro Guijosa" escribió en el mensaje
news:

Buenos dias,

Después de una caida del sistema operativo completo en un servidor W2003
Server SP2 con SQL 2000 SP3a, y de la pertinente reinstalación , nos
encontramos el siguiente problema grave.

Cuando intentamos adjuntar la base de datos del cliente ( archivos .mdf y
.ldf ) nos muestra el siguiente error:

Microsoft SQL-DMO ( ODBC SQL State: HY000)

Error 9003 : El LSN (20034:1866:1) pasado a la exploracion del registro en
la base de datos ´ Termo´ no es válido.

Tenemos un problema grave, ya que el cliente por "descuido" no hacia

copias

de seguridad desde hace tiempo!!!! .. Solo tenemos los archivos mdf y ldf

que

tenian en la particion de datos del server y los archivos de ofimática,

que

la mayoria tambien han quedado " tocados"

Os agradezco cualquier solución que no sea "tirar de copia de seguridad"

!!!

Saludos

Ups!!! perdon, tienes toda la razon!!!! ;-)

Ahora me encuentro en el proceso de desmarcar la opcion de 'Restrict access'
y lleva bastante ratosupongo que será normal..

Pd: en otro documento similar, me indicaba que ejecutara el comando
sqlservr -m 2 entre el paso 4 y 5

Te voy comentando como va..( no veas la presión que tenemos que aguantar
algunos)

Saludos y nuevamente gracias por tu colaboracion.


"Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> escribió en el mensaje
news:%23%234wo%

Qué error te muestra? No te conectes a esa base de datos, sino a

Master.

Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Pedro Guijosa" escribió en el mensaje
news:#
Hola Carlos.
Muchas gracias por responder..
Te comento:
Cuando llego al paso 3, efectivamente me inicia como ´suspect´ pero..
Cuando abro el analizador de consultas para ejecutar el script me da un
error de inicio de sesión
He probado con el SA, con el de windows y nada de nada...
Alguna idea???
Saludos y nuevamente gracias.
"Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> escribió en el mensaje
news:%
Buscando por los artículos que tenía por ahí guardados, he encontrado

lo

siguiente. Trata de seguir estos pasos:

1.- Crea la base de datos con el nombre correcto (nombre de BD y de

los

MDF y LDF)

2.- Para el servicio MSSQLSERVER, sustituye los archivos mdf con los
originales

3.- Inicia el servicio, y la base de datos estará en modo 'Suspect'

4.- Abre el analizador de consultas para ejecutar el siguiente script:
use master
go
sp_configure 'allow updates', 1
reconfigure with override
go

5.- Desde el analizador ejecuta
update sysdatabases set status= 32768 where name = '<db_name>'

6.- Reinicia el servicio MSSQLSERVER, ahora la base de datos estará en
modo Emergency

7.- Reconstruye el Log. Desde el analizador ejecuta
DBCC REBUILD_LOG('<db_name>', '<full name to new log file>').

Obtendrás un mensaje parecido a
Warning: The log for database '<db_name>' has been rebuilt.

8.- Desde el analizador ejecuta
Use master
go
sp_configure 'allow updates', 0
Go

9.- Desmarca la opción 'Restrict access' de las propiedades de la base
de datos desde la consola de administración

Hay que tener en cuenta que DBCC REBUILD_LOG tratará de crear un log
para tí, pero no le importa si se queda inconsistente la base de datos. Si
no te importa tener datos inconsistentes, o verificar los datos

existentes,

esta situación puede ser aceptable. Aunque también es cierto que en la
mayoría de los casos se prefiere una base de datos en un estado

consistente

pero en un estado anterior que una base de datos inconsistente


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Pedro Guijosa" escribió en el mensaje
news:
> Buenos dias,
>
> Después de una caida del sistema operativo completo en un servidor W2003
> Server SP2 con SQL 2000 SP3a, y de la pertinente reinstalación , nos
> encontramos el siguiente problema grave.
>
> Cuando intentamos adjuntar la base de datos del cliente ( archivos .mdf

y

> .ldf ) nos muestra el siguiente error:
>
> Microsoft SQL-DMO ( ODBC SQL State: HY000)
>
> Error 9003 : El LSN (20034:1866:1) pasado a la exploracion del registro

en

> la base de datos ´ Termo´ no es válido.
>
> Tenemos un problema grave, ya que el cliente por "descuido" no hacia
copias
> de seguridad desde hace tiempo!!!! .. Solo tenemos los archivos mdf y

ldf

que
> tenian en la particion de datos del server y los archivos de ofimática,
que
> la mayoria tambien han quedado " tocados"
>
> Os agradezco cualquier solución que no sea "tirar de copia de seguridad"
!!!
>
> Saludos
>
>
>
>