Hello,
We've been sticking with 4K block size in Windows and now we're considering the move to 8K block size. Any specific tips or issues to beware of? Does the Windows version matter (i.e.. 2003 R2 or 2008 R2...). OE version is either 10.1C no SP or 10.2B05.
From what I understood, if the database uses Type I storage, you would need to format the NTFS volume using 8K (to avoid getting "torn" pages should a failure occur), but no need for this on Type II since it is "torn-proof".
Also, I read this: "8 KB blocksize will /generally/ give better performance than 4 KB. There are exceptions,
such as if the records per block is less than 32 and the average record size is very small and
there are many of them"
Does this still hold? And is it an 8K deal breaker ?
Thanks
> but no need for this on Type II since it is "torn-proof".
It's not correct. The check sums of the blocks in Type II storage areas make it's easy to find out the corrupted blocks but they will not help to repair the corruptions.
> they will not help to repair the corruptions
There won't be a transaction rollback while upping again the database?
Any ideas about the second part ("There are exceptions, such as if the records per block is less than 32 ...")?
Thanks
>> they will not help to repair the corruptions
>There won't be a transaction rollback while upping again the database?
If the torn page resulted from an error when the modified block was flushed from the file system cache to storage, at that point the database transaction has already committed. There is nothing to roll back. The block is physically corrupt.