Assertion 101419 - page not pinned

[justin_willey]

Has anyone come across this assertion? I can't find any references on-line or elsewhere.

*** ERROR *** Assertion failed: 101419 (10.0.1.4310) E. 03/14 15:11:11. page not pinned

The db re-started without complaint, but I won't be able to do a validation until later (it's a huge database), but we have live log back-ups. The database files were moved on to new SAN hardware last night.

I suppose I am asking whether this is likely to indicate a database corruption, and if so what form it might take; also whether it can give us any indication of any possible problem with the hardware? The SAN is the latest top-spec EMC fibre-channel kit configured as RAID 10.

v 10.0.1.4310

---

UPDATE DB passed validation

---

UPDATE Has happened again, about two weeks after the first time, no problems in between. Given John's explanation about heap pages, is this likely to be a related to a server bug or something we are doing?

---

FURTHER UPDATE This assertion carried on happening regularly (approx once or twice a week) until the server was upgraded to 11.0.1 - now about for weeks without repetition. It seems that the problem relates to v10.0.1 together with the particular hardware / environment.

[Breck_Carter]

FWIW that is a super-rare assertion with only three reports in cyberspace and no solutions or workarounds... try calling tech support to get an answer on "database corruption" or not.

[VolkerBarth]

Required counter-question: Does the SAN support the "writethrough" semantics (i.e. no unwanted caching) as specified for SQL Anywhere storage systems?

(Cf. this whitepaper)

[justin_willey]

It looks OK , but I'm double checking.

[johnsmirnios]

It is very unlikely that this assertion failure would be due to database corruption. I also expect that it is unlikely to indicate that something was going on that could cause corruption but that's a much more difficult call to make.

[justin_willey]

Thanks John, that's helpful in determining priorities.

[MCMartin]

Which OS are you using?

[justin_willey]

It's 2008 R2 64-bit Enterprise

[VolkerBarth]

Wild guess: May bad RAM have an influence here?

[jeff_albion]

Is this running on a Windows, Linux or other OS?

(I will assume Windows...)

Have you checked your OS settings regarding how you have configured the ( http://support.microsoft.com/kb/314482 ) page file / swap space? Have you monitored this system for 'low-memory' issues (either in real or virtual memory) via Performance Monitor (or similar)? Have you scanned for bad memory ( http://technet.microsoft.com/en-us/magazine/ff700221.aspx / http://www.memtest86.com/ / http://www.memtest.org/ ) as Volker has recommended?

What drive is the temporary file stored on and have you scanned that drive (chkdisk / scandisk) for potential issues?

[justin_willey]

Hi Jeff,

it's Windows Server R2 2008 64-bit Enterprise.

There is 160GB of RAM on the system, about 60GB is configured for cache at the moment (we've found that having more leads to a longer time before the DB comes up to "full working speed"). There nothing at all being reported in the Event Log (except for what SQL Anywhere is putting there re the assertion & restarting).

The temp files are on a dedicated RAID 1 array, I'll get the logs on the controller checked, in case something is showing there and schedule a full check. Similarly with the RAM, nothing has been reported (and I think 2008 server has the ability to do that), but again we can schedule a memory check.

Many thanks for the checklist!

Justin

[MCMartin]

Have you checked How to: Enable the Lock Pages in Memory Option (Windows)

It is disabled by default on Win 2008 R2.

[justin_willey]

Thanks for looking at this. My understanding was that this was a 32-bit AWE thing (to do with the AWE page swapping business) and did not apply to 64-bit OSs. Is "page not pinned" something to do with memory pages, I suppose I was thinking in terms of database file pages rather memory pages.

[johnsmirnios]

The 'Lock Pages in Memory' setting has nothing to do with this assertion failure. A 'pinned' page in this case is one that is being used by an internal memory heap. The failure indicates that we tried to unlock or dispose of the heap but one of the pages we tried to unlock wasn't a heap page.