Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Describe cómo funcionan FileTables con otras características de SQL Server.
Grupos de disponibilidad AlwaysOn y FileTables
Cuando la base de datos que contiene datos FILESTREAM o FileTable pertenece a un grupo de disponibilidad AlwaysOn:
Los grupos de disponibilidad AlwaysOn admiten parcialmente la funcionalidad de FileTable. Después de una conmutación por error, los datos de FileTable son accesibles en la réplica principal, pero los datos de FileTable no son accesibles en réplicas secundarias legibles.
Nota:
Observe que después de una conmutación por error, toda la funcionalidad de FILESTREAM está disponible. Los datos FILESTREAM son accesibles tanto en réplicas secundarias legibles como en la nueva principal.
Las funciones FILESTREAM y FileTable aceptan o devuelven nombres de red virtual (VNN) en lugar de nombres de equipo. Para obtener más información sobre estas funciones, vea Filestream y FileTable Functions (Transact-SQL).
Todo acceso a los datos de FILESTREAM o FileTable a través de las API del sistema de archivos debe utilizar VNN en lugar de nombres de equipo. Para obtener más información, vea FILESTREAM y FileTable con grupos de disponibilidad AlwaysOn (SQL Server).
Creación de particiones y FileTables
La creación de particiones no se admite en FileTables. Con la compatibilidad con varios grupos de archivos FILESTREAM, se pueden controlar problemas de escalado vertical puro sin tener que recurrir a la creación de particiones en la mayoría de los escenarios (a diferencia de SQL 2008 FILESTREAMs).
Replicación y FileTables
La replicación y las características relacionadas (incluida la replicación transaccional, la replicación de mezcla, la captura de datos modificados y el seguimiento de cambios) no se admiten con FileTables.
Semántica de transacciones y FileTables
Aplicaciones de Windows
Las aplicaciones de Windows no comprenden las transacciones de base de datos, por lo que las operaciones de escritura de Windows no proporcionan las propiedades ACID de una transacción de base de datos. Por lo tanto, las anulaciones transaccionales y la recuperación no son posibles con las operaciones de actualización de Windows.
aplicacionesTransact-SQL
Para las aplicaciones TSQL que trabajan en la columna FILESTREAM (file_stream) de una FileTable, la semántica de aislamiento es la misma que con el tipo de datos FILESTREAM en una tabla de usuario normal.
Notificaciones de consulta y FileTables
La consulta no puede contener referencia a la columna FILESTREAM de FileTable, en la cláusula WHERE ni en ninguna otra parte de la consulta.
SELECT INTO y FileTables
Las instrucciones SELECT INTO de una FileTable no propagarán la semántica de FileTable en la tabla de destino creada (al igual que las columnas FILESTREAM de una tabla normal). Todas las columnas de la tabla de destino se comportarán igual que las columnas normales. No tendrán ninguna semántica de FileTable asociada.
Desencadenadores y FileTables
Desencadenadores DDL (lenguaje de definición de datos)
No hay consideraciones especiales para los desencadenadores DDL con FileTables. Los desencadenadores DDL normales se activarán para las operaciones de creación o modificación de bases de datos, así como para las operaciones CREATE/ALTER TABLE para FileTables. Los desencadenadores pueden recuperar los datos de eventos reales que incluyen el texto del comando DDL y otra información llamando a la función EVENTDATA(). No hay nuevos eventos ni cambios en el esquema Eventdata existente.
Desencadenadores DML (lenguaje de manipulación de datos)
Estas restricciones se aplicarán durante la operación DDL para crear desencadenadores.
FileTables no admitirán desencadenadores INSTEAD OF para las operaciones DML. Se trata de una restricción existente en todas las tablas que contienen columnas FILESTREAM.
FileTables admitirá desencadenadores AFTER para operaciones DML.
Los desencadenadores definidos en una FileTable no pueden actualizar ninguna FileTable (incluido el FileTable primario). Esta restricción existe principalmente para evitar que un desencadenador entre en conflicto con los bloqueos mantenidos por el acceso del sistema de archivos en la misma transacción.
Acceso no transaccional y sus efectos en desencadenadores
Cuando se permite el acceso a actualizaciones no transaccionales en una base de datos, es posible realizar la actualización local de los datos FILESTREAM en cualquier tabla, incluida FileTable en esa base de datos. Debido a esta posibilidad, es posible que la imagen anterior del contenido de FILESTREAM no esté disponible para su uso por parte del desencadenador.
Para las operaciones de actualización no transaccionales a través del sistema de archivos, SQL Server creará una transacción interna para capturar la operación CloseHandle y los desencadenadores DML definidos se pueden desencadenar como parte de esa transacción. Una reversión de este tipo de transacción dentro del cuerpo del desencadenador, aunque no se impide, no revierte los cambios realizados en el FILESTREAM. Esta reversión también puede impedir que se activen los desencadenadores de actualización, aunque se haya cambiado el contenido de FILESTREAM.
Además de estos impactos, los desencadenadores en FileTables deben tratar un par de comportamientos adicionales.
En caso de operaciones de actualización no transaccional en FileTable a través del sistema de archivos, es posible que el contenido de FILESTREAM esté bloqueado exclusivamente por otras operaciones Win32 y no sea accesible para lectura y escritura a través del cuerpo del desencadenador. En tales casos, cualquier intento de acceder al contenido de FILESTREAM dentro del cuerpo del desencadenador puede provocar un error de "Infracción de uso compartido". Los desencadenadores deben diseñarse para controlar estos errores de forma adecuada.
Es posible que la imagen 'AFTER' de FILESTREAM no sea estable, puesto que en algunos casos pueda estar siendo escrita activamente por actualizaciones no transaccionales al mismo tiempo (debido a los modos de compartición permitidos en el acceso al sistema de archivos).
La terminación anómala de los manejadores Win32, como la eliminación explícita de los manejadores Win32 por parte de un administrador o un fallo de base de datos, no ejecutará los desencadenadores de usuario durante las operaciones de recuperación, aunque la aplicación Win32 que terminó anómalamente haya cambiado el contenido de FILESTREAM.
Vistas y FileTables
visualizaciones
Se puede crear una vista en una FileTable como en cualquier otra tabla. Sin embargo, las siguientes consideraciones se aplican a una vista creada en una FileTable:
View no tendrá ninguna semántica de FileTable. Es decir, las columnas de la vista (incluidas las columnas de atributo de archivo) se comportan igual que las columnas de vista normales sin semántica especial y lo mismo es true para las filas que representan archivos o directorios.
La vista puede ser actualizable según los principios de 'vista actualizable', pero las restricciones de la tabla subyacente pueden rechazar las actualizaciones, al igual que ocurre con la tabla.
La ruta de acceso de un archivo se puede visualizar en la vista agregándola como una columna explícita en la vista. Por ejemplo:
CREATE VIEW MP3FILES AS SELECT column1, column2, ..., GetFileNamespacePath() AS PATH, column3,... FROM Documents
Vistas indizadas
Actualmente, las vistas indexadas no pueden incluir columnas FILESTREAM ni columnas calculadas/persistentes que dependan de las columnas FILESTREAM. Este comportamiento permanece sin cambios con las vistas definidas en FileTable también.
Aislamiento de instantáneas y FileTables
Read Committed Snapshot Isolation (RCSI) y Snapshot Isolation (SI) dependen de la capacidad de tener una instantánea de los datos disponibles para los lectores incluso cuando se producen operaciones de actualización en los datos. Sin embargo, FileTables permite el acceso de escritura no transaccional a los datos de Filestream. Como resultado, las restricciones siguientes se aplican al uso de estas características en bases de datos que contienen FileTables:
Se puede modificar una base de datos que contiene FileTables para habilitar RCSI/SI.
Cuando el acceso no transaccional se establece en FULL para la base de datos, una transacción que se ejecute bajo RCSI o SI tiene el siguiente comportamiento:
Se produce un error en las lecturas Transact-SQL de la columna file_stream FileTable. INSERT y UPDATE en la columna siguen funcionando correctamente, siempre y cuando no lean de la columna file_stream.
Si la instrucción Transact-SQL especifica sugerencias de tabla READCOMMITTEDLOCK, las lecturas se realizan correctamente y toman bloqueos en las filas, en lugar de usar el control de versiones de fila.
También fallan las solicitudes de apertura de FileStream transaccionadas de Win32.
El acceso no transaccionado a FileTable Win32 se realiza correctamente. No se ven afectadas todas las consultas internas realizadas por FileTable.
La indexación de texto completo siempre se realiza correctamente, independientemente de cuáles sean las opciones de la base de datos (READ_COMMITTED_SNAPSHOT o ALLOW_SNAPSHOT_ISOLATION).
Bases de datos secundarias legibles
Las mismas consideraciones se aplican a las bases de datos secundarias legibles que a las instantáneas, como se describe en la sección anterior, Aislamiento de instantáneas y FileTables.
Bases de datos contenidas y FileTables
La característica FILESTREAM en la que depende la característica FileTable requiere alguna configuración fuera de la base de datos. Por lo tanto, una base de datos que usa FILESTREAM o FileTable no está totalmente contenida.
Puede establecer la contención de la base de datos en PARTIAL si desea usar determinadas características de bases de datos independientes, como los usuarios contenidos. Sin embargo, en este caso, debe tener en cuenta que algunas de las opciones de configuración de la base de datos no están contenidas en la base de datos y no se mueven automáticamente cuando se mueve la base de datos.