Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

read_only filegroup Expand / Collapse
Author
Message
Posted Thursday, February 9, 2012 8:25 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Yesterday @ 10:06 AM
Points: 100, Visits: 573
Hi,
I have a filegroup which is set to read-only. I need to set it back to read-write. When I try to modify it, it errors out with: 'An error occurred while processing 'AltFile' metadata for database...'
After looking at sys.master_files, the filegroup has all redo_xxxx_lsn values set. The redo_start_lsn and redo_target_lsn is the same values, so theoretically, the filegroup is ok, but it still prevents me from changing the read-only mode.
Any thoughts?
Thanks.
Post #1249750
Posted Thursday, February 9, 2012 8:32 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 3:43 PM
Points: 40,177, Visits: 36,579
Anything in the error log?


Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1249759
Posted Thursday, February 9, 2012 9:09 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Yesterday @ 10:06 AM
Points: 100, Visits: 573
Nothing suspicious, but obviously it happened during some past restore. I'm trying to find some older full backup and restore the FG and see if it's ok. But still, I'd like to figure out how this happened in first place.
Post #1249780
Posted Tuesday, March 6, 2012 3:09 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Yesterday @ 4:16 AM
Points: 121, Visits: 1,248
If you have already check that filegroup is ok then there is one another possibility-
Did you check that read-only filegroup is on a compressed ntfs volume? If the volume is compressed, first you have to decompress it & after that try it again.


SQL Database Recovery Expert
Post #1262024
Posted Tuesday, March 6, 2012 6:10 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Yesterday @ 10:06 AM
Points: 100, Visits: 573
No it's not compressed. It was completely different issue. The particular FG was pointing to a non-existing file. I talked to MS and the solution they came up with was to keep adding filegroups until the non-existing file record is overwritten. It worked.
Post #1262122
Posted Wednesday, May 30, 2012 8:58 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, June 23, 2014 4:16 PM
Points: 244, Visits: 249
Hi,

I just wanted to add something to this topic as I had the same error but the fix was slightly different, although adding files to the database was the key.

The error I received was:

An error occurred while processing 'AltFile' metadata for database id 8, file id 3, and transaction='alterdb'.

Upon reviewing the sys.sysfiles for the database (id=8) it was obvious that there was no fileid=3. There was a 1, 2, 4, 5, 6 but no 3.

There were two filegroups: PRIMARY had 1 file, with a fileid=1, and the SECONDARY had three files, fileid=4,5 & 6.

I suspect there was a second file in the PRIMARY filegroup at some stage with a fileid=3 which was removed, thus leaving a hole in the sequence.

The solution was to add a file to the PRIMARY filegroup, confirm that the file was created with a fileid=3 and re-run the ALTER DATABASE command, this time it worked fine.

Just wanted to share that with the community.

Thanks
Paul
Post #1308416
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse