Análisis XML lento

Actualmente estoy tratando de ajustar un procedimiento almacenado algo problemático y he notado que la mayoría del costo asociado con la ejecución proviene del análisis de algunos XML en una tabla temporal. Aquí está el SQL en cuestión:

CREATE TABLE #ChangeSet 
(
    RemarkTypeID TINYINT NOT NULL PRIMARY KEY,
    RemarkText VARCHAR(2500) NOT NULL,
    ListingID INT NOT NULL
)
INSERT INTO #ChangeSet
    (RemarkTypeID, 
    RemarkText,
    ListingID)
SELECT
    T.c.value('@RemarkTypeID[1]','tinyint') AS RemarkTypeID,
    T.c.value('@RemarkText[1]','varchar(2500)') AS RemarkText,
    @ListingID
FROM @RemarksXml.nodes('/Remarks[1]/Remark') AS T(c)

Además, tiene una idea de la estructura del XML que se analiza:

  <Remarks>
    <Remark xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" RemarkID="211767" DateTimeCreated="1991-11-19T10:43:50" DateTimeModified="1992-01-01T10:43:50" RemarkTypeID="8" RemarkText="aaaWasher,Dryer,Refriger,Microwav" />
    <Remark xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" RemarkID="211768" DateTimeCreated="1991-11-19T10:43:50" DateTimeModified="1992-01-01T10:43:50" RemarkTypeID="3" RemarkText="aaaell Maintained 3Bd 1.5Ba Semi-Detached Home In Cambridge Gardens. Garage W As Converted Into A Nice Family Room The Outside Is Maintence Free. Includes All Appliances,Security System,Storage Shed,Ceiling Fans And New Carpet.This Home Is Very Well Pricded. Seller Will Consider Fha Or Va Along With Conventional Finacing. This Is A Great Buy." />
 </Remarks>

¿Hay algo que pueda hacer para mejorar el rendimiento de analizar estos nodos XML y configurar esta tabla temporal?

Podrías intentarlo OPENXML. Ahora, normalmente no lo recomiendo, OPENXMLya que tiene una serie de problemas de memoria bien conocidos (básicamente, puede tomar 1/8 de su grupo de búferes dependiendo del tamaño de XML) (¡¡¡¡¡¡TODO agregue el enlace). Sin embargo, según la leyenda, es más rápido para piezas más grandes de XML, por lo que vale la pena intentarlo en un entorno de desarrollo / prueba y si conoce los problemas de memoria y obtiene el rendimiento, depende de usted decidir cuál necesita más. Algo como esto:

DECLARE @handle INT

EXEC sp_xml_preparedocument @handle OUTPUT, @RemarksXml

INSERT INTO #ChangeSet
SELECT RemarkTypeID, RemarkText, @ListingID
FROM OPENXML( @handle, '/Remarks[1]/Remark', 1 ) 
WITH ( 
    RemarkTypeID    TINYINT,
    RemarkText      VARCHAR(2500)
    )

EXEC sp_xml_removedocument @handle

Recuerda llamar siempre sp_xml_removedocument. Supongo que su XML real es mucho más grande, ¿puede darnos una idea de cuántos Remarkelementos tendrá y cuál es el tamaño en KB / MB? Volveré a la publicación más tarde y configuraré una plataforma de prueba para comparar el rendimiento en función de sus estadísticas.

ACTUALIZACIÓN: de acuerdo con su secuencia de comandos de ejemplo, su XML solo puede tener un máximo de 256 Remarkelementos con una longitud máxima de 2500. Una vez creado un XML de muestra para cumplir con estos criterios y probado, hay poco rendimiento entre las dos técnicas, y ambas terminar en sub-segundo. En este caso, elegiría el tipo de datos XML y los métodos. ¿Puede proporcionar la otra información solicitada por favor?

Hay dos cosas principales que puede hacer para mejorar el rendimiento del análisis XML:

• Haga que la columna / variable xml se escriba , lo que significa declarar un esquema xsd en ella. Esto forzará una validación del xml, que en sí mismo tomará un poco de tiempo, pero la velocidad de análisis mejorará.
• Indice una columna xml (no se aplica a las variables xml). Puede indexar columnas xml de diferentes maneras, según sus requisitos. Esto puede brindarle excelentes ganancias de rendimiento para consultas y búsquedas más complejas en blobs xml.
• Si su consulta es parte de una consulta mucho más grande, me parece recordar que las operaciones xml no son paralelas, por lo que puede hacer una sabia separación y hacer el análisis xml en una consulta separada del resto del trabajo.