|
[
Permalink
| « Hide
]
Karol Bieniaszewski added a comment - 13/Jun/19 07:37 AM
View from "Resource monitor"
I can see only one difference between security database and other DBs - it has by default non-zero linger. Is is set on your sec/db?
I do not change linger for restored db, but i suppose it is default in minutes not days?
It's not in minutes, it's seconds :)
I asked cause I want to have some idea from where to start. IMO some bug is present here but you see yourself - when we talk about something that happened for you 3 times it's rather hard to fix something using just this info. We need a way to reproduce soemthing. BTW, 3 failures per how many successful restores? Yes, i know. Without reproducible test case it is hard to start.
We have 3 failtures in this year. The job start at every night and we have now day 164 of the year. Then most of the time it is working without problem. I have tried
1. database sweep - manually 2. delete from MON$ATTACHMENTS WHERE MON$USER<>'SYSDBA' --- no success or any change -- 3. gfix -nolinger above change something as garbage collector and cache writer are finished and when i have connect to database it show current dates But still Firebird do not release handle to the file :( I have found the way how to fix this. I should do this at start, but as you can see i must run this command 2 times to work
First try show an error as db is bining used. Second try do not show this message and show error about permission (i do not provide user and password) Third try work ok, Firebird release handle and i have deleted database file :) --------------------------------------------------------------------------------------------------------------------------------------- C:\Firebird>gfix -shutdown -force 1 D:\restore\SECURITY3.FDB.RESTORED I/O error during "CreateFile (open)" operation for file "D:\RESTORE\SECURITY3.FDB.RESTORED" -Error while trying to open file -The process cannot access the file because it is being used by another process. --------------------------------------------------------------------------------------------------------------------------------------- C:\Firebird>gfix -shutdown -force 1 D:\restore\SECURITY3.FDB.RESTORED no permission for shutdown access to database D:\RESTORE\SECURITY3.FDB.RESTORED --------------------------------------------------------------------------------------------------------------------------------------- C:\Firebird>gfix -shutdown -force 1 -user sysdba -password XXXXXXX D:\restore\SECURITY3.FDB.RESTORED C:\Firebird> I have thinked about this command without credentials
"C:\Firebird>gfix -shutdown -force 1 D:\restore\SECURITY3.FDB.RESTORED " Why it release some handle? Is this some another bug? It should do nothing in the database as the user was not autorized. That's embedded access. What is strange is that it can access file already open with SS instance. Are you using SS?
Yes, SuperServer.
But if you look at above commands, first try encoutered "The process cannot access the file because it is being used by another process" But this try somehow have released file handle and another try have not any problems i suppose, because i have not tried to delete file sfter first attempt only after 3 with succesful shutdown. Maybe file was released after first attempt and this was my concern why unautorized try make any change. But this is only an assuption. Now this have occurred once again and i can confirm that first unauthorized (without credentials) shutdown close handle to the database
"gfix -shutdown -force 1 D:\restore\SECURITY3.FDB.RESTORED" I do not know as i have added shutdown command to the process. I can remove it and we will see.
But now, if you need, you can close the issue, i will report if it happen again with this fix included. Karol,
thanks, if you could test it - I'll wait for feedback |