Un par de pequeños problemas con las muestras de Hekaton

Algunos de ustedes tienen acceso a Hekaton publicado Scripts de demostración In-Memory OLTP relacionados con AdventureWorks; la muestra más reciente se publica aquí. Estos ejemplos se complementan con la base de datos de muestra AdventureWorks2012 en CodePlex. Si probó estas muestras, es posible que haya encontrado un par de problemas que pueden cambiar drásticamente su primera experiencia con esta tecnología.

Autorización de la base de datos

Mucha gente descarga el "Archivo de datos de AdventureWorks2012", un archivo .mdf de 200 MB que puede adjuntar, sin un registro, usando la siguiente sintaxis:

CREATE DATABASE AdventureWorks2012 ON
(
  NAME = AdventureWorks2012_Data, FILENAME = '<path>\AdventureWorks2012_Data.mdf'
)
FOR ATTACH_REBUILD_LOG;

El problema es que, si está conectado a la instancia de SQL Server como su cuenta de Windows, puede terminar siendo el propietario de la base de datos sin darse cuenta. Lo cual no va a ser un gran problema en la mayoría de los escenarios, excepto que si crea procedimientos almacenados con EXECUTE AS OWNER , como muchas muestras con las que te encuentras, esto puede causar un problema. Puede encontrar esta línea, por ejemplo, en muchos procedimientos almacenados compilados de forma nativa:

WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER

A menos que ya haya mitigado este problema de otras maneras, si el propietario de la base de datos es su cuenta de Windows, es probable que obtenga el siguiente error al intentar crear dicho procedimiento:

Dependiendo de su entorno, es posible que desee sopesar seriamente cómo lidiar con esto; en mi caso, tomé el camino fácil y simplemente configuré la autorización en la base de datos para sa :

ALTER AUTHORIZATION ON DATABASE::AdventureWorks2012 TO sa;

En este punto, pude ejecutar el script de demostración sin problemas (bueno, tuve errores cuando intenté agregar otro grupo de archivos optimizado para memoria, pero ese es un problema completamente diferente e ignorable).

Número de cubos

No parece haber mucha orientación práctica sobre cómo elegir el recuento de cubos para sus tablas optimizadas para memoria. Hay este artículo en MSDN, que entra en algunos detalles técnicos, y Klaus Aschenbrenner ha escrito esta publicación sobre cómo tomar decisiones inteligentes en esta área. Fuera de eso, estás prácticamente solo para experimentar. El SWAG que he escuchado con mayor frecuencia es 1x-2x el número de valores clave únicos, por lo que las búsquedas de puntos son más eficientes. Sin embargo, algunas de las muestras que encontrará allí usan consistentemente 1,000,000 cubos, o números más pequeños como 100 (e incluso 5 en un caso), o una combinación. Tenga esto en cuenta a medida que comience a experimentar con su propio esquema y patrones de acceso a datos:es posible que deba desglosar las tablas e intentar nuevamente con diferentes tamaños de depósito para encontrar el "punto ideal" para su escenario.

Modelo de recuperación

La base de datos AdventureWorks2012 está establecida en SIMPLE recuperación. Al igual que el problema del propietario de la base de datos, en la mayoría de los casos esto no es tan importante para una base de datos de muestra. Pero cuando está probando In-Memory OLTP, y probablemente en combinación con otras tecnologías que hacen que SIMPLE la recuperación es un factor decisivo, como los grupos de disponibilidad:puede tener mucho más sentido realizar las pruebas en una base de datos con la recuperación configurada en FULL . De lo contrario, es posible que no observe ciertos comportamientos que podrían ser diferentes en diferentes modelos de recuperación. Puede cambiar AdventureWorks2012 a FULL de la siguiente manera:

ALTER DATABASE AdventureWorks2012 SET RECOVERY FULL;

Y no olvide realizar una copia de seguridad completa, de modo que se establezca una cadena de copia de seguridad y la base de datos no funcione en pseudo-SIMPLE modo de recuperación.