| Subject | Re: [firebird-support] damaged database |
|---|---|
| Author | Helen Borrie |
| Post date | 2009-02-17T08:23:36Z |
At 06:33 PM 17/02/2009, you wrote:
Your deleted records remain "interesting" ( = Oldest Transaction) until there are no more transactions running that would potentially touch the records that were deleted. Their "stubs" will continue to occupy space on the pages for that table until all of those other transactions are HARD committed. If IBManager never performs HARD commits, then all of its transactions just keep being "interesting". :-)
The OIT is a completed transaction. The next one after that was the one that is displayed as your Oldest Active transaction. It is still running, i.e., it has not been committed, nor rolled back.
You are running Classic, so GC is not a busy thread running in the background as it can be with Superserver. Next time someone does a SELECT on the table from which you deleted all those records, you should see some changes in the transaction statistics.
Just try it: SELECT * FROM ATABLE, followed by a HARD commit, will do it. (If IBManager doesn't offer a hard commit then use isql and provide your own COMMIT statement.)
Detaching your transaction-unfriendly client application and running a sweep should also cause some movement. Either way
From some things you have said, I wonder whether you are trying to read statistics while a backup or restore is running. I suggest you use the -v and -f switches on both backups and restores, so you have a record of what happens.
./heLen
>Hello.To me, this looks as though these deletions were done with "Autocommit" transactions using Commit Retaining. I don't know anything about IBManager but it's possible you can configure it to NOT use such settings.
>
>Sadly has no one an idea for my latest problems.
>
>Perhaps, you can help me with this question.
>
>ClassicServer 2.01. After I have deleted much data once more, the
>gstat-monitor shows me the follow:
>
>Oldest Tr. 16339
>Oldest active 16340
>Oldest snapshot 4656
>Next transaction 198659
>Bumped trans. 1
>Sequenceno. 0
>Next attachmentid 428
>Implementation id 16
>Shadow count 0
>Page puffers 0
>Next header page 0
>Database dialect 3
>Creation date feb 12, 2009 20:29:52
>Attributes force write
>Sweep interval 20000
>
>The deletion I have made with IB Manager 3. I have committed all steps and
>close the program after action.
Your deleted records remain "interesting" ( = Oldest Transaction) until there are no more transactions running that would potentially touch the records that were deleted. Their "stubs" will continue to occupy space on the pages for that table until all of those other transactions are HARD committed. If IBManager never performs HARD commits, then all of its transactions just keep being "interesting". :-)
The OIT is a completed transaction. The next one after that was the one that is displayed as your Oldest Active transaction. It is still running, i.e., it has not been committed, nor rolled back.
>What does the snapshot counter mean?It's not a "counter". It shows the id of the transaction that was the Oldest Active the last time a round of garbage collection finished in your db. Next time a GC happens, it should change to the current value of the OAT.
You are running Classic, so GC is not a busy thread running in the background as it can be with Superserver. Next time someone does a SELECT on the table from which you deleted all those records, you should see some changes in the transaction statistics.
Just try it: SELECT * FROM ATABLE, followed by a HARD commit, will do it. (If IBManager doesn't offer a hard commit then use isql and provide your own COMMIT statement.)
Detaching your transaction-unfriendly client application and running a sweep should also cause some movement. Either way
>Can I manually update the counters? (oldest transaction)No. The numbers are statistics that are reported to in-memory and transaction accounting pages as a result of garbage collection and sweeps so, of course, they are read-only.
>The deleted data are gone, but not the counter - despite I have committedAs I said, I don't know IBManager but you might consider looking for a tool that gives you more control over transactions, if you are depending on a GUI tool to perform database operations.
>all erasing steps.
>I have my doubts, if I close the network connection to backup the database,It doesn't seem like a corrupted database to me. Perhaps one that is not receiving the kindest treatment...
>that the database will be corrupted again.
>Currently the database works fine and the automatically backup does finish.Can't tell what "the automatically backup" might be....
>My second database works fine since nearly 5 Years. I never had to create aAre you serious???? You have been walking a tightrope for 5 years? Backups are essential and not just because they protect you from horrible things like corruptions and self-destructing hard disks. gbak also performs housekeeping. It should be normal practice to back up say, monthly, and restore once every six months. You should also test-restore your backups to some private space to ensure that you do NOT have corruptions in some infrequently-accessed data.
>backup,
>but since four weeks, (without any changes on my application) theDo a backup. Make sure it is finished!! then restore it to some different database name, and perform a gstat -h on it.
>oldest transaction counter does not go forward, like the next transaction
>counter. It doesn't count (oldest transaction) for many days ago. But the
>database still work. This database running on firebird 1.5.0
>
>Please, have anyone an idea?
From some things you have said, I wonder whether you are trying to read statistics while a backup or restore is running. I suggest you use the -v and -f switches on both backups and restores, so you have a record of what happens.
./heLen