Hi Kevin, In the video you said you gonna tell about trouble shooting of 30 MB execution plan. Do you have a blog or video about working on that issue?
Hi Kevin, I wanted to know any co-relation between the removal of any plan from the plan cache and the corresponding data present in the buffer cache. While removing the plan from the plan cache by the lazy writer does it also perform any action to remove the corresponding data page from the buffer cache. What if happens if there is plan in the plan cache but not present in the buffer cache.
Awesome session... What happens to the data in the transaction log and has not been written to the disk (mdf). if in that mean time the server crashes?
One of us is seriously confused about what Atomic and Consistent mean. Atomic doesn't remotely mean that a transaction "doesn't do multiple things"; it means that the entire transaction goes as an indivisible unit--precisely so that, if you want to do more than one thing (debit one account and credit another), it either all happens or none of it does. Consistent doesn't mean a transaction does the same thing every time you run it, but that the database transitions from one relationally-consistent state to another. It has nothing to do with repeatability. I'm hoping this gets a lot better, fast. The first two substantive things he said about databases seem to be flat-out wrong.
So he got Isolation *reasonably* right--like a grade B--and then confused Durable with Atomic. (Durable means that committed transactions remain committed, even if, say, the server crashes.) I guess I should be grateful that he led off with a topic I know. The rest of the video is a pass.
Consistency means If there is any disaster in the system also, the transactions should be consistent either by rolling backward or rolling forward after the disaster.
Thanks, Kevin, for taking the time to make it easy to digest.
great lecture still we passed 10 years but the lecture get super and it made easy understand architecture great simple a fan made comment
super kevin, this video gives the 100% clarity about the internal architecture of sql.
Thanks A Lot Kevin..
One of the best explanation..
Thanks Kevin!!! You helped me learn the SQL architecture to an extent.
Hey mate you can join this one also ua-cam.com/play/PLfz1lS_mCZd9zQKzf0mQGc8QyDK25I6FI.html
ua-cam.com/video/jskazgQ9_VI/v-deo.html
Thanks Kevin for this excellent presentation !!!
This is great, helps understand the internals nicely, thanks Kevin,
Thanks for uploading this Kevin..
Thank you Kevin, this is very helpful.
loved it
I have covered one session abt ARCHITECTURE
Wow, that was very educational. KK is like the CK Louis of SQL teaching. Many thanks for the upload!
very informative video... thanks
Amazing, thanks for that.
Best Session!!
Good one 👍
Hi Kevin, In the video you said you gonna tell about trouble shooting of 30 MB execution plan. Do you have a blog or video about working on that issue?
Very interesting, i did not know about optimizer, funny thing
Wow. I learned a lot
Very goo content
Hi Kevin, I wanted to know any co-relation between the removal of any plan from the plan cache and the corresponding data present in the buffer cache. While removing the plan from the plan cache by the lazy writer does it also perform any action to remove the corresponding data page from the buffer cache. What if happens if there is plan in the plan cache but not present in the buffer cache.
Awesome!
Hi Kevin does it use MRU(Most rectently used for frequently running plans),LRU will be in bottom of buffer cache?
Did he say ACID?
How & who does load the newly created Plan from Query Optimizer to Plan cache???
Why were databases created in the first place. To make money for companies. Never thought bout it that way before
Hi kevin
what is the actual job of query executor?
Awesome session...
What happens to the data in the transaction log and has not been written to the disk (mdf). if in that mean time the server crashes?
Data will be lost in the above scenario.
42:49 Does that mean that the Cmd Parser is the one in charger of looking up the cache plan for matchinf execution plans for the received query?
One of us is seriously confused about what Atomic and Consistent mean. Atomic doesn't remotely mean that a transaction "doesn't do multiple things"; it means that the entire transaction goes as an indivisible unit--precisely so that, if you want to do more than one thing (debit one account and credit another), it either all happens or none of it does. Consistent doesn't mean a transaction does the same thing every time you run it, but that the database transitions from one relationally-consistent state to another. It has nothing to do with repeatability. I'm hoping this gets a lot better, fast. The first two substantive things he said about databases seem to be flat-out wrong.
So he got Isolation *reasonably* right--like a grade B--and then confused Durable with Atomic. (Durable means that committed transactions remain committed, even if, say, the server crashes.) I guess I should be grateful that he led off with a topic I know. The rest of the video is a pass.
@@craigbryant3191 Thanks for clarifying, I'm new to ACID and those were a little confusing as I was trying to reason through it in my head.
Atomicity means either all the statements should get committed or none of the statements should be committed.
Consistency means If there is any disaster in the system also, the transactions should be consistent either by rolling backward or rolling forward after the disaster.
Consider ATM of any bank as an example it will be the perfect one to understand easily.
grt
Hi Kevin.... I told my son I can make pal with you by database reply me
from where can we get the slides
I believe here are the slides kevinekline.com/wp-content/uploads/2010/03/UG-SQL-Server-Internals-Architecture.pdf
Navneet Gupta thank you brother and the best gift that I can give to you in return is this...
quran.com/
examples for consistant and isolated trasaction didnt make sense.. Wikipedia has good example to understand these concepts