none
WITH CHECK OPTION, WITH VIEW_METADATA y WITH CHECKPOINT SQL Server RRS feed

  • Pregunta

  • Holaa todos como andan...
    Alguien me puede ayudar acerca estas opciones, que significan y para que se usan...

    WITH CHECK OPTION
    WITH VIEW_METADATA
    WITH CHECKPOINT "Entiendo que esta es usada para guardar los meta datos o algo asi, pero como puedo consultar estos o como puedo hacer uso de esta opcion"


    Tomando estas consultas.... Que significa "INCLUDE"

    CREATE NONCLUSTERED INDEX idx
    ON dbo.Sales(CommentDate, SalesPersonId)
    INCLUDE(CustomerId)
    WHERE CommentDate IS NOT NULL;


    Y ahora tomando este problema...

    Your database is 5gb and contains a table named SalesHistory. Sales information is frequently inserted and updated
    You discover that exccesiver page splitting is occurring you need to reduce the occurence of page splitting the Sales History table

    Que significa mas o menos esta consulta Rebuid, FillFactor"...
    ALTER INDEX ALL ON Sales.SalesHistory
    REBUILD WITH (FILLFACTOR = 60)

    De antemano mil gracias a todos por su ayuda...

    miércoles, 9 de junio de 2010 3:23

Respuestas

  • Hola.

    Voy a ver si consigo explicar lo del include en un índice nonclustered, porque hay cosillas que sí, pero otras no veo que las hayas comprendido. Me voy a remontar un poco y que conste que es una simplificación con fines pedagógicos.

    Un índice clustered es la tabla, cuyos registros se encuentran ordenados por los campos que van en el índice, pero que en el nivel hoja tiene todos los demás campos. Por encima del nivel hoja se coloca otro conjunto de páginas con punteros a las páginas del nivel hoja. Esos punteros contienen sólo información de los campos que están ordenados. Si es necesario, se sitúan más niveles por encima.

    Un índice nonclustered es un subconjunto de los campos de la tabla, ordenados por los campos del índice y en el orden especificado, a los que se les acoplan los campos del índice clustered. El motivo es para poder usar un índice para una consulta en la que no todos los campos están en el índice. En el fondo, es buscar el registro en la tabla, y la tabla es el índice clustered.

    Si la consulta se puede resolver sólo con los propios campos del índice no debe ir al índice clustered. Este "ir al índice clustered" es una penalización para el rendimiento. Sin embargo, incluir muchos campos en un índice lo hace poco práctico, porque se eleva el tamaño. A mayor tamaño, menos registros caben en cada tabla y, por tanto, hay que leer más páginas para obtener la misma información.

    Una buena solución para determinados casos es un índice nonclustered con campos incluidos. Es un subconjunto de los campos de la tabla, de los cuales sólo están ordenados los que están en la parte del índice. Los de la parte del include no van ordenados y sólo están en el nivel hoja. El objetivo es no tener que ir luego al índice clustered para resolver la consulta.

    Espero haber sido claro, pero si no es así, nos cuentas.


    Alberto López Grande (Visita mi blog en http://qwalgrande.blogspot.es/)
    jueves, 10 de junio de 2010 20:05
    Moderador
  • Hola.

    Bueno, vamos con el checkpoint. Como indica la ayuda, es un comando que baja las páginas desfasadas de memoria a disco. Esta bajada se produce igual, por un proceso en segundo plano (lazy write), aunque no lo llames a mano, se va haciendo. Luego, hay otros procesos que lo ejecutan, como los backups. Sirve para tener un punto de consolidación que te asegure que toda la información está en disco. Eso facilita los restores, por ejemplo, el reciclado del log de transacciones, etc.

    Y la duda sería que por qué se hace así, porqué es un proceso asíncrono. Es una cuestión de rendimiento. Es más rápido escribir en memoria que en el disco y más cuando vas a tener que modificar varias veces la misma página en breve por estar en medio de una transacción. La página se deja en memoria y cuando ya no hay procesos que requieran la modificación, se baja la información a disco.

    Otro detalle importante. Cuando se produce el commit, tienes la certeza de que el dato está salvado, en disco. Este comando puede dejar alguna ambigüedad a ese respecto, pero no tengas dudas, cuando haces commit, en el log de transacciones ya se ha escrito que el dato ha sido cambiado.

    El otro comando es bastante más simple. Es la forma de realizar las reindexaciones de las tablas en sintaxis de SQL Server 2005 o posterior. Es lo mismo que antes hacía DBCC DBREINDEX. Si tu duda es acerca del fill factor (factor de relleno), decirte que significa que cada página se ocupa sólo en un 60%, en lugar de ocuparse por completo. Esto es útil en algún caso aislado de tablas que sufren numerosas inserciones en medio de los índices, ya que al dejar estos huecos, las inserciones se producen en ellos, lo cual evita que haya que crear una página referenciada en la secuencia (el page split, que se llama).

    Lo normal es ocupar las páginas en su totalidad. Poniendo un ejemplo, supón que tienes una tabla de usuarios, con un IDUsuario que es un entero autoincremental y un nombre. Tienes un índice, que es la clave primaria sobre este campo autoincremental. No tiene sentido dejar huecos en ese índice porque los nuevos valores son siempre mayores que todos los que hay. Pero si tienes otro índice por el nombre, ahí los nombres nuevos pueden caer en cualquier parte. Si se inserta un registro, se actualiza el índice, creándose el valor en el sitio en el que le corresponda. Si el lugar que le corresponde es una página que ya está llena, se tiene que crear una nueva página referenciada. Eso repercute en el rendimiento, ya que para leer la misma información hay que leer más páginas. Se resuelve reindexando periódicamente.

    Es algo excepcional que un índice se deba dejar con huecos. El fill factor hace que un mismo índice ocupe mucho más espacio y eso repercute igualmente en el rendimiento. Por evitar el page split no puedes partir de un estado ya menos óptimo. 

     


    Alberto López Grande (Visita mi blog en http://qwalgrande.blogspot.es/)
    • Marcado como respuesta AdyIr domingo, 13 de junio de 2010 19:25
    domingo, 13 de junio de 2010 10:28
    Moderador

Todas las respuestas

  • Sin ánimo de ofender pero... ¿has echado un vistazo a la ayuda (Books On Line) sobre esos temas antes de acudir al foro? Creo que la explicación que puedes encontrar ahí es mucho mejor que la que te podamos dar aquí.
    miércoles, 9 de junio de 2010 7:33
  • Hola.

    Coincido con Carlos. También te animo a que prosigas con tu aprendizaje, ya que ese "problema" es una pregunta típica de un examen de certificación. Así que primero toma los Books Online como guía de referencia. Si después de revisar los Books Online no consigues resolver cada duda, ya sabes donde estamos.


    Alberto López Grande (Visita mi blog en http://qwalgrande.blogspot.es/)
    miércoles, 9 de junio de 2010 12:53
    Moderador
  • Hola.

    Coincido con Carlos. También te animo a que prosigas con tu aprendizaje, ya que ese "problema" es una pregunta típica de un examen de certificación. Así que primero toma los Books Online como guía de referencia. Si después de revisar los Books Online no consigues resolver cada duda, ya sabes donde estamos.


    Alberto López Grande (Visita mi blog en http://qwalgrande.blogspot.es/)

    Hola amigo como estan, si he leído acerca del tema pero no termino de comprender…

    Lo único que si tengo medio claro es Check Opion, que lo que he podido comprender es que no me permite hacer modificaciones de datos que no cumplan una determinada condición, por ejemplo si hago asi…

    CREATE VIEW [dbo].[vPruebacONCheckPoint] (Empleado, cedula, Empresa, Monto)

    AS

    SELECT  Empl.NOMBRE, Empl.CEDULA, Empr.NOMBRE, Sal.MONTO FROM EMPLEADO Empl

                       INNER JOIN EMPRESA Empr

                       ON Empl.ID_EMPRESA = Empr.ID_EMPRESA

                       INNER JOIN Salario Sal

                       ON Empl.ID_Salario = Sal.ID_SALARIO

    WHERE Empr.NOMBRE = 'Microsoft' AND Sal.MONTO = 2000000

    WITH CHECK OPTION

     

    No podrá hacer ninguna modificación a la vista de la empresa, en este caso, “Microsoft” ya que si haces eso, estaría fuera de conficion de la vista y no aplicaría a esta, es decir, se encarga de que todos la datos que modifique no salgan de la condición dada para futuras consultas… Esto es más o menos lo que yo he podido entender leyendo, en especial, en la pagina http://msdn.microsoft.com/es-es/library/ms187956.aspx pero no sé si tendrá un uso más profundo…

     

    WITH VIEW_METADATA: Ya lo lei y ni pio entiendo… http://msdn.microsoft.com/es-es/library/ms187956.aspx

     

    WITH CHECKPOINT

    Lo definen asi ‘Escribe en el disco todas las páginas desfasadas de la base de datos actual. Las páginas desfasadas son páginas de datos que se han incluido en la memoria caché del búfer y se han modificado, pero todavía no se han escrito en el disco. Los puntos de comprobación permiten ahorrar tiempo en una recuperación posterior al crear un punto en el que se garantiza que todas las páginas desfasadas se hayan escrito en el disco.”

    Eso quiere decir que cuando yo no aplico CheckPoint los datos estan en la Cache y no el Disco duro? Cual es la diferencia a que estén en un lugar o en otro…? Entiendo que cada vez que se ingresa a unos datos por primera vez, se crea una copia de los datos del disco lo cual es la cache, ya que estos son mas fáciles de acceder, pero no entiendo mucho igual, para que yo quesera que me guarde cada vez que ejecute algo en el disco directamente y no en la cache? A que me ayudaría esto?, como es ese proceso interno?

     

    INCLUDE

    En verdad tampoco entendí mucho… http://technet.microsoft.com/es-es/library/ms189607.aspx

    Lo que yo entiendo de cómo se organizan los índices externamente, es algo asi…

    Paginas de Indices… “Basados en nombre”

    Nivel de ruta               Ruta intermedia                     Left Data

    Pag 1                                                     Pag 2                                     Pag 4

    Ana / 2                                                  Ana / 4                                  Ana                       

    Jose / 2                                                 Anita / 4                               Anita

    Rafael / 3                                             Jose, 5

                                                                    Josefa / 5

                                                                                                                    Pag 5

                                                                                                                    Jose

                                                                                                                    Josefa

                                                                                                                    Josefina

                                                                    Pag 3

    Rafael / 6                                                                                            

                                                                    Ramon / 6                                          

                                                                                                                    Pag 6

                                        Rafael  

                                                    Ramirez                                                                                                                                                Ramon 

                                       

    Entonces si hago con include por ejemplo de cedula seria algo asi…?

    Pag 1

    Ana, 55444 /  2

    Si seria asi que no lo creo en que me ayudaría…

     

    Rebuild y Fill Factor

    La verdad aquí no comprendo casi nada… Yo encontré esta información pero nada que termine de comprenderla, ni que hace ni para que usarla…

    REBUILD [ WITH (<rebuild_index_option> [ ,... n]) ]

    Specifies the index will be rebuilt using the same columns, index type, uniqueness attribute, and sort order. This clause is equivalent to DBCC DBREINDEX. REBUILD enables a disabled index. Rebuilding a clustered index does not rebuild associated nonclustered indexes unless the keyword ALL is specified. If index options are not specified, the existing index option values stored in sys.indexes are applied. For any index option whose value is not stored in sys.indexes, the default indicated in the argument definition of the option applies.

    When you rebuild an XML index or a spatial index, the options ONLINE = ON and IGNORE_DUP_KEY = ON are not valid.

    If ALL is specified and the underlying table is a heap, the rebuild operation has no effect on the table. Any nonclustered indexes associated with the table are rebuilt.

    The rebuild operation can be minimally logged if the database recovery model is set to either bulk-logged or simple. For more information, see Choosing a Recovery Model for Index Operations.

     

    FILLFACTOR = fillfactor

    Specifies a percentage that indicates how full the Database Engine should make the leaf level of each index page during index creation or alteration. fillfactor must be an integer value from 1 to 100. The default is 0.

     

     

    Muchas gracias de Nuevo y disculpa la ignorancia, pero justamente como comentastes me estoy preparando para la prueba de certificación y hay muchisimooooo que estudiar y materiales y la verdad hay ciertas cosas que son algo complicadas, de antemano mil gracias de nuevo…

    miércoles, 9 de junio de 2010 20:44
  • Hola.

    Coincido con Carlos. También te animo a que prosigas con tu aprendizaje, ya que ese "problema" es una pregunta típica de un examen de certificación. Así que primero toma los Books Online como guía de referencia. Si después de revisar los Books Online no consigues resolver cada duda, ya sabes donde estamos.


    Alberto López Grande (Visita mi blog en http://qwalgrande.blogspot.es/)

    Hola amigo que tal, ya he investigado acerca de eso, pero hay cosas que no alcanzo a comprender... Le escribi un comentario el conversacional de Alberto si puedes hecharme una mano, mil veces agradecido...
    miércoles, 9 de junio de 2010 20:45
  • Hola.

    A ver si consigo explicarlo un poco. 

    Opción "with check option" en vistas: En determinadas vistas puedes realizar inserciones, como si fueran tablas. Con esta opción, impides que se puedan insertar registros con un insert en la vista en la que no se cumplan las propias condiciones de la vista. Esta creo que la tienes clara.

    Opción "with view_metadata" en vistas: Esta opción no es nada frecuente y es mejor dejarla como está salvo contadísimos casos. Hace que los metadatos que se devuelvan a las API de OLE DB no sean los de las tablas que referencia la vista, sino los de la vista en sí. Si en el examen te preguntan por esta sería para hacérselo mirar.

    Opción "include" en índices: Esta sí es muy útil. Permite agregar campos a un índices, pero sólo en el nivel hoja. La ventaja de esto es que evitas recurrir a los índices clustered, no se hacen bookmarks y se reducen las lecturas. Consigues índices covered de una forma mucho más económica. Pero de todos modos, ¿no estuvimos hablando de esto hace no mucho en un hilo?

    Y bueno, creo que de momento es una parte, seguro que podemos seguir con otros de los términos más adelante.

     


    Alberto López Grande (Visita mi blog en http://qwalgrande.blogspot.es/)
    miércoles, 9 de junio de 2010 21:42
    Moderador
  • Hola.

    A ver si consigo explicarlo un poco. 

    Opción "with check option" en vistas: En determinadas vistas puedes realizar inserciones, como si fueran tablas. Con esta opción, impides que se puedan insertar registros con un insert en la vista en la que no se cumplan las propias condiciones de la vista. Esta creo que la tienes clara.

    Opción "with view_metadata" en vistas: Esta opción no es nada frecuente y es mejor dejarla como está salvo contadísimos casos. Hace que los metadatos que se devuelvan a las API de OLE DB no sean los de las tablas que referencia la vista, sino los de la vista en sí. Si en el examen te preguntan por esta sería para hacérselo mirar.

    Opción "include" en índices: Esta sí es muy útil. Permite agregar campos a un índices, pero sólo en el nivel hoja. La ventaja de esto es que evitas recurrir a los índices clustered, no se hacen bookmarks y se reducen las lecturas. Consigues índices covered de una forma mucho más económica. Pero de todos modos, ¿no estuvimos hablando de esto hace no mucho en un hilo?

    Y bueno, creo que de momento es una parte, seguro que podemos seguir con otros de los términos más adelante.

     


    Alberto López Grande (Visita mi blog en http://qwalgrande.blogspot.es/)

    Hola Alberto, que tal. Muchas gracias una vez mas…

    with check option: Completamente claro, gracias…

    with view_metadata: Aunque no entiendo para que hacer eso, si entendi que hace. Gracias de nuevo…

    include: La verdad tu me has ayudado en muchas preguntas últimamente pero sinceramente no habia preguntado acerca de esto, ¡si hablamos de los índices cluster y non clustered! pero no de Include, es decir, por tu explicación me estas queriendo decir que con INCLUDE simplemente estoy agregando un índice non clustered mas?... Gracias de nuevo…

    jueves, 10 de junio de 2010 14:26
  •  

    De nuevo yo, tocando el punto Include, ya lo tengo algo mas claro, aqui hay dos link muy buenos con respecto al tema.. Es algo asi como agregarle a la hoja mas baja del indice un campo adicional, el cual no se tomara en cuenta a la hora de ordernar el indice lo cual hace mas rapido el proceso o algo asi y te permite que el tamaño de los indices sean mas amplios, segun lo que lei no se si me equivoco un indice tiene un tamaño maximo de 900 byte o lago asi... Asi que si tenemos varios campos como indices, por ejemplo (Nombre, Registros, Campo3, Campo4) y entre los 4 excenden ese tamaño podemos usar como indice solo 2 o 3 campos de esos y el resto lo agregamos con este metodo INCLUDE...

    http://msdn.microsoft.com/es-es/library/ms190806.aspx

    http://sqlblog.com/blogs/roman_rehak/archive/2007/05/03/why-use-included-columns-in-sql-server-2005.aspx

    El primer link es super mas extenso y especifico y el segundo te lo explican brevemente de manera sencilla, aunque no estoy 100% claro y no se muy cuando debo usarlo, ya me quedo algo, luego con la practica lo comprenderé mejor...

    jueves, 10 de junio de 2010 15:12
  • Hola.

    Voy a ver si consigo explicar lo del include en un índice nonclustered, porque hay cosillas que sí, pero otras no veo que las hayas comprendido. Me voy a remontar un poco y que conste que es una simplificación con fines pedagógicos.

    Un índice clustered es la tabla, cuyos registros se encuentran ordenados por los campos que van en el índice, pero que en el nivel hoja tiene todos los demás campos. Por encima del nivel hoja se coloca otro conjunto de páginas con punteros a las páginas del nivel hoja. Esos punteros contienen sólo información de los campos que están ordenados. Si es necesario, se sitúan más niveles por encima.

    Un índice nonclustered es un subconjunto de los campos de la tabla, ordenados por los campos del índice y en el orden especificado, a los que se les acoplan los campos del índice clustered. El motivo es para poder usar un índice para una consulta en la que no todos los campos están en el índice. En el fondo, es buscar el registro en la tabla, y la tabla es el índice clustered.

    Si la consulta se puede resolver sólo con los propios campos del índice no debe ir al índice clustered. Este "ir al índice clustered" es una penalización para el rendimiento. Sin embargo, incluir muchos campos en un índice lo hace poco práctico, porque se eleva el tamaño. A mayor tamaño, menos registros caben en cada tabla y, por tanto, hay que leer más páginas para obtener la misma información.

    Una buena solución para determinados casos es un índice nonclustered con campos incluidos. Es un subconjunto de los campos de la tabla, de los cuales sólo están ordenados los que están en la parte del índice. Los de la parte del include no van ordenados y sólo están en el nivel hoja. El objetivo es no tener que ir luego al índice clustered para resolver la consulta.

    Espero haber sido claro, pero si no es así, nos cuentas.


    Alberto López Grande (Visita mi blog en http://qwalgrande.blogspot.es/)
    jueves, 10 de junio de 2010 20:05
    Moderador
  • Hola.

    Voy a ver si consigo explicar lo del include en un índice nonclustered, porque hay cosillas que sí, pero otras no veo que las hayas comprendido. Me voy a remontar un poco y que conste que es una simplificación con fines pedagógicos.

    Un índice clustered es la tabla, cuyos registros se encuentran ordenados por los campos que van en el índice, pero que en el nivel hoja tiene todos los demás campos. Por encima del nivel hoja se coloca otro conjunto de páginas con punteros a las páginas del nivel hoja. Esos punteros contienen sólo información de los campos que están ordenados. Si es necesario, se sitúan más niveles por encima.

    Un índice nonclustered es un subconjunto de los campos de la tabla, ordenados por los campos del índice y en el orden especificado, a los que se les acoplan los campos del índice clustered. El motivo es para poder usar un índice para una consulta en la que no todos los campos están en el índice. En el fondo, es buscar el registro en la tabla, y la tabla es el índice clustered.

    Si la consulta se puede resolver sólo con los propios campos del índice no debe ir al índice clustered. Este "ir al índice clustered" es una penalización para el rendimiento. Sin embargo, incluir muchos campos en un índice lo hace poco práctico, porque se eleva el tamaño. A mayor tamaño, menos registros caben en cada tabla y, por tanto, hay que leer más páginas para obtener la misma información.

    Una buena solución para determinados casos es un índice nonclustered con campos incluidos. Es un subconjunto de los campos de la tabla, de los cuales sólo están ordenados los que están en la parte del índice. Los de la parte del include no van ordenados y sólo están en el nivel hoja. El objetivo es no tener que ir luego al índice clustered para resolver la consulta.

    Espero haber sido claro, pero si no es así, nos cuentas.


    Alberto López Grande (Visita mi blog en http://qwalgrande.blogspot.es/)


    jejeje bueno amigo no puedo pedir mas claro que se entendio, solo te agradezco por tu tiempo y gran pedagogia, aunque si te pedir otra cosa y es que sime puedes ayudar con las otras opciones que puse

    - WITH CHECKPOINT

    -ALTER INDEX ALL ON Sales.SalesHistory
    REBUILD WITH (FILLFACTOR = 60)

    En verdad disculpa la molestia pero en verdad deseo muchisimo aprobar esa prueba... A parte es algo costosa y necesito preparame mucho para no perder la prueba y el dinero...

    De nuevo muchas gracias...

    sábado, 12 de junio de 2010 0:07
  • Hola.

    Bueno, vamos con el checkpoint. Como indica la ayuda, es un comando que baja las páginas desfasadas de memoria a disco. Esta bajada se produce igual, por un proceso en segundo plano (lazy write), aunque no lo llames a mano, se va haciendo. Luego, hay otros procesos que lo ejecutan, como los backups. Sirve para tener un punto de consolidación que te asegure que toda la información está en disco. Eso facilita los restores, por ejemplo, el reciclado del log de transacciones, etc.

    Y la duda sería que por qué se hace así, porqué es un proceso asíncrono. Es una cuestión de rendimiento. Es más rápido escribir en memoria que en el disco y más cuando vas a tener que modificar varias veces la misma página en breve por estar en medio de una transacción. La página se deja en memoria y cuando ya no hay procesos que requieran la modificación, se baja la información a disco.

    Otro detalle importante. Cuando se produce el commit, tienes la certeza de que el dato está salvado, en disco. Este comando puede dejar alguna ambigüedad a ese respecto, pero no tengas dudas, cuando haces commit, en el log de transacciones ya se ha escrito que el dato ha sido cambiado.

    El otro comando es bastante más simple. Es la forma de realizar las reindexaciones de las tablas en sintaxis de SQL Server 2005 o posterior. Es lo mismo que antes hacía DBCC DBREINDEX. Si tu duda es acerca del fill factor (factor de relleno), decirte que significa que cada página se ocupa sólo en un 60%, en lugar de ocuparse por completo. Esto es útil en algún caso aislado de tablas que sufren numerosas inserciones en medio de los índices, ya que al dejar estos huecos, las inserciones se producen en ellos, lo cual evita que haya que crear una página referenciada en la secuencia (el page split, que se llama).

    Lo normal es ocupar las páginas en su totalidad. Poniendo un ejemplo, supón que tienes una tabla de usuarios, con un IDUsuario que es un entero autoincremental y un nombre. Tienes un índice, que es la clave primaria sobre este campo autoincremental. No tiene sentido dejar huecos en ese índice porque los nuevos valores son siempre mayores que todos los que hay. Pero si tienes otro índice por el nombre, ahí los nombres nuevos pueden caer en cualquier parte. Si se inserta un registro, se actualiza el índice, creándose el valor en el sitio en el que le corresponda. Si el lugar que le corresponde es una página que ya está llena, se tiene que crear una nueva página referenciada. Eso repercute en el rendimiento, ya que para leer la misma información hay que leer más páginas. Se resuelve reindexando periódicamente.

    Es algo excepcional que un índice se deba dejar con huecos. El fill factor hace que un mismo índice ocupe mucho más espacio y eso repercute igualmente en el rendimiento. Por evitar el page split no puedes partir de un estado ya menos óptimo. 

     


    Alberto López Grande (Visita mi blog en http://qwalgrande.blogspot.es/)
    • Marcado como respuesta AdyIr domingo, 13 de junio de 2010 19:25
    domingo, 13 de junio de 2010 10:28
    Moderador
  • Hola.

    Bueno, vamos con el checkpoint. Como indica la ayuda, es un comando que baja las páginas desfasadas de memoria a disco. Esta bajada se produce igual, por un proceso en segundo plano (lazy write), aunque no lo llames a mano, se va haciendo. Luego, hay otros procesos que lo ejecutan, como los backups. Sirve para tener un punto de consolidación que te asegure que toda la información está en disco. Eso facilita los restores, por ejemplo, el reciclado del log de transacciones, etc.

    Y la duda sería que por qué se hace así, porqué es un proceso asíncrono. Es una cuestión de rendimiento. Es más rápido escribir en memoria que en el disco y más cuando vas a tener que modificar varias veces la misma página en breve por estar en medio de una transacción. La página se deja en memoria y cuando ya no hay procesos que requieran la modificación, se baja la información a disco.

    Otro detalle importante. Cuando se produce el commit, tienes la certeza de que el dato está salvado, en disco. Este comando puede dejar alguna ambigüedad a ese respecto, pero no tengas dudas, cuando haces commit, en el log de transacciones ya se ha escrito que el dato ha sido cambiado.

    El otro comando es bastante más simple. Es la forma de realizar las reindexaciones de las tablas en sintaxis de SQL Server 2005 o posterior. Es lo mismo que antes hacía DBCC DBREINDEX. Si tu duda es acerca del fill factor (factor de relleno), decirte que significa que cada página se ocupa sólo en un 60%, en lugar de ocuparse por completo. Esto es útil en algún caso aislado de tablas que sufren numerosas inserciones en medio de los índices, ya que al dejar estos huecos, las inserciones se producen en ellos, lo cual evita que haya que crear una página referenciada en la secuencia (el page split, que se llama).

    Lo normal es ocupar las páginas en su totalidad. Poniendo un ejemplo, supón que tienes una tabla de usuarios, con un IDUsuario que es un entero autoincremental y un nombre. Tienes un índice, que es la clave primaria sobre este campo autoincremental. No tiene sentido dejar huecos en ese índice porque los nuevos valores son siempre mayores que todos los que hay. Pero si tienes otro índice por el nombre, ahí los nombres nuevos pueden caer en cualquier parte. Si se inserta un registro, se actualiza el índice, creándose el valor en el sitio en el que le corresponda. Si el lugar que le corresponde es una página que ya está llena, se tiene que crear una nueva página referenciada. Eso repercute en el rendimiento, ya que para leer la misma información hay que leer más páginas. Se resuelve reindexando periódicamente.

    Es algo excepcional que un índice se deba dejar con huecos. El fill factor hace que un mismo índice ocupe mucho más espacio y eso repercute igualmente en el rendimiento. Por evitar el page split no puedes partir de un estado ya menos óptimo. 

     


    Alberto López Grande (Visita mi blog en http://qwalgrande.blogspot.es/)

    Wow amigo deberias hacer un libro y te haces millonario... Todo entendido perfectamente, un millon de gracias...
    domingo, 13 de junio de 2010 19:25
  • Hola.

    Como de momento sólo escribo un blog, con tu permiso haré una entrada referenciando este hilo, ya que es más que posible que estas mismas dudas puedan surgirle a otros que se estén preparando la certificación.


    Alberto López Grande (Visita mi blog en http://qwalgrande.blogspot.es/)
    domingo, 13 de junio de 2010 19:45
    Moderador
  • Hola.

    Como de momento sólo escribo un blog, con tu permiso haré una entrada referenciando este hilo, ya que es más que posible que estas mismas dudas puedan surgirle a otros que se estén preparando la certificación.


    Alberto López Grande (Visita mi blog en http://qwalgrande.blogspot.es/)

    Con mucho gusto no tienes que pedir permiso... Esa es la idea que todos podamos aprender y ser mejores cada dia y si hay quienes pueden aprovechar esta informacion y aclarar las mismas dudas que yo tenia es bueno saberlo y de paso la informacion es tuya por quer tu fuistes el que la distes asi yo halla iniciado el tema... De nuevo gracias...
    domingo, 13 de junio de 2010 21:30