Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
Database Servers
DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybase
Desktop Databases
FileMakerFoxProMS AccessParadox
General
General DB TopicsDatabase Theory
Related Topics
Java Development.NET DevelopmentVB DevelopmentMore Topics ...

Database Forum / Ingres Topics / January 2007

Tip: Looking for answers? Try searching our database.

[Info-Ingres] Database returns to the state of the last CP after a    crash

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Bernard Casgrain - 24 Jan 2007 21:51 GMT
Hi, Gurus.

(Our configuration: Ingres 2006 Version II 9.0.4 (int.w32/10500) on Windows Server 2003 R2 SP1)

After a crash, it seems that a lot of transactions were lost and that our main database comes back to its state at the moment of the last CP.

On restart, we find in the iircp.log, that 2 Databases need recovery. These 2 databases are "transfertvax" and "imadb". Why our main database is not listed?

There are, for sure, many transactions running on it at the crash time. We think that the message "54 Transactions must be Redone" concerns this database. No message indicates that these transactions have been redone. Why?

Someone can explain that?

Here is an abstract of the iircp.log:

!Wed Jan 17 08:36:21 2007 RCP: Marking Log File status VALID.
!Wed Jan 17 08:36:21 2007 RCP-P0: Offline Recovery: Build Recovery Context.
! Log File Window:   BOF <1149292415,442587,712> EOF <1149292415,443197,436>.
! Consistency Point: CP  <1149292415,443109,376>.
!Wed Jan 17 08:36:21 2007 RCP-P0: Reading Information from Consistency Point.
!Wed Jan 17 08:36:21 2007 RCP-P1: Start Analysis Pass.
! Analysis Window:  CP <1149292415,443109,376> to EOF <1149292415,443197,436>.
! <1149292415,443111,120> End CP  Record: New BOF: <1149292415,442587,712>
!Wed Jan 17 08:36:21 2007 RCP-P1: Analysis Pass Complete.
!Wed Jan 17 08:36:21 2007 RCP-P1: Initialize System for Recovery.
!Wed Jan 17 08:36:21 2007 RCP-P1: Check Recovery Context.
!Wed Jan 17 08:36:22 2007 RCP-P1: Recovery context complete:
! 2 Databases need recovery.
! 54 Transactions must be Redone.
! 0 Transactions must be Undone.
! 0 Transactions in Willing Commit state.
! Database transfertvax, ID 3ED75403: REDO from LGA <1149292415,443109,376>
!     0 completed transactions require REDO.
!     0 open transactions require REDO then UNDO.
! Database imadb, ID 4480CF7E: REDO from LGA <1149292415,443109,376>
!     0 completed transactions require REDO.
!     0 open transactions require REDO then UNDO.
! Non-Redo Operations: No REDO recovery on these tables prior to LSN.
!     DB 3ABB5CDA, Table (83454, 0)  at LSN (1149292376,295757096)
!     DB 3ABB5CDA, Table (83453, 0)  at LSN (1149292376,295757076)
!     DB 3ABB5CDA, Table (83452, 0)  at LSN (1149292376,295757013)
!     DB 3ABB5CDA, Table (83421, 0)  at LSN (1149292376,295756974)
!Wed Jan 17 08:36:22 2007 RCP-P1: Prepare Databases for Recovery.
!Wed Jan 17 08:36:22 2007 RCP Mark open  transfertvax ID: 00020001 ROOT: D:\IngresII\ingres\data\default\transfertvax
!Wed Jan 17 08:36:22 2007 RCP Mark open  imadb ID: 00040001 ROOT: d:\IngresII\ingres\data\default\imadb
!Wed Jan 17 08:36:22 2007 RCP-P2: Start Redo Pass.
! Redo Window:  CP <1149292415,443109,376> to EOF <1149292415,443197,436>.
!Wed Jan 17 08:36:22 2007 RCP-P2: Redo Pass Complete.
!Wed Jan 17 08:36:22 2007 RCP-P3: Start Undo Phase.
!Wed Jan 17 08:36:22 2007 RCP-P3: Undo Complete.
!Wed Jan 17 08:36:22 2007 UPDATE_BOF: BOF after Recovery: <1149292415,442587,712>
!Wed Jan 17 08:36:22 2007 RCP-P3: Begin Recovery Cleanup Phase.
! Database transfertvax successfully recovered
! Database imadb successfully recovered
!Wed Jan 17 08:36:22 2007 RCP Mark close transfertvax ID: 00020001 ROOT: D:\IngresII\ingres\data\default\transfertvax
!Wed Jan 17 08:36:22 2007 RCP Mark close imadb ID: 00040001 ROOT: d:\IngresII\ingres\data\default\imadb
!Wed Jan 17 08:36:22 2007 Recovery Operations Completed.
!Wed Jan 17 08:36:22 2007 RCP: BOF after recovery: <1149292415,442587,712>
!Alter the log-full-limit in percentage to 90
!Alter the consistency point interval block count to 10240
!Alter the force-abort-limit in percentage to 72
!Alter the maximum consistency point interval for invoking archiver to 1
!
!Wed Jan 17 08:36:22 2007 RCP Dual logging is ENABLED.
!Wed Jan 17 08:36:22 2007 RCP LOG IS ONLINE.

___________________________
Bernard Casgrain
Computer Analyst
Projet BALSAC
(418) 545-5011 (6525)
___________________________
Chip Nickolett - 26 Jan 2007 19:51 GMT
Hello Bernard,

The iircp.log output actually looks very normal.

Are you certain that transactions are lost?  That would be a major bug
if it were true, but it is difficult to believe that is the case.  Was
the "missing" database in use?   (search for the database name from the
bottom of the iircp.log file, looking for a "Mark open" without a
corresponding "Mark close")  Is the database marked inconsistent when
you attempt to connect to it later?

You mention that many transactions are running at the time of the
crash, but depending on the type of transaction design (e.g., stateless
web transaction versus normal application that is continuously
connected; when commits occur, etc.) it is possible to have
applications building transactions but not actually having open
transactions (something that is done for high performance
applications).

If you are using journaling (which everyone should do) you can check
the iiacp.log file to see about archiving activity for that database.

Those are just a few initial thoughts.  Feel free to contact me
directly if you have further questions.

Chip Nickolett (ChipN@Comp-Soln.com)
Comprehensive Solutions   www.Comp-Soln.com

> Hi, Gurus.
>
[quoted text clipped - 17 lines]
> (418) 545-5011 (6525)
> ___________________________
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.