November 29, 2012 at 6:09 am
SQLSACT (11/28/2012)
Please don't get me wrong, I'm not saying that you're are being contradictory. There's obviously a huge difference between what you're implying and what I'm inferring.
FYI: I think this right here is your biggest issue. You're making assumptions about how SQL works and when Gail is telling you how it really does work, her words don't fit your assumptions. You're trying to shoehorn her (and other people's) comments into your vision of how SQL works and since you can't, their words seem contradictory.
It's time to step back, throw out everything you think you know about SQL Server, and read that book. Go into it without assumptions. Go into it without trying to visualize how you think SQL Server works. Read the book and make your charts and diagrams and stuff based on what the book says.
When you're done with that, come back and re-read what Gail and everyone else has been telling you. I promise it will make more sense than if you continue trying to shoehorn their words into your world view.
November 29, 2012 at 11:28 am
SQLSACT (11/29/2012)
GilaMonster (11/29/2012)
A page is just an 8kb chunk of data. Given that, what exactly is the difference between a page (an 8kb chunk of data) and the contents of the page (8kb of data)?I see where my understanding was throwing me off now..
I my mind, I pictured a Page to be a seperate entity that SQL creates and then subsequently stores info on that.
I think that the terminology you are using is probably a source of confusion. In these discussions and the referenced description seems to call the 8192 byte regions of data on the disk pages. You might also be using the term page to reference the 8kb copies of that data in system memory that SQL server actually reads and writes to., ie the page in the page cache (probably more accurately referred to as buffer pool). These pages in the page cache are probably indeed separate entities, they're essentially a set of memory pages that can contain copies of the 8kb regions of data on disk, or contain zeros (or random data) that are NOT copies of 8kb regions of data on disk. They can also obviously be marked "dirty", ie., SQL server has modified them, or "clean", SQL server has not modified them since they have been last been read from or written to disk.
Hypothetically, say I have 10 pages available for use in a buffer pool. These 10 pages in the buffer pool can be used to read and write pages for a datafile that could very well be 1000 pages big. Its probably these 10 pages that you're discussing as being the "separate entity". Each one of these 10 pages will "map" to one of the 1000 pages of datafile storage or map to nothing (marked free).
I think these 10 pages in my hypothetical little server thing are what is called the "buffer pool", or available 8k pages of ram that can represent arbitrarily located 8kb pages of disk storage.
Apologies to everyone if I'm simply full of it LOL
Viewing 2 posts - 16 through 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply