Como DBA, ¿cómo haría para hacer la transición de Oracle a SQL Server?

Soy un DBA de Oracle que también tiene experiencia en Sybase.

¿Cuáles son las principales diferencias arquitectónicas y conceptuales entre las dos plataformas RDBMS?

Una respuesta similar a la pregunta de SQL Server-> Oracle aquí sería de gran utilidad.

He cambiado entre trabajar en Oracle y SQL Server en los últimos años, y escribí un comentario sobre ir por el otro lado aquí. Hay una serie de diferencias idiomáticas y arquitectónicas, y los vendedores y desarrolladores / comunidades de DBA que utilizan cada producto utilizan de manera diferente diversos términos.

Arquitectura fisica

SQL Server organiza varias cosas de manera un poco diferente a Oracle y tiene uno o dos conceptos clave que no tienen análogos directos en Oracle.

• Una 'Base de datos' es un elemento separado en SQL Server, con sus propios permisos de usuario, esquemas / espacios de nombres y almacenamiento. Si está familiarizado con Sybase, funcionan de la misma manera que las bases de datos en Sybase, debido a los orígenes comunes del producto.

• Los grupos de archivos son más o menos equivalentes a los espacios de tabla, aunque son locales en una base de datos.

• Un esquema es un concepto distinto de un usuario de base de datos en SQL Server, aunque los usuarios pueden tener un esquema predeterminado.

• MVCC funciona de manera algo diferente en SQL Server. Es una característica relativamente reciente, que mantiene diferentes copias de una fila hasta que se liberan los bloqueos de la versión anterior. SQL Server no tiene un equivalente directo a un segmento de reversión. No está activo por defecto en las bases de datos de SQL Server.

• Tempdb se usa mucho más en SQL Server. El sistema lo usa para tablas temporales y resultados de unión intermedios. Más sobre tempdb más tarde.

• La partición de tablas es algo más torpe que Oracle. Debe configurar una función de partición que cree una clave de partición a partir de lo que esté suministrando, luego un esquema de partición sobre esa función de partición. El esquema de partición se comporta un poco como un grupo de archivos en el que luego crea la tabla en el esquema de partición.
  
  Intercambiar particiones dentro y fuera requiere que configure una restricción en una tabla vacía en la estructura correcta. La restricción garantiza que los valores de la clave de partición son apropiados para la partición que desea intercambiar.

• Las vistas materializadas se denominan vistas indexadas en SQL Server. La GROUP BYcláusula tiene un CUBEoperador, y la documentación alude a una función de reescritura de consultas. Sin embargo, esta funcionalidad no está bien documentada y puede no ser muy madura. YMMV.

• SQL Server no admite transacciones autónomas, aunque sí admite la confirmación en dos fases a través de protocolos de transacción XA u OLEDB.

• Los índices agrupados son ligeramente diferentes de las tablas ordenadas por índice en Oracle, ya que no requieren que todas las columnas de la tabla participen en el índice agrupado. Son mucho más utilizados en la arquitectura de SQL Server que los IOT en Oracle.

• SQL Server admite índices de cobertura, pero no tiene índices de unión. Los índices de mapa de bits no son compatibles, aunque tiene un operador de intersección de índice / transformación de estrella que puede calcular intersecciones sin tocar la tabla de hechos.

• Las secuencias son una adición relativamente reciente a SQL Server. Tradicionalmente, las claves de autoincremento se realizan a través de columnas de identidad. Puede cargar valores en una columna de identidad a través de set identity_insert on.

Programación

Idiomatic T-SQL tiene algunas diferencias con idiomatic PL / SQL. Funciona de manera tan diferente que algunas de las diferencias paradigmáticas merecen una explicación más profunda.

• T-SQL no tiene concepto de paquete. Todos los procedimientos y funciones almacenados en una base de datos viven en un espacio de nombres común, aunque los esquemas se pueden usar para dividir esto, y el espacio de nombres es local para una base de datos.

• Obtenga una idea de cómo usar tablas temporales y SELECT INTO. Es bastante raro encontrar código T-SQL que realmente necesita un cursor; Las tablas temporales permiten que las operaciones se dividan en pasos que se pueden hacer con las operaciones establecidas. SELECT INTOen tempdb se registra mínimamente, y también se registra mínimamente en ciertos modos de recuperación en las bases de datos de usuarios, por lo que es tan rápido como el operador de consulta que persiste en un resultado de unión intermedio.
  
  Idiomatic T-SQL usará tablas temporales en el tipo de roles que vería las variables del cursor en PL / SQL, pero hará mucho más uso de las operaciones de conjunto. Sin embargo, las tablas temporales pueden crear un código bastante obtuso, así que úselo con cuidado.

• El diccionario de datos del sistema era mucho más obtuso que el de Oracle en versiones anteriores, pero mejoró mucho con SQL Server 2005. Aunque las herramientas proporcionadas por Microsoft tienen muchas cosas de introspección integradas en el explorador SSMS, aún vale la pena conocer su alrededor del diccionario de datos. No diferencia entre ALL, USERy DBApuntos de vista de los objetos de base de datos, sin embargo.

• SSMS tiene un visor de planes de consultas integrado.

• Los identificadores en el código T-SQL se pueden citar con [], y pueden contener todo tipo de basura si se cita. Sin embargo, si lo atrapamos llamando a una columna 'Directo / Transferencia', le arrancaremos los intestinos.

• SQL Server tiene funciones de ventana (desde 2005 IIRC), por lo que puede hacer pedidos, ejecutar sumas y cosas similares dentro de los grupos ahora.

• T-SQL no tiene un equivalente directo a CONNECT BY, aunque la recursividad se puede hacer a través de CTE recursivos.

• Si necesita escribir código que salte a través de las bases de datos (a diferencia de los esquemas dentro de una base de datos), considere usar sinónimos públicos para alias los objetos a algo local y consulte los alias en el código. Esto evita dependencias codificadas en los nombres de las bases de datos.

• Si evita las dependencias codificadas en los nombres de las bases de datos, las bases de datos facilitan el mantenimiento de múltiples entornos en el mismo servidor.

• Algunas cosas, como las funciones de agregación personalizadas, solo se pueden implementar utilizando sprocs CLR. Además, si desea escapar de un contexto de transacción (por ejemplo, falsificar una transacción autónoma para el registro de errores a prueba de reversión) puede usar un sproc CLR, ya que puede crear una conexión local fuera del contexto de transacción actual.

Seguridad

Los inicios de sesión se definen en el nivel de instancia de SQL Server, pero cada inicio de sesión se asigna a cero o más bases de datos como 'usuario de la base de datos'. Los permisos se pueden asignar tanto a 'inicios de sesión' (servidor) como a 'usuarios' (base de datos), pero en una base de datos se usan normalmente 'roles'. Los usuarios pertenecen a roles, los permisos se asignan a roles. SQL Server 2012 agrega 'roles de servidor'.

• SQL Server 2012 presenta un concepto llamado 'bases de datos parcialmente contenidas', que permite que la información de usuarios y roles se mantenga local en esa base de datos.

• Dentro de una base de datos, el concepto de usuario y esquema está separado. Se puede asignar un usuario o rol a un esquema y un esquema posee objetos de la base de datos.

• La autenticación de Windows utiliza información de inicio de sesión detrás de escena para autenticar a un usuario en una máquina o dominio para un inicio de sesión de SQL Server. El soporte de IIRC para esto es un extra opcional en Oracle.

• Un rol especial, 'dbo' (abreviatura de 'propietario de la base de datos') tiene una especie de privilegio de superusuario dentro de una base de datos específica. Cada base de datos tiene un rol 'dbo' y los usuarios pueden ser asignados al rol 'dbo' en una base de datos determinada.

• También hay un esquema 'dbo' predeterminado. Los objetos pueden ser propiedad del esquema dbo: los objetos creados por los usuarios con el rol 'dbo' (o permisos de administrador de todo el sistema) serán propiedad del esquema 'dbo' de manera predeterminada, a menos que se proporcione otro esquema explícitamente.

• La información de seguridad no se guarda con una copia de seguridad de una sola base de datos. Los usuarios deben y los roles deben configurarse explícitamente en el servidor en el que se restaura la copia de seguridad. SQL Server 2012 permite que los datos de usuarios y roles se mantengan localmente en una base de datos con una nueva característica de 'bases de datos parcialmente contenidas'.

• Desde SQL Server 2005, los procedimientos almacenados se pueden ejecutar en el contexto de seguridad del llamante, el creador, el esquema propietario o un usuario específico.

• En una vista en SQL Server, los permisos en las tablas subyacentes se basan en los permisos del esquema que posee la vista. Los permisos de usuario en las tablas subyacentes no participan en la seguridad, aunque una definición de vista puede incluir filtros que obtienen información de la sesión. En Oracle, los permisos de usuario en las tablas subyacentes pueden afectar la vista, dependiendo de la configuración de las concesiones.

Monitoreo y ajuste

TBA: arquitectura de memoria frente a SGA, etc. en Oracle

Copia de seguridad y recuperación

TBA

Estampación

Microsoft agrupa un conjunto de herramientas circundantes con SQL Server. Algunos de los principales artículos suministrados son:

• SQL Server Management Studio (SSMS): hace algo similar a SQL Developer en Oracle: proporciona un editor y una función de ejecución de código. Algunas características útiles incluyen un navegador de objetos de base de datos y un visor de planes de consulta.

• SQL Server Analysis Services (SSAS): este es un servidor OLAP que es distinto del servidor de base de datos. Utiliza su propio lenguaje de consulta (MDX) y API (XML / A) para la comunicación cliente-servidor. No se puede consultar con SQL. SSMS tiene una función para editar consultas MDX y XMLA sin procesar y mostrar los resultados. También se proporciona una herramienta de consulta de línea de comandos llamada ASCMD.EXE.

• SQL Server Reporting Services (SSRS): esta es una herramienta de informes basada en la web para publicar informes. Los informes pueden construirse a través de BI Development Studio (BIDS) o Report Builder, y publicarse en un portal web. El servidor SSRS tiene una API de servicio web para administrar el servidor mediante programación. Tenga en cuenta que los informes SSRS pueden consumir datos de una variedad de fuentes, no solo SQL Server. Se proporciona una herramienta de línea de comandos llamada RS.EXE para administrar mediante programación los servidores SSRS.

• SQL Server Integration Services (SSIS): esta es una herramienta ETL suministrada con SQL Server. Arquitectónicamente, es bastante diferente a OWB u ODI en que no es una herramienta de generación de código. El tiempo de ejecución se ubica en el lado del cliente y puede estar en una máquina separada del servidor de la base de datos. Los paquetes SSIS pueden desarrollarse con BIDS y ejecutarse independientemente con una herramienta de línea de comandos llamada DTEXEC.EXE.

• BI Development Studio (BIDS): este es un entorno basado en un estudio visual para desarrollar informes, paquetes SSIS y cubos SSAS. Si se instalan otras herramientas de desarrollo basadas en VS (por ejemplo, VS Professional), las herramientas se pueden integrar en un solo entorno y en una agrupación de proyectos común.

• Copia masiva (BCP): una herramienta de inserción / extracción masiva de línea de comando similar a SQL * Loader

• SQLCMD: una herramienta de consulta de línea de comando similar a SQL * plus

• SQL Profiler: una herramienta de rastreo y creación de perfiles que puede capturar y evaluar la información de rastreo de SQL Server, SSAS y otras herramientas en la suite.

• Agente SQL Server: una utilidad de programación de trabajos que puede ejecutar trabajos periódicos de un tipo u otro.

Nuestro producto principal funciona tanto en SQL Server como en Oracle, aquí hay algunas otras diferencias que tuvimos que solucionar y podría ser bueno tener en cuenta:

• El manejo de fecha y hora es muy diferente: diferentes precisiones, diferentes conjuntos de funciones para trabajar

• Las cadenas vacías son NULL en Oracle, no en SQL Server

• El manejo de la codificación de caracteres y Unicode es muy diferente. En SQL Server puede tener columnas normales ( varchar) o Unicode ( nvarchar) mezcladas en la misma base de datos, en Oracle usted decide a nivel de base de datos qué tipo de codificación usar.