There is 77GB free out of 148GB at the minute and it has restored 9GB so far,
final size ~33GB so on the surface looks adequate unless very large temp files
are created when the indexes are reactivated?
I'm now trying to restore it with "ignore validity constraints" off in
flamerobin.
It's a production database but this restore is for a side-project (email
logging). I clearly need to get to the root of the problem.
The offending index is added to using a generated integer within a
gbak:activating and creating deferred index K_MERCURY_EMAIL
gbak:cannot commit index K_MERCURY_EMAIL
gbak: ERROR:operating system directive CreateFile failed
gbak: ERROR:The system cannot find the path specified.
Database restore canceled 21:17:19 due to IBPP exception:
***
But you likely changed from 32bit Win2003, so you are experiencing the
expected problem of Window Cache/Pages management with 64bit OS.
Please google this subject, there is plenty written about it.
Shouldn't this important information be part of the FAQ or in other prominent
place?
I'd recommend using 'dd-mmm-' as in '01-Jan-2014'.
It is unambiguous, more easily readable than the alternatives, and doesn't
require the brain to convert the month number to an actual month name. Tom
Thanks for the replies.
- Same results with ISQL + CTE
- FB version 2.1.3.18185 SS on Windows 2008 Server R2 (on a VM)
- will validate the db when possible.
Database info
ODS Version 11.1
Page Size 8192
Pages 163560
Size on Disk 1.25GB
SQL Dialect 3
Default Character Set NONE
e.g.
I was expecting to see one row for
melvin comms directors 30.04.13 and also for DCFTG210513.
TIA
Tom
QUERY
-
select '['|| TRIM(SUBSTRING(COMMENTS FROM 1 FOR 100)) || ']', count(*)
from target
group by 1
having count(*)5
order by 1
RESULTS
---
[null] 2289
