Creating index in a large table
-
Hello:
When creating a non-clustered index in a column in a large table, will the time it takes to create it be longer if the column has data? In another word, if the column contains only null, would it create an index faster?
Thanks,
Q
-
You could try this experiment yourself, but my guess is that the column with all null values would be slightly quicker.
In any case, the question you should be asking is whether you should create the index before populating the column with data. You need to consider table fragmentation (assuming it's not a heap table), in which case you should create the index after populating it with data.
-
El problema radica en la cantidad de registros que tiene tu tabla, recuerda que un indice es una relacion implicita entre la posicion del registro en la tabla y el contenido ordenado de los campos a indizar, en pocas palabras si cuentas con 100 millones de registros e indizas un campo de texto largo este va a tomar tiempo ya sea con datos o con nulos puesto que igualmente tiene que crear un registro indice por cada registro de dato (numero de registro y dato)
Otro problema que puede estar afectando tu performance es precisamente la fragmentacion de tu tabla, chequea esto mediante la sentencia apropiada dbcc indexdefrag, si el porcentaje de fragmentacion es alto entonces tienes un problema mayor y debes reindizar tus indices, para esto deberas analizar los tiempos que te puede tomar hacerlo debido a la cantidad de registros que tenga tu tabla
Resumiendo, el tiempo que te toma crear ese indice solo lo puedes mejorar si defragmentas tu tabla y la reindizas por lo menos el indice de la clave primaria el cual es un cluster, hacer eso si tu tabla es pesada te tomara buen tiempo pero ayudara a todos los procesos posteriores no solo al que estas necesitando en este momento
Saludos,
Hans Arancibia
DBA - IT Manager
BitMinds.com
(escrito a proposito en castellano, ahora te toca traducir a ti ... viva el español!)
-
-
Hi,
As far as I am concerned, creation of non-clustered index results in preparing index keys for each row(whether the particular field in that row is null or not)
It depends only on the fragmentation of the table...
-Siva Rama Krishna
-
Hola Siva,
Podriamos decir que efectivamente si el indice es no cluster solo afecta la fragmentacion de la tabla como comentas ... pero vamos un poquito mas alla, analicemos tambien los tipos de "fragmentacion" ...
Primero: Tu tabla puede estar fragmentada lo cual debes defragmentar el indice de la clave primaria que es tipo cluster, esto ordenara las paginas de tu tabla para corregir la fragmentacion pero un consejo mejor es reindizar tu tabla, el porcentaje de fragmentacion cuando reindizas baja a 0 pero cuando defragmentas llega al un nivel aceptable pero regularmente no a 0, haz la prueba y veras
Segundo: Aca va un dato de afinamiento avanzado ... recordemos que la tabla esta contenida en un dispositivo que es un archivo fisico grabado en un disco duro o arreglo de discos, si por casualidad creaste la base de datos en este disco que estuvo previamente "utilizado" por otros sistemas o simplemente como servidor de archivos y no defragmentaste "fisicamente" el disco antes de crear tus dispositivos de datos quiere decir que automaticamente has creado una base de datos defragmentada pero sus dispositivos fisicos fragmentados en el disco duro previamente usado, peor aun si tienes la base de datos en varios dispositivos en varios discos duros quiza con el mismo problema ...
Entonces tienes otro problema mayor ... vas a tener que defragmentar tu disco duro y ese tiempo puede ser considerable asi que toma tus precausiones y te recomiendo usar un defragmentador de un tercero y no el basico del sistema operativo
Les cuento un caso real en una empresa que le di consultoria, estuve trabajando con un servidor el cual la estuve revisando y dimos con el problema que necesitaba hacer tunning tanto en la defragmentacion de sus tablas como en sus indices por que estaba altamente fragmentada aparte de otros problemas ... les hice el respectivo informe y avise ... al poco tiempo el servidor se recalento a pesar de estar en un sitio refrigerado ... por que? pues la cantidad de revoluciones generadas en los cabezales de los discos por las consultas efectuadas en horas picos en las tablas altamente fragmentadas provoco un alza de temperatura tanto en los discos duros como en los procesadores (recordemos que estos administran todo al final) y al recalentarse simplemente los discos se plantaron.
Tomen esto como anectoda pero a la vez como precausion, ser DBA no es solo ver como instalar logicamente la base de datos, es tomar en cuenta el "fierro", estimar los usuarios, la carga de consultas y siempre hacer un analisis de como vamos a crear una BD, es mejor crearla con un estimado de gran tamaño dentro de un arreglo de discos limpio defragmentado por que con eso aseguramos a futuro que nuestros millones de registros viajaran en un ambiente libre de fragmentacion fisica y dependiendo de nuestros planes de mantenimiento tambien logica
Saludos,
Hans Arancibia
DBA - IT Manager
BitMinds.com
(escrito a proposito en castellano, ahora te toca traducir a ti ... viva el español!)
-
Dear Hans,
Will be pls post ur post in English we can understand what u had written in ur posts.
So, pls post in eglish.
from
Killer
-
Hi
Only in case of non clustered index
If u create the index on a null field it will be faster because SQL Server treat that column as empty(no records).
from
Killer
-
-
dear Hans
it would be gr8 if you could post your reply in english. as first of all we dont know in which language u posted your reply. pls a personal request from my side.
Regards
Ashwin Reddy
SQL Server DBA
-
Hi Hans,
If seems that Babelfish is not a perfect translator, it produced a sort of Spenglish (...mall pillows of discs...?) which certainly brightened a dull Sunday in operations
."Podriamos to say that indeed if indice is not to cluster single it affects the fragmentation of the table as you comment... but we go just a little bit but alla, we also analyze the types of "fragmentation"... First: Your table can be fragmented which you must defragmentar indice of the primary key that is type to cluster, this ordered the paginas of your table to correct the fragmentation but a better advice is to reindizar your table, the percentage of fragmentation when reindizas loss to 0 but when defragmentas arrives at an acceptable level but regularly not to 0, you test and sides Second: Aca goes a data of advanced refining... we remember that the table this contained in a device that is a fisico file recorded in a hard disk or disc adjustment, if by chance you created the data base in this disc that previously "was used" by other systems or simply as file server and not defragmentaste "fisicamente" the disc before creating your devices of data means that automaticamente you have created a defragmentada data base but its fragmented fisicos devices in the previously used hard disk, worse even if you have the data base in several devices in several hard disks quiza with the same problem... Then you have another greater problem... you are going to have to defragmentar your hard disk and that time asi can be considerable that takes your precausiones and I recommend to you to use a defragmentador of a third and not basico of the operating system Them story a real case in a company that I gave consultoria him, I was working with a servant who I was reviewing it and we gave with the problem that needed to as much do tunning in defragmentacion of its tables like in its indices so that highly it was fragmented aside from other problems... I did the respective report to them and soon after warns... to the servant recalento in spite of being in a cooled site... so that? then the amount of revolutions generated in the mall pillows of discs by the consultations conducted in rush hours in the tables highly fragmented I as much cause a rise of temperature in hard disks as in the processors (we remember that these administer everything in the end) and when overheating simply the discs stood. Take this like anectoda but simultaneously like precausion, to be DBA is not single to see as to install the data base logicamente, it is to take into account the "iron", to consider the users, the load of consultations and to always make a analisis of as we are going to create a BD, is better to create it with considering of great size within a clean disc adjustment defragmentado so that with that we assured to future that our million registries traveled in a free atmosphere of fisica fragmentation and depending on our plans of also logica maintenance"David
Si no es lo rompió, no fija...If it ain't broke, don't fix it...
-
Thanks so very much for all your advice whether they are in English, Spanish, or Spenglish!
Q
-
Hi Hans ,
Do u do the coding in the same language -: )
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply