April 17, 2013 at 3:23 pm
Thanks again for the help.
What are some of the advantages? Is it just so that the behavior is more predictable?
Thanks for the help,
Dane
April 17, 2013 at 3:28 pm
It ensures that data in your columns adheres to that column's data type. Nothing more really. But once you run it once WITH DATA_PURITY you'll always get those checks out of a standard CHECKDB. The engine is not supposed to allow invalid data into the DB anymore, but if someone or something directly changes a page or the data file using a hex editor a regular run of CHECKDB will report it by default.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
April 17, 2013 at 3:36 pm
Two questions:
1. Should the page verification on recovery find those changes (if you have it set to CHECKSUM)?
2. Can a data file be changed while the DB is actively running (outside of the engine making the change)?
Making sure I understand these items.
Thanks again for the help,
Dane
April 17, 2013 at 3:45 pm
1. CHECKSUM would likely catch straight mods to a page outside the engine. That's their reason for existing. Point was that the engine is supposed to disallow out-of-bounds data values through normal means.
2. Not sure, but I doubt unless it is done below the Windows file system level or while the database was offline since SQL Server will likely have an open file handle to open databases.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
April 17, 2013 at 6:39 pm
Awesome thanks! I will work at getting the CHECKDB changed on our production system.
Thanks again for all the help!
-Dane
Viewing 5 posts - 31 through 34 (of 34 total)
You must be logged in to reply to this topic. Login to reply