- Se incorporó
- 15 Enero 2004
- Mensajes
- 11.872
Acá en la pega tenemos unos sql server chicos sobre Vmware y una SAN. El storage tiene esas feautures choras como multi-tier automático que te mueve los bloques a capas de discos más rápidas o más lentas según el uso que le des, de manera transparente para los servidores y el administrador.
La cosa es que en un curso de sql server el instructor nos dice que es importante hacer defragmentación aún cuando sql server esté basado en una plataforma virtual y yo quedé como
, porque me tinca que hacer un defrag lo único que va a lograr es que aumente temporalmente la escritura en el volúmen y nada más que eso, pues la ubicación física de los bloques no depende de windows sino que depende del storage.
¿Alguien tiene experiencias al respecto? Yo estoy googleando por si encuentro algo y las opiniones dicen más o menos lo mismo, no tiene sentido y menos aún en un storage basado en tiers.
This comes up time and time again, the simple answer is not to bother, apart from adding IO to the guest and underlying disks, your data is within a flat file, that flat file is what would need to be defragged, if you run thin disks a defragment would simply bloat it (expand it out) based on it writing out data to new locations, meaning the space increases unnecessarily.
If your storage is using tiered storage then the storage may be moving blocks of data about itself, so defragmenting is not needed
Can you do it - yes, do you gain anything - possibly, but with caveats and downsides, 99% of people don't bother, it's added overhead and thin can become thick due to the moving of blocks.
dato: no confundir con la reorganización de los índices, que consiste en recrear el índice de manera lógica para que el árbol b-tree quede equilibrado.
La cosa es que en un curso de sql server el instructor nos dice que es importante hacer defragmentación aún cuando sql server esté basado en una plataforma virtual y yo quedé como
, porque me tinca que hacer un defrag lo único que va a lograr es que aumente temporalmente la escritura en el volúmen y nada más que eso, pues la ubicación física de los bloques no depende de windows sino que depende del storage.¿Alguien tiene experiencias al respecto? Yo estoy googleando por si encuentro algo y las opiniones dicen más o menos lo mismo, no tiene sentido y menos aún en un storage basado en tiers.
This comes up time and time again, the simple answer is not to bother, apart from adding IO to the guest and underlying disks, your data is within a flat file, that flat file is what would need to be defragged, if you run thin disks a defragment would simply bloat it (expand it out) based on it writing out data to new locations, meaning the space increases unnecessarily.
If your storage is using tiered storage then the storage may be moving blocks of data about itself, so defragmenting is not needed
Can you do it - yes, do you gain anything - possibly, but with caveats and downsides, 99% of people don't bother, it's added overhead and thin can become thick due to the moving of blocks.
Defragmenting database disk drives - SQL Server
This article provides some guidance regarding defragmentation of SQL Server database drives.
docs.microsoft.com
dato: no confundir con la reorganización de los índices, que consiste en recrear el índice de manera lógica para que el árbol b-tree quede equilibrado.
Última modificación:
