DBCC CHECKDB returning space issue error
The message is telling you why it failed, here is the root cause of the failure:


  Write to sparse file 't:\test_audit23.ndf_MSSQL_DBCC6' failed due to lack of disk space.


Looks like the T volume runs out of space.


  I am not sure why it would need to write to this disk.


A hidden snapshot is taken and crash recovery run on the databases to bring it to a consistent state so that checkdb can run against the hidden snapshot copy of the database. This is how it works when checkdb is run online. There is the tablock option which is called 'offline' as it takes locks where the online way doesn't.



You are mostly correct. It doesn't force all writes to a single data file, however it is recalculating the proportional fill values which leads to hotspotting in a few number of files. This is known (though it seems no one cares) and that's why we had trace flags to grow the entire filegroup all together (TF 1118). This was changed and is now a database option in 2016.

Manually growing the data files each week seems excessive. If you know it's just going to grow by another TB each week, why grow it so low? If Performance Volume Maintenance Tasks is given to the service account or service sid you should be able to grow the data files fairly large with little impact.


  My question is can I try turning auto-grow off on any data files on the T drive, and try again?will it cause any issue or is there any other way.


Autogrow settings aren't your issue, sparse writes and running out of space on the volume, is.

Update:


  so what will be best way to deal these type of issues.shall I add more space?


Maybe. Depends.

If the datafiles are already on monolithic volumes, then I'd work on migrating them off the same volume. You can use mount points, storage spaces, etc., but having available space is what you need. Again, this has nothing to do with your autogrow settings and everything to do with the amount of free space available and the amount of space required to make the snapshots consistent.

What else could you do?

Well, you don't have to run CheckDB() all at once. You can break it up into smaller bite sized chunks of checks, things like using checkalloc, checkcatalog, checktable, etc. See the link here, I don't need to remake the wheel as Paul already has great articles.


  and in this case more ndf files are there then why it is writing in 23rd ndf files ,it should write to 28.ndf in X drive


The root cause of the issue is that you're unfamiliar with how CheckDB works, and that's okish. Since you know there is now a level of understanding needed, check the link I gave and read Paul's posts.

The snapshot files will be made for each data file, it's a snapshot and not actually writing to the database itself. When you read Paul's series I believe you will understand what and why - along with this answer.