I agree with both KasparsB and Andre, although I would partially disagree with this statement:
"To see if you will be able to further extend fnames tablespace you have to look in the global options file /etc/opt/omni/server/options/global and find option DbFnamesDatLimit . What is the value of it for you?"
My check of the 'global' file shows, on DP 7 at least, that the default value for this is 48GB, and, in the Product Announcements Guide
Number of filenames
48 GB or approximately 1050 million (UNIX systems) or 675 million (Windows systems)
My feeling is that you may be bumping up against the Maximum number of 'fnames.dat' files that you may be allowed to have, although I can't find any documented limitation. You currently have 16, including 'fnames.dat', and are trying to be able to use the 17th
As recommended, I would check the Sessions part of the IDB context, look for any old sesions, that is, sessins that are not being protected, and export the media associated with those sessions
As Andre said, you probably need to consider purging the IDB, starting with the filenames. You can get a very rough idea how long this will take by running
omnirpt -report db_purge_preview
which is important because no backups can be runnign while you are doing the purge. To purge filenames, run
omnidbutil -purge -filenames -force
It may be easier to purge filenames by hostname instead of all at once, for example to purge filesname associated with 2 systems 'host_1' and 'host_2'
omnidbutil -purge -filenames host_1 host_2 -force
You may stop the purge at any time by running
omnidbutil -purge_stop
In addition to stopping the purge, a checkpoint is written, so that, when you run the command again, it will pick up from this point
Once the purge is done, I recommend that a 'writedb/readdb' be done of the IDB to remove iDB fragmentation, and, clean up possible sources of IDB corruption. I can only imagine how long your Consistency Check must be taking when you back up the IDB