INDICE DESCRIPTION CONCEPTOS GENERALES 2.- Recomendaciones para codificar sentencias SQL optimas. 2. .- La re!

"a #$sica es entender %&e toda sentencia SQL e'ec&tada es &n coste. ( Se tratar$ de red&cir a" m)nimo e" n*mero de e""as+. 2.2.- Las sentencias necesarias se codificar$n de "a forma m$s simp"e, 2.-.- Las sentencias imprescindi#"es se codificar$n de "a manera m$s eficiente. (Apro.ec/ando todas "as posi#i"idades de "as estr&ct&ras de )ndices+. -.- Reposicionamiento de c&rsores. DESCRIPCI0N Este documento define los estndares SQL, a considerar en la instalacin, para codificar sentencias de acceso a los datos DB2 con un buen rendimiento. Se lamenta el flaco favor que se hace a nuestra len ua hermana, por la alta densidad de palabras an losa!onas, inevitables para hacernos entender. El documento esta estructurado de la si uiente manera" El cap#tulo primero introduce una serie de conceptos enerales que facilitan la comprensin del resto. El cap#tulo se undo da recomendaciones para codificar sentencias SQL ptimas. El cap#tulo tercero comenta las t$cnicas de reposicionamiento de cursores. Conceptos !enera"es. Las sentencias SQL se componen de diferentes clusulas" Select, %here, &rder, etc. La clusula %here contiene una serie de predicados que se tipifican a continuacin se 'n diferentes clasificaciones" (.) Simples o compuestos. *n predicado compuesto es el resultado de dos predicados, simples o compuestos, enla+ados por operadores ,-D o &.. 2.) Locales o !oin. Los predicados locales referencian a una sola tabla, mientras que un predicado de !oin lo hace a ms de una tabla. /.) Boolean. *n predicado es Boolean si mediante la utili+acin de operadores l icos tipo &. 0 si uiendo las re las del l ebra de Bool, el resultado es una condicin verdadera o falsa. 1or tanto, si un predicado de este tipo es evaluado como falso para una fila, el con!unto de la clusula %here es falsa. 2.) 1or 3ipo" 2.() Subquer0. 4ualquier predicado que inclu0a otra sentencia Select. Las subqueries pueden ser correlacionadas, cuando tienen un predicado de !oin con una tabla de la Select principal, o no)correlacionadas cuando no lo presentan. Los predicados con subqueries correlacionadas son todos Sta e 2. Los no)correlacionados pueden ser inde5ables, Sta e ( o Sta e 2. 2.2.) 6 ual. 4ualquier predicado que no es del tipo subquer0, no tiene un operador -&3 0 s# tiene un operador por i ual. Se inclu0en predicados del tipo 4olumna( 6S -*LL. 2./.) .an o. 4ualquier predicado que no es del tipo Subquer0 0 tiene un operador de entre los si uientes" 7, 78, 9, 98, L6:E o BE3%EE-. 2.2.) Lista)6-. *n predicado de la forma column 6- ;lista de valores< 2.=.) -&3. 4ualquier predicado que no es del tipo Subquer0 0 que contiene un operador del tipo -&3. =.) &rden de aplicacin del predicado en la validacin de la clusula %here, que se traduce en rendimiento de los accesos si el predicado es de tipo Boolean. La secuencia que si ue se identifica con este orden de consideracin de los predicados" =.(.) >atchin . Son predicados que permiten delimitar el ran o de claves de un #ndice a procesar en la resolucin de una sentencia SQL. Se aplican, por tanto, en los niveles altos de las estructuras de #ndices. =.2.) Screenin . Son los predicados que pueden aplicarse en el nivel ms ba!o de la estructura de un #ndice. Este nivel contiene las claves 0, por tanto, se aplican sobre las columnas que la componen. Estos predicados son un subcon!unto de los Sar ables, si uiente cate or#a, pero por estar incluida la columna sobre la que se aplican en el #ndice, se resuelven con anterioridad al acceso a la fila de datos. =./.) Sar able o Sta e (. Son predicados que pueden aplicarse por el primer estor que filtra las filas resultado. Se consideran sobre las filas de datos. =.2.) -o)Sar able o Sta e 2. Son predicados que se aplican en el estor si uiente al que filtra los predicados sar ables. ?.) 6nde5able. Son los 'nicos predicados que pueden formar parte de la cate or#a >atchin . Los predicados inde5ables son dependientes de la versin del DB2. En la @=, que es la que tomamos como referencia para elaborar este documento, son los tipificados por i ual, ran o, tipo lista)6- o subquer0. En los de ran o, los predicados L6:E tienen e5cepciones no inde5ables 0 entre los de subquer0 la ma0or#a tampoco lo son. La tabla si uiente reco e las columnas que conforman las claves de tres #ndices 0 que nos servirn para codificar sentencias SQL de e!emplo, que clarifiquen las recomendaciones.

TA1LA D&>646L6& 1&S646&4L6E-3E

INDICE 1.6>E.AD&>646L6& 1,6S 361&A1&S646&- E>1.ES, 6DE-36B64,D&.

COL23NAS DE INDICE 1.&@6-46, 46*D,D 4,LLE 4E-3.& 361&A4*E-3, -*>A4*E-3, 361&AD&4*>E-3& -*>AD&4*>E-3&

El matchin en un acceso por el #ndice 1.6>E.AD&>646L6&. 3endr el valor de ( de e5istir un predicado inde5able 0 Boolean sobre la columna 1,6S en la sentencia. El matchin ser de 2, si e5iste un predicado inde5able 0 Boolean sobre la columna 1.&@6-46, 0 el e5istente sobre la columna 1,6S es por i ual. De ser este 'ltimo de tipo ran o, Lista)6- o subquer0, el matchin ser#a de (, a pesar de e5istir un predicado inde5able 0 Bolean por la se unda columna de la clave. El factor de filtro de un predicado, es un n'mero decimal de dominio CD,(E que indica el tanto por uno de las filas de una tabla, resultantes de aplicar esta condicin sobre ellas. De e5istir una distribucin uniforme entre los valores de la columna Se5o, de la tabla 4liente, un predicado por i ual sobre esta columna tendr#a un factor de filtro de D.=. El cierre transitivo de predicados, ocurre siempre que ha0 un predicado por i ual entre columnas ;4( 8 42<, bien sea local o de !oin, 0 e5iste otro predicado de i ual o ran o ;e5cepto L6:E< 0 Boolean sobre al una de las otras dos columnas ;4( BE3%EE- / ,-D =<. El DB2 enerar#a el predicado 42 BE3%EE- 2 ,-D =. 2.- Recomendaciones para codificar sentencias SQL optimas. 2. .- La re!"a #$sica es entender %&e toda sentencia SQL e'ec&tada es &n coste. ; Se tratar de reducir al m#nimo el n'mero de ellas<. Evitar sentencias Select repetitivas sobre pequeFas tablas de cdi os. &ptar por car ar la tabla en memoria 0 acceder de forma directa. Eliminar sentencias Select que resuelvan la alternativa entre reali+ar un *pdate o un 6nsert. Si el resultado ms frecuente de esta dis0untiva es actuali+ar la fila e5istente, se deber#a e!ecutar primero el *pdate 0 de ser el Sqlcode8G(DD ;no e5iste la fila<, se proceder a insertar. Si lo ms frecuente fuera insertar, se e!ecutar#a el 6nsert 0 de recibir un Sqlcode8)HD/ ;fila duplicada< se actuali+ar#a. Siempre que sea posible se reali+ar el *pdate sin lectura previa. 4uando se modifique un pro rama 0 se sustitu0a una sentencia SQL por otra, ser#a recomendable eliminar completamente la anti ua. Si se desea conservar por al 'n motivo, se comentar toda la sentencia incluido el EIE4 SQL 0 E-D)EIE4. De no hacerse, se uir#a apareciendo en el E5plain 0 los controles de la calidad del SQL anali+arn sentencias in'tiles. 2.2.- Las sentencias necesarias se codificar$n de "a forma m$s simp"e, -unca se utili+ar el SELE43 J. Las plantillas definidas en el pro rama para recibir las columnas solicitadas quedar#an invalidadas al incorporar una nueva columna a la estructura de la tabla. 1or tanto, cualquier modificacin en la definicin de una tabla desencadenar#a la precompilacin, compilacin, etc. de todos los pro ramas que la acceden, sin ser necesario. Se recuperarn las columnas necesarias en la clusula Select. La transferencia al pro rama de cada columna solicitada supone un coste de procesador. La sentencia de la derecha es un caso e5tremo de esta recomendacin. SELE43 1,6S, 46*D,D, 1&.3,L B.&> D&>646L6& %KE.E 1,6S 8 LES1,M,N ,-D 46*D,D 8 L>,D.6DN SELE43 1&.3,L B.&> D&>646L6& %KE.E 1,6S 8 LES1,M,N ,-D 46*D,D 8 L>,D.6DN Se utili+ar el operador correcto para cada condicin, sin sustituirlo por una combinacin de varios operadores. Los e!emplos de la derecha son los correctos frente a los de la i+quierda" 1,6S78 ", ,-D 1,6S 98 "B 1,6S 7 ", &. 1,6S 8 ", 1,6S -&3 8 ", 1,6S -&3 9 ", 1,6S 8 ", &. 1,6S 8 "B

1,6S BE3%EE- , ,-D B 1,6S 78 ", 1,6S 97 ", 1,6S 78 ", 1,6S 6- ;",, "B< En nin 'n caso se usar el -&3 pues el DB2 transforma primero la ne acin en su opuesta, lo que supone un asto adicional. Se usar siempre la misma lon itud de datos para la columna 0 la constante o variable con la que se compara aquella. *n predicado puede no ser inde5able de ser ma0or la lon itud de la variable que la de la columna. *tili+ando las variables proporcionadas por la sentencia 6-4L*DE se ase ura este requerimiento. 3odos los predicados codificados en la clusula %here son aplicados en e!ecucin, con el consi uiente coste de procesador. Los predicados enerados por el cierre transitivo, de ser redundantes, se considerarn en la eleccin del camino de acceso pero no sern evaluados en e!ecucin. 1or tanto, es conveniente aprovechar la funcin de cierre transitivo 0 no codificar predicados redundantes innecesarios. Las clusulas &.DE. BO, P.&*1 BO, D6S36-43, 6- con ,-O ,LL, ciertos Q&6-, *-6&- 0 *-6&- ,LL pueden causar procesos de Sort, se 'n los campos sobre los que act'e, por lo que se vi ilarn especialmente estas sentencias. -o es aconse!a el reali+ar Q&6-s sobre ms de tres tablas. Slo se utili+arn variables cuando no se trate de constantes. La sentencia de la derecha es correcta se 'n esta consideracin. El optimi+ador que planifica el camino de acceso lo hace con ms e5actitud de conocer el valor e5acto de la columna. SELE43 1&.3,L B.&> D&>646L6& %KE.E 1,6S 8 LES1,M,N ,-D 46*D,D 8 L>,D.6DN ,-D 4,LLE 8 LP&O,N SELE43 1&.3,L B.&> D&>646L6& %KE.E 1,6S 8 "1,6S ,-D 46*D,D 8 "46*D,D ,-D 4,LLE 8 "4,LLE ) 4uando se quiera comprobar la e5istencia o no de al una fila que cumpla una condicin, se debe e!ecutar una Select directa 0 controlar el Sqlcode ;GD, e5iste la filaR )H((, e5isten m'ltiples filasR G(DD, no e5isten filas<. &tra t$cnica, de menor rendimiento, es indicar al optimi+ador que planifique un camino de acceso para recuperar una 'nica fila, mediante la clusula &136>6SE B&. ( .&%. La t$cnica ms desfavorable es contar el n'mero de filas que cumplen la condicin. Los e!emplos si uientes muestran estas dos 'ltimas t$cnicas. SELE43 4&*-3;J< B.&> 1&S646&%KE.E E>1.ES, 8 LDDT=N ,-D 4E-3.& 8 NDD(DN ,-D 361&43, 8 L=DN DE4L,.E 4*.S&. 4( B&. SELE43 -*>A4*E-3, B.&> 1&S646&%KE.E E>1.ES, 8 LDDT=N ,-D 4E-3.& 8 NDD(DN ,-D 361&43, 8 L=DN &136>6SE B&. ( .&% -o es conveniente el aFadir condiciones del tipo 4olumna 7 LN o bien 4olumna 7 D, con constante o variable, porque no filtran nin una fila 0 car an el procesador. 2.-.- Las sentencias imprescindi#"es se codificar$n de "a manera m$s eficiente. (Apro.ec/ando todas "as posi#i"idades de "as estr&ct&ras de )ndices+. El matchin en accesos por #ndice se tratar de ma5imi+ar. La sentencia de la derecha es correcta aunque introduce dos predicados obvios, desde el punto de vista l ico, pero me!ora el matchin de D a 2. La ciudad de >adrid se encuentra en la divisin administrativa o provincia de >adrid, que es la capital de EspaFa..

SELE43 1&.3,L B.&> D&>646L6& %KE.E 46*D,D 8 L>,D.6DN ,-D 4,LLE 8 LP&O,N SELE43 1&.3,L B.&> D&>646L6& %KE.E 1,6S 8 LES1,M,N ,-D 1.&@6-46, 8 L>,D.6DN ,-D 46*D,D 8 L>,D.6DN ,-D 4,LLE 8 LP&O,N El predicado de ran o L6:E es inde5able, siempre que la constante no comience por LUN o N AN. De no venir estas mscaras se uidas de al 'n otro carcter ;LUabcN<, estos predicados no filtran nin una fila 0 car an el procesador. -unca se usar la concatenacin ;VV o 4&-4,3< entre campos que formen parte del #ndice, pues los predicados no sern del tipo 6nde5ables o Screenin . SELE43 -*>A4*E-3,, S,LD& B.&> 1&S646&%KE.E E>1.ES,VV4E-3.& 4&-4,3 361&A4*E-3, 8 LDDT=DD(D=DN SELE43 -*>A4*E-3,, S,LD& B.&> 1&S646&%KE.E E>1.ES, 8 LDDT=N ,-D 4E-3.& 8 LDD(DN ,-D 361&A4*E-3, 8 L=DN -o se usar la funcin S*BS3. sobre una columna de #ndice como operando, en una clusula %here, porque el predicado no ser 6nde5able, ni Screenin . El List prefetch, hasta la pr5ima versin del producto, modifica la cate or#a de los predicados de Screenin en Sar ables, que se aplican en datos. El DB2 no usar el #ndice cuando e5istan e5presiones aritm$ticas como operandos de comparacin en clusulas %here. SELE43 ,1ELL6D&, ED,D B.&> 4L6E-3E %KE.E S,L,.6& 7 "S,L G TDDD En el cap#tulo anterior se coment que la secuencia de aplicacin de predicados es" >atchin , Screenin , Sta e ( 0 Sta e 2. Las re las enerales en relacin con la evaluacin de predicados son" cuanto antes sean evaluados los predicados me!or ;la situacin idnea ser#a que todos fueran inde5ables< 0 el escribir los ms restrictivos primero. , continuacin se e5plica el como hacerlo, con ms detalle. En cada una de estas cate or#as se pueden definir subcate or#as respecto a la aplicacin de predicados" primero se aplican los predicados por i ual, a continuacin los de ran o 0 los de la foma 6S -&3 -*LL 0 finalmente el resto. Si e5ceptuamos la cate oria >atchin , el orden de codificacin de los predicados Boolean para cada subcate or#a en la clusula %here, condiciona el orden de aplicacin de los mismos en e!ecucin. 1or tanto en cada subcate or#a los predicados se deber#an codificar en la secuencia que se corresponda con el radiente ascendente de su factor de filtro. Sean tres predicados Boolean, en la cate or#a Screenin 0 subcate or#a 6 ual, con factores de filtro D.(, D.= 0 D.W. De codificarse en este orden 0 aplicarse sobre una tabla de (DDD filas, el resultado ser de 2= filas, pero los predicados aplicados sern de (DDD G (DD G =D. De codificarse en orden inverso, las filas resultado se uirn siendo 2=, pero los predicados aplicados sern" (DDD G WDD G 2=D. En ocasiones las subqueries pueden codificarse como correlacionadas o no)correlacionadas. De forma eneral" (.) Si ha0 #ndices eficientes en las tablas de la subquer0, codificarla como correlacionada. 2.) Si no los ha0, codificarla como no)correlacionada. El DB2 siempre aplica antes los predicados de subqueries no)correlacionadas que los de correlacionadas. Las queries no)correlacionadas pueden incluirse en cualquiera de las cuatro cate or#as mencionadas, mientras que las correlacionadas son todas Sta e 2. La ubicacin de las subqueries en la clusula %here debe considerarse dentro de la subcate or#a de aplicacin en que les corresponda. En el caso de las subqueries el criterio del factor de filtro viene mati+ado por el rendimiento de su acceso, que puede aconse!ar al una correccin de esta secuencia.

El DB2 no utili+ar de forma adecuada los #ndices cuando se realicen sentencias 6- ;subselect< 0 adems ordena el resultado de la subquer0R en estos casos se deber usar un Q&6- como muestra el e!emplo. 6 ual que este predicado 6-, se comportan" -&3 6-, 8 ,-O, 97 ,-O, 8 ,LL 0 97 ,LL. SELE43 ,1ELL6D&, 3ELEB&-& B.&> 1&S646&%KE.E E>1.ES, 8 LDDT=N ,-D 4E-3.& 6;SELE43 46*D,D B.&> D&>646L6&< SELE43 ,1ELL6D&, 3ELEB&-& B.&> 1&S646&-, D&>646L6& %KE.E E>1.ES, 8 LDDT=N ,-D 4E-3.& 8 46*D,D El uso de &.DE. BO por las columnas del #ndice puede ser un factor decisivo para que el DB2 use el #ndice en cuestin, pues as# se evitar#a el proceso de Sort posterior. Sin embar o, slo se debe especificar el &.DE. BO cuando realmente se desee el resultado en ese orden, 0 nunca para for+ar al DB2 a que entre por un #ndice. ,dems se debe ordenar por todos los campos del #ndice, o un subcon!unto de las 5 primeras columnas de la clave, 0 que no ha0an sido especificados con un predicado por i ual en el %here. SELE43 1&.3,L B.&> D&>646L6& %KE.E 1,6S 8 LES1,M,N ,-D 1.&@6-46, 8 L>,D.6DN &.DE. BO 46*D,D, 1.&@6-46, ) Ka0 un con!unto de t$cnicas que permiten influir en el camino de acceso a los datos, a costa de procesador en la e!ecucin. El DB2 en su pr5ima versin incorpora una facilidad que permite indicar, e5pl#citamente, el camino de acceso para una sentencia, sin sobrecoste. 1or tanto, de necesitarse el encaminar un acceso se aconse!a solicitar un soporte de superior nivel para evitar el enterrar SQL no eficiente. En los cursores B&. *1D,3E &B se definirn e5clusivamente, las columnas potencialmente actuali+ables, porque estas columnas pueden condicionar el camino de acceso ele ido, para prevenir el entrar en un LloopN en la e!ecucin. -.- Reposicionamiento de c&rsores. 3odos los pro ramas con cursores que tomen puntos de sincronismo, deben codificar la clusula %63K K&LD para evitar que sean cerrados en el 4&>>63, con el consi uiente incremento de rendimiento. DE4L,.E nombre)del)cursor 4*.S&. %63K K&LD B&. sentencia)SQL Los pro ramas batch deben incorporar una estrate ia de rearranque, ante ca#das inesperadas, que permitan no iniciar los procesos desde el principio. Los pro ramas del teleproceso pueden solicitar la continuacin de la informacin visuali+ada por una transaccin, mediante la e!ecucin de otra transaccin que se posicione tras la 'ltima fila mostrada. El reposicionamiento, en ambos casos, debe planificarse mediante un #ndice 'nico que identifique la si uiente fila a visuali+ar. 3$cnicas de reposicionamiento a partir de predicados compuestos enla+ados por &., desencadenan accesos por m'ltiples #ndices. Estos caminos suponen el considerar todas las claves resultantes de aplicar la clusula %here ;con las limitaciones 0a comentadas del Screenin < antes de acceder a la primera fila de los datos. DE4L,.E ,L3,6. 4*.S&. B&. SELE43 1&.3,L, 16S&, 1*E.3, B.&> D&>646L6& %KE.E 1,6S 7 "K@( &. ;1,6S 8 "K@( ,-D 1.&@6-46, 7 "K@2< &. ;1,6S 8 "K@( ,-D 1.&@6-46, 8 "K@2 ,-D 46*D,D 7 "K@/< &. ;1,6S 8 "K@( ,-D 1.&@6-46, 8 "K@2 ,-D 46*D,D 8 "K@/ ,-D 4,LLE 7 "K@2< 1ara corre ir estos accesos se proponen las si uientes t$cnicas"

(.) *tili+ando la clusula &. 0 un predicado adicional" DE4L,.E ,L3,6. 4*.S&. B&. SELE43 1&.3,L, 16S&, 1*E.3, B.&> D&>646L6& %KE.E 1,6S 78 "K@( ,-D ; 1,6S 7 "K@( &. ;1,6S 8 "K@( ,-D 1.&@6-46, 7 "K@2< &. ;1,6S 8 "K@( ,-D 1.&@6-46, 8 "K@2 ,-D 46*D,D 7 "K@/< &. ;1,6S 8 "K@( ,-D 1.&@6-46, 8 "K@2 ,-D 46*D,D 8 "K@/ ,-D 4,LLE 7 "K@2<< En ocasiones esta t$cnica no resuelve el acceso por m'ltiples #ndices, en funcin de la cardinalidad de la primera columna de la clave. 2.) *tili+ando la clusula ,-D -&3" DE4L,.E ,L3,6. 4*.S&. B&. SELE43 1&.3,L, 16S&, 1*E.3, B.&> D&>646L6& %KE.E 1,6S 78 "K@( ,-D -&3 ;1,6S 8 "K@( ,-D 1.&@6-46, 98 "K@2< ,-D -&3 ;1,6S 8 "K@( ,-D 1.&@6-46, 8 "K@2 ,-D 46*D,D 98 "K@/< ,-D -&3 ;1,6S 8 "K@( ,-D 1.&@6-46, 8 "K@2 ,-D 46*D,D 8 "K@/ ,-D 4,LLE 98 "K@2<< El predicado -&3 no es inde5able 0, por tanto, ase ura el abandono de la t$cnica por m'ltiple #ndice. Se recomienda que la primera columna de las claves sea la de ma0or cardinalidad, de forma que los reposicionamientos que presentan una 'nica columna de matchin sean lo ms pro5imos a la 'ltima clave 0a tratada. /.) *tili+ando varios cursores. El e!emplo muestra el encadenamiento de cursores. Esta t$cnica aunque sea la ms costosa de codificar es posiblemente la de me!or rendimiento, especialmente en claves de reposicionamiento con ba!a cardinalidad en su primera columna. DE4L,.E ,L3,6.( 4*.S&. B&. SELE43 1&.3,L, 16S&, 1*E.3, B.&> D&>646L6& %KE.E 1,6S 8 "K@( ,-D 1.&@6-46, 8 "K@2 ,-D 46*D,D 8 "K@/ ,-D 4,LLE 7 "K@2 %KE- SQL4&DE 8 G(DD DE4L,.E ,L3,6.2 4*.S&. B&. SELE43 1&.3,L, 16S&, 1*E.3, B.&> D&>646L6& %KE.E 1,6S 8 "K@( ,-D 1.&@6-46, 8 "K@2 ,-D 46*D,D 7 "K@/ %KE- SQL4&DE 8 G(DD DE4L,.E ,L3,6./ 4*.S&. B&. SELE43 1&.3,L, 16S&, 1*E.3, B.&> D&>646L6& %KE.E 1,6S 8 "K@( ,-D 1.&@6-46, 7 "K@2 %KE- SQL4&DE 8 G(DD

DE4L,.E ,L3,6.2 4*.S&. B&. SELE43 1&.3,L, 16S&, 1*E.3, B.&> D&>646L6& %KE.E 1,6S 7 "K@( 4.- G"osario de acciones a considerar en "a correcci5n de incidencias de ca"idad6 en e" SQL de" te"eproceso. Se describen las acciones a considerar por Desarrollo, en la resolucin de las incidencias de calidad detectadas por el paso 4,L6D,D, del procedimiento de preparacin de pro ramas DB2 para e!ecucin, en la cate or#a de X4orre ir o QustificarX. El informe que se enera en el paso 4,L6D,D se compone de varias reas. En la primera se formatea el camino de acceso de las sentencias SQL, con incidencias de calidad, 0 se seFalan $stas. En este cap#tulo del documento las referencias a LcamposN deben relacionarse con los presentes en el formato de este primer rea del informe. De no ser aplicable nin una de las alternativas, que se proponen a continuacin, se puede pedir soporte al rea de datos, contribu0endo al enriquecimiento de este losario. De no ser me!orable, se Qustificar la necesidad del camino de acceso en una base de datos -otes, que el rea de datos preparar para cada aplicacin. Esta base de datos presentar un documento por pro rama e incidencia a Qustificar, e5istente en el momento de su eneracin. 1or tanto, ser#a conveniente solicitar su creacin al presentar las incidencias a !ustificar una cierta solide+. Siete son los tipos de incidencias a me!orar por Desarrollo, a rupadas en" 6nformativas ;LoY 6I Scan 0 >atchin < 0 a Qustificar ;6I Scan, 3S Scan, Sort, 1refetch 0 >ultiple 6I<. Las informativas son aquellas que no deben ser documentadas en la base de datos -otes. Las a Qustificar, por el contrario, si lo sern. 4. +.- IN7OR3ATI8AS, 4. . +.- 3ATC9ING, ,ccesos por #ndice en que se estima se tratarn ms de =D filas de datos. La estimacin de filas esperadas aparece reco ida en el campo >uestra. De aconse!arse, a continuacin, la me!ora del acceso, debe tratarse de aumentar el matchin en el #ndice o revisar los requerimientos del usuario, considerando su planificacin batch. La casu#stica posible es diversa 0, por tanto, a valorar por Desarrollo" G 4ursor que pretende visuali+ar las primeras filas de la tabla resultado 0 que no se materiali+a en un fichero, como consecuencia de un proceso de clasificacin ;que supondr#a una incidencia del tipo Sort<. Dos casos son posibles" ,cceso mediante #ndice cluster. ,dmisible. ,cceso mediante #ndice secundario o no cluster. >e!orar el acceso. G Select directa que e!ecuta una funcin de columna ;valor L.N en el campo 4&AB-AE@<. Dos casos posibles" ,cceso mediante #ndice cluster. >e!orar el acceso para un tamaFo del campo >uestra de ms de =DD filas. ,cceso mediante #ndice secundario. >e!orar el acceso. 4. .2+.- LO: I; SCAN, ,cceso por clave, con o sin acceso a datos, que evita el matchin en la estructura de #ndice, sobre tablas de pequeFo tamaFo. Debe revisarse la posibilidad de me!orar el matchin . 4.2+.- <2STI7ICAR, 4.2. +.- TS SCAN, ,cceso directo a datos que planifica operaciones de lectura masivas en memoria. Debe me!orarse el acceso" definiendo un #ndice ;valorando la sobrecar a que en los accesos de modificacin a esta tabla puede suponer< o revisando los requerimientos del usuario, considerando su planificacin batch. 4.2.2+.- I; SCAN, ,cceso por clave, con o sin acceso a datos, que evita el matchin en la estructura de #ndice. >e!orar el acceso" comprobando la e5istencia de los predicados, de tipo matchin , sobre el #ndice por el que se accede. La e5istencia del valor LSN en el campo 1., apunta al tratamiento de un volumen considerable de filas resultado, que debe me!orarse. De accederse a datos ;campo 6& con valor L-N<, mediante #ndice secundario o no cluster, considerar" 4ursor que lee una parte m#nima de filas ;(D< de su tabla l ica resultado ;0 no se materiali+a $sta<. ,dmisible. De no ser as#, corre ir. Select directa que e!ecuta una funcin de columna, sobre ms de (D filas. Debe me!orarse. Si la columna 1. no presenta valor 0 el matchin no puede me!orarse, documentar la incidencia. 4.2.-+.- PRE7ETC9, ,cceso por clave a datos que planifica operaciones de lectura masivas en memoria sobre la estructura de datos, de #ndices o en ambas. Se propone" me!orar el matchin o revisar los requerimientos de usuario, considerando su planificacin batch. La e5istencia en el campo 1., del valor ZSZ, obli a a me!orar el acceso. La e5istencia en el campo 1. del valor ZLZ, en una sentencia de lectura, puede tener su ori en en la ba!a clusteri+acin del #ndice por el que se accede. >e!orar el acceso. 4.2.4+.- SORT, &peracin de clasificacin de datos motivada por una clusula &rder b0 ;campos S-A&. o S4A&. a ZOZ<, Proup b0 ;campos S-AP. o S4AP. a ZOZ< 0 Select Distinct o *nion ;campos S-A*- o S4A*- a ZOZ<.

En las sentencias con &rder b0 o Proup b0, revisar la codificacin de las columnas en estas clusulas, 0 ase urar que su orden 0 secuencia ;ascendente o descendente< coinciden con la de la clave de acceso. En la liber#a DES.DB-,>E.6-DEI e5iste un miembro por base de datos, de actuali+acin diaria, en que se puede consultar la definicin de los #ndices. De no e5istir al una base de datos en la librer#a, notificarlo al rea de datos para su planificacin. .evisar los requerimientos del usuario. 4.2.=+.-32LTIPLE I;, ,cceso a datos por varios #ndices, que planifica operaciones de lectura masivas en memoria. De comprobarse un acceso m'ltiple por un mismo #ndice ;campo ,ccessna del formato<, se relacionara con t$cnicas de reposicionamiento de cursores. .evisar el cap#tulo tercero de los XEstndares SQLX en la intranet 0 valorar su oportunidad. De forma eneral, de presentar la primera columna de la clave pocos valores distintos 0, por tanto, presentes cada uno de ellos en muchas filas de datos, el acceso no ser ptimo ;mediante >ultiple 6I< 0 debe me!orarse. De ser el acceso m'ltiple por #ndices diferentes, me!orar el matchin del mas eficiente. &tra t$cnica utili+ada, es la de codificar una clusula &rder b0 por la clave que se pretende potenciar.