PHWinfo - Afficher un message

01/04/2008, 16h03

On Tue, 01 Apr 2008 03:56:37 GMT, changliw@online.microsoft.com (Charles
Wang[MSFT]) wrote:

> Hi Luc,
> Could you please let me know what the newsgroup in which you put the same
> post was? Is it a managed newsgroup? If your original post was not posted
> at a Managed newsgroup, it could not be monitored by Microsoft Newsgroup
> Support Team.

My fault: it's not a managed newsgroup (microsoft.public.sqlserver.misc).

It must still have existed in the newsgroup list of my newsreader (Forté
Agent) from years ago.

Agent must have fallen back to another server when the group was deleted
from msnews.microsoft.com (I'm using two other servers in addition to
msnews to get access to non-MS newsgroups, but I also use them for
microsoft.public newsgroups because they keep old messages much longer,
which sometimes comes in handy if a question has been asked and answered
long ago).

> After you restore the latest version of your database, I recommend that you
> first trying detaching your database and then attaching the database with
> single file, such as:
> exec sp_detach_db 'database name'
> Go
> exec sp_attach_single_file_db @dbname='database name',@physname=N'your mdf
> file path'
> Go
> After that, run DBCC CHECKDB with REPAIR_FAST to see if it can succeed.

I get the same error.

To be sure I deleted the database, restored it again from the same backup,
detached it, and then ran these queries:

exec sp_attach_single_file_db @dbname='PLRest',
physname=N'F:\Temp2\PLRest.mdf'
alter database PLRest set SINGLE_USER
dbcc checkdb('PLRest',REPAIR_FAST)

The result is a single message:

Msg 5244, Level 16, State 1, Line 3
Repair statement not processed. One or more files in the database are
read-only and must be made writeable in order to run repair.

The "set SINGLE_USER" line is there only because DBCC CHECKDB insists on
it.

Being only the developer who wrote the application, I haven't seen the
machine where the database comes from, but the engineer who was sent there
to repair it on site and who brought back the copy of the backup file,
reports the same error from dbcc checkdb there.

Changing REPAIR_FAST to REPAIR_REBUILD doesn't either: same error.

Only without a REPAIR option, dbcc checkdb succeeds and reports about a
dozen errors.

01/04/2008, 16h03	#3
Luc Messages: n/a Hébergeur:	Re: DBCC CHECKDB REPAIR error 5244 On Tue, 01 Apr 2008 03:56:37 GMT, changliw@online.microsoft.com (Charles Wang[MSFT]) wrote: > Hi Luc, > Could you please let me know what the newsgroup in which you put the same > post was? Is it a managed newsgroup? If your original post was not posted > at a Managed newsgroup, it could not be monitored by Microsoft Newsgroup > Support Team. My fault: it's not a managed newsgroup (microsoft.public.sqlserver.misc). It must still have existed in the newsgroup list of my newsreader (Forté Agent) from years ago. Agent must have fallen back to another server when the group was deleted from msnews.microsoft.com (I'm using two other servers in addition to msnews to get access to non-MS newsgroups, but I also use them for microsoft.public newsgroups because they keep old messages much longer, which sometimes comes in handy if a question has been asked and answered long ago). > After you restore the latest version of your database, I recommend that you > first trying detaching your database and then attaching the database with > single file, such as: > exec sp_detach_db 'database name' > Go > exec sp_attach_single_file_db @dbname='database name',@physname=N'your mdf > file path' > Go > After that, run DBCC CHECKDB with REPAIR_FAST to see if it can succeed. I get the same error. To be sure I deleted the database, restored it again from the same backup, detached it, and then ran these queries: exec sp_attach_single_file_db @dbname='PLRest', physname=N'F:\Temp2\PLRest.mdf' alter database PLRest set SINGLE_USER dbcc checkdb('PLRest',REPAIR_FAST) The result is a single message: Msg 5244, Level 16, State 1, Line 3 Repair statement not processed. One or more files in the database are read-only and must be made writeable in order to run repair. The "set SINGLE_USER" line is there only because DBCC CHECKDB insists on it. Being only the developer who wrote the application, I haven't seen the machine where the database comes from, but the engineer who was sent there to repair it on site and who brought back the copy of the backup file, reports the same error from dbcc checkdb there. Changing REPAIR_FAST to REPAIR_REBUILD doesn't either: same error. Only without a REPAIR option, dbcc checkdb succeeds and reports about a dozen errors.