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

The operating system returned error 665(The requested operation could not be completed due to a file system limitation) to SQL Server during a write at offset... Expand / Collapse
Author
Message
Posted Wednesday, February 15, 2012 8:27 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, February 26, 2015 9:17 AM
Points: 4, Visits: 439
I am kind of in a bit of a Jam.

Seeing a lot of Storage I/O issues.

The OS is MS Windows 2008 R2 (RTM) and MS SQL Server 2008/R2 (RTM).

Based on an analysis I did over the weekend (which is attached), we applied SP1 to both OS and SQL Server this morning.

But, I am still not able to create Database Snapshots. And, when I am able to create them, I

get the following errors:

Date 2/15/2012 11:37:53 PM
Log SQL Server (Current - 2/15/2012 11:39:00 PM)

Source spid22s

Message
The operating system returned error 665(The requested operation could not be completed due to a file system limitation) to SQL Server during a write at offset 0x0000123b0f0000 in file 'Z:\DATA\JPE_Snapshot.ss'. Additional messages in the SQL Server error log and system event log may provide more detail. This is a severe system-level error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.


Post #1252840
Posted Wednesday, February 15, 2012 11:28 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, February 26, 2015 9:17 AM
Points: 4, Visits: 439
It is quite possibly that the problem that I am having are related to "File System Filter Drivers":

A tale of CHECKDB failures cause by 3rd party file-system drivers
http://sqlblog.com/blogs/jonathan_kehayias/archive/2009/12/10/a-tale-of-checkdb-failures-cause-by-3rd-party-file-system-drivers.aspx


Two Minute Drill: File System Filter Drivers
http://blogs.technet.com/b/askperf/archive/2008/08/08/two-minute-drill-file-system-filter-drivers.aspx



Search Engine Q&A #14: Beware 3rd party file-system drivers with DBCC CHECKDB
http://www.sqlskills.com/BLOGS/PAUL/post/Search-Engine-QA-14-Beware-3rd-party-file-system-drivers-with-DBCC-CHECKDB.aspx


When I go in tomorrow, I will use the file extension mdf for my database snapshot files. Currently, I chose to
use .ss, but that is probably causing trouble with my Anti-Virus Software that is more likely than not
only filtering against mdf and ldf - It is probable that ndfs are skipped, as well.

Post #1252886
Posted Wednesday, January 9, 2013 9:45 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, May 15, 2013 4:18 PM
Points: 1, Visits: 12
Not sure whether you solved this or not, but you might want to review this Microsoft KB about a known Hotfix for the OS for the "'Operating system error 665' BackupIoRequest::ReportIoError: "

Or for anybody else who runs into this issue and might need it.

OS Errors 1450 and 665 are reported for database data files
http://support.microsoft.com/kb/2002606
Post #1404867
Posted Sunday, June 14, 2015 1:52 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Wednesday, July 1, 2015 12:58 PM
Points: 270, Visits: 936
DBCC CHECKDB uses internal database snapshots which are created at the same location of the corresponding database data file and grow as data is changed in the original data file. If transactional activity continues on this database, these snapshots created by DBCC commands may experience huge internal fragmentation. Keeping details of such high level of fragmentation requires more resources than the default size “Bytes Per FileRecord Segment” which is 1 KB.

Suggestions for Remedy <in order of effort required>.
• Suggest the users to use a combination of other DBCC CHECK jobs and avoid DBCC CHECKDB
• Avoid running DBCC CHECKDB at a time when other / major data modifications are taking place.
• Divide the database into a multiple files. The limitations are per sparse file and each database snapshot creates matching sparse files for each data file.
• Find out which tables/indexes result in the most write activity during the lifetime of the snapshot
o Separate them out into a different file group with multiple files of comparatively smaller sizes.
o Identify & revise the Index Fill Factor & PAD index values.
o Use check table or as appropriate on those.
• Format the disks with /L to increase the “Bytes Per FileRecord Segment” to 4 KB from 1 KB.

More details at
http://support2.microsoft.com/kb/967351
KB957065
https://support.microsoft.com/en-us/kb/2002606
Post #1694417
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse