Pregunta

Así que me estoy construyendo un elemento web que enumera todos los doclibs en la web actual, el acaparamiento de todos los archivos protegidos y listado de ellos en una tabla, lo que permite a un usuario para aplicar algunos de los metadatos necesarios y comprobar en muchos a la vez (50).

Este webpart debe operar en las listas de la lista umbral de la vista (que actualmente está fijado en 15.000 en la producción), y también en los sitios que son MUY grandes (50,000 - 100,000+ documentos).

Estoy siguiendo la MS de las Mejores prácticas para el manejo de grandes listas de aquí: http://msdn.microsoft.com/en-us/library/ee557257.aspx

El uso de un SPquery (sin CAML se define en absoluto), la recuperación de las páginas de 2.000 artículos y análisis de esa manera.El problema con esto es, que el webpart es, de hecho, provocando un tiempo de espera que se producen en los muy grandes (50k+) de los sitios.Así que estoy tratando de ser un poco más inteligente con mi CAML, tirando sólo de los elementos que están desprotegidos:

spQuery.Query = "<Where><IsNotNull>
    <FieldRef Name=\"CheckoutUser\" LookupId=\"TRUE\"/>
</IsNotNull></Where>";
spQuery.RowLimit = 2000;
spQuery.ViewAttributes = "Scope=\"Recursive\"";

Estoy usando un CrossListQueryInfo consulta a consulta toda la web con este mismo caml, y funciona de maravilla cuando la lista no es más que el LVT.Si uno es, me atrapa la excepción, y volver a intentar con el 'lento' SPQuery en cada biblioteca.

De todo lo que estoy leyendo, mientras mi CAML está volviendo menos elementos que el LVT, se debe trabajar.Pero el uso de la CAML por encima de causa el error The attempted operation is prohibited because it exceeds the list view threshold enforced by the administrator se produce cuando SPList.GetItems(spQuery) se llama.Desde que estoy siendo un rowlimit de 2.000, no debería suceder nunca?MS Sugiere para ejecutar un SPQuery sin CAML se define en absoluto - básicamente, el acaparamiento de todos los elementos de la biblioteca en las páginas de 2.000.Así que no puedo hacer ninguna idea de por qué mi CAML está fallando sólo en las listas de sobre el umbral de la vista.

Editar:Más allá de la investigación, estoy intentando utilizar el ContentIterator clase para satisfacer mis necesidades (http://msdn.microsoft.com/en-us/library/microsoft.office.server.utilities.contentiterator.aspx).Usando ejemplos de este post: http://extreme-sharepoint.com/2012/07/17/data-access-via-caml-queries/

Todavía estoy fallando en la contentiterator con el mismo LVT error.

¿El CheckoutUser' campo tiene que ser indexado en cada lista que desea ejecutar esta consulta en contra?

Actualización 2:Este viene a ser el 'CheckoutUser' el campo no está indexado, y tratando de consulta en contra de ella.Por desgracia, no es una opción para nosotros para salir y fuerza de este índice en cada biblioteca de la granja.Creo que mi única opción en este momento es implementar algún tipo de esquema de paginación en sitios muy grandes elementos de proceso en lotes.

Última Actualización:Como una solución, me he decidido a hacer cumplir la indexación de los 'CheckoutUser' columna para las bibliotecas.Esto debería mejorar enormemente el rendimiento general de la webpart, y permitir que el soporte para sitios muy grandes.Habrá un poco de dolor de cabeza inmediatamente después de la implementación, ya que necesitaremos para configurar manualmente la columna de índice de la lista a lo largo de la lista umbral de la vista, pero esto a la larga será lo mejor.

¿Fue útil?

Solución

Mi comprensión de cómo el Umbral de la Vista Lista de obras es limitado, sin embargo, sospecho que el motivo de su consulta CAML está fallando es porque es filtrado en el campo no indizado, y el RowLimit se aplica el "después".

Creo que la indexación de los CheckoutUser campo de resolver su problema, sin embargo parece que usted tiene un montón de sitios.

Permítanme sugerir un enfoque alternativo de paginación.Desde la columna de ID en cada lista está indexado, implementar una consulta CAML donde es filtrado PRIMERA (muy importante) en la columna de ID de menos de, digamos, 2000, y en segundo lugar en la CheckoutUser campo.Si la consulta no devuelve el número deseado de resultados, a continuación, aumentar el 2000 a 4000 y repetir.

No he implementado esta solución mí, es solo un pensamiento.

Otros consejos

Si usted está consultando las listas de gran tamaño, que sin duda debe indexar los campos en los que se está consultando.La limitación de no producirse porque los campos indizados se almacenan en una tabla separada en la base de datos.

Esta entrada del blog de la mina debe ser de alguna ayuda, creo:http://vrdmn.blogspot.in/2012/11/sharepoint-list-indexes-under-hood.html

Licenciado bajo: CC-BY-SA con atribución
scroll top