IQ fractured/torn blocks

[former_member420425]

Hi all,

I asked the question to SAP support, and they pointed me to the IQ SCN.

My question is:

How does IQ prevents fractured/torn blocks on disk in the case a server crashes in the middle of a block write ?

Is the IQ checkpoint log used for this purpose (double write) and what exactly gets written into the IQ checkpoint log ?

Thanks in advance for your answers,

Marco

[former_member333181]

Hi Marco,

    Can you please clarify on your question? IQ have two distinct storage , on is IQ data storage which stores IQ main data and IQ catalog database, which stores IQ meta data. IQ by nature of design is non-transactional server. The .log file contains information for catalog database to be consistent. IQ main data store is accessed by many threads which executes synchronous write to the disk. For this very reason, we do recommend to use raw devices for IQ main store rather than File-system device.

   Is your question relates some how to comparison between IQ and ASE?

Regards

Shashi

[former_member420425]

Hi Shashi,

Thank you for your reply.

I am talking about the IQ store. I was wondering how IQ prevents fractured blocks.

Let say IQ is in the middle of a synchronous write to the IQ store device (not the catalog store) and the machine crashes. The block will be half written to disk. Does IQ has a mechanism to prevent that to happen ?

The purpose of the IQ checkpoint log is also not clear to me. What does it actually contain ? real data blocks ? new/old version ?

Thanks

[former_member333181]

Hi Marco,

   If while writing to IQ data store, there is crash, Most of the time IQ will recover, as the catalog database bitmap is updated ONLY after successful write to data store. catalog store contains, freelist bitmap and it is used to check the consistency of IQ store. In rare situations, if this happens there is always a possibility of corruption. If IQ store corruption happens, ONLY resolution is to restore from last clean backup and reapply any missed transaction/data.

   Typically IQ data is written in blocksize. When you configure IQ store you define the IQ blocksize and each individual read/write is of IQ blocksize.

    IQ has checkpoint as per the configured option ( "-gc" ) as well as there are certain commands when executed there will be automatic checkpoint and commit, like "alter table" or "create table" commands.  During checkpoint all records until last committed transaction is flushed to the disk, this is for catalog database and internal in memory as well as on disk freelist is updated.

HTH

Regards

Shashi

[markmumy]

To broaden this a bit.  The state of the block(s) on disk are really immaterial for this discussion.  What?  How much sense does that really make?

Well, they don't matter simply because the transaction hasn't been completed.

The key here is the transaction.  If the user is in the middle of the transaction and the server crashes, the transaction would never have been committed in the database.  When IQ starts up again, the version that was being written prior to the crash is uncommitted and thus rolled back.  We simply mark that disk as free so that it can be reused.

IQ has a free list that tracks all used and unused blocks.  Upon commit the free list is updated with the newly written pages.  IQ crashed prior to a commit.  Consequently, those pages in-flight are marked as free again and can be used for the next set of writes as part of our rollback process.  Because of this high level control, the state of the page/block on disk is immaterial.  Since IQ crashed the work is undone, so the state of the disk is irrelevant to the process.

Mark

[former_member420425]

Shashi, Mark, thanks for your comments.

So IQ never modifies an existing block in place ? It always clones the blocks before modifying it ?

I am confused, because I saw a case in the solved cases (Case Number: 11532496), where it is explained that IQ will first write the modified blocks to the IQ checkpoint log (blocktype C ?) and when there is a checkpoint, it will re-write those pages from the IQ checkpoint log to their original location (blocktype A).

Is this correct ? If yes, how does this correlate with your comments ?

Thanks again.

Marco

[markmumy]

Data/index pages are always written new.  We cannot do any in-place updates of pages because we use snapshot versioning and multi-version concurrency control to guarantee data integrity and consistency.  These methods require that the "old" page stay in its original format on disk and that any changes to that page MUST be written to a new page.  That way users that are using the old page can continue to see that data and never block a writer that is changing data.

This is 99% of all disk IO done in IQ.  There are many other small areas of disk where we write and the pattern is different.  That's because they are internal structures where we have complete control over who is accessing and changing the data.

Mark

[former_member420425]

Thanks Mark, it is clear now.

Still have one question: What does the IQ checkpoint log (I mean blocktype C in sp_iqdbspace output) exactly contain ? versioned blockmaps ?

Thanks,

Marco

[markmumy]

The C pages should only be seen in multiplex and on the system main dbspace.  This is, mostly, the internal IQ TLV space, our internal tran logs, etc.

Are you seeing that there are a high number of pages in a 'C' state?  Or just a few periodically?

Mark

[former_member420425]

Mark,

To answer your question, I never see a high number of C blocks. When I execute the sp_iqdbspace procedure I see a few blocks of type C. They disappear and come again. I was just wondering what was their use.

From your post I understand that the C blocks contains the IQ internal transaction log that is located on the IQ main store.

I have found this paragraph in the IQ manuals:

CREATE DATABASE Statement

  Warning!  IQ_SYSTEM_MAIN is a special dbspace that contains all structures necessary for the database to open:

  the IQ db_identity blocks,

  the IQ checkpoint log,

  the IQ rollforward/rollback bitmaps of each committed transaction and each active checkpointed transaction,

  the incremental backup bitmaps,

  and the freelist root pages.

The way I understand it is that the transaction log (IQ rollforward/rollback bitmaps) and the checkpoint log were 2 different things, both located on the IQ Store. Modifying the transaction log(IQ rollforward/rollback bitmaps) generates entries in the checkpoint log. Only when the entries in the IQ internal transaction log are removed, are the corresponding entries in the checkpoint log removed as well (seems to happen when a transaction is APPLIED). Both the IQ internal transaction log and the checkpoint log are used to recover the IQ store.  I am correct ?

Thanks for your help.

Marco