Con SQL Sever 2017 Microsoft incorpora nuevas funcionalidades propuestas por la comunidad de profesionales de Data Platform, hablaremos acerca de las mismas así como también sobre las funcionalidades más destacadas de la próxima versión de SQL
Strategies for Landing an Oracle DBA Job as a Fresher
SQL Server 2017 - Mejoras Impulsadas por la Comunidad
1. SQL Server 2017 Mejoras impulsadas por la comunidad
14 de Junio 2017 (12 pm GMT -5)
Javier Villegas
Resumen: Con SQL Sever 2017 Microsoft
incorpora nuevas funcionalidades
propuestas por la comunidad de
profesionales de Data Platform, hablaremos
acerca de las mismas así como también
sobre las funcionalidades más destacadas de
la próxima versión de SQL
Está por comenzar: Próximos Eventos
Consistencia en Bases de datos
Distribuidas con CosmosDB
21 de Junio
Warner Chavez
Moderador:
SQL 2016 Basic Availability
Groups multisubnet failover en
Azure
28 de Junio
Kenneth Ureña
2. Manténgase conectado a nosotros!
Visítenos en http://globalspanish.sqlpass.org
/SpanishPASSVC
lnkd.in/dtYBzev
/user/SpanishPASSVC
/SpanishPASSVC
4. 4
Oportunidades de Voluntariado
PASS no pudiera existir sin personas apasionadas y
dedicadas de todas partes del mundo que dan de su
tiempo como voluntarios.
Se un voluntario ahora!!
Para identificar oportunidades locales visita
volunteer.sqlpass.org
Recuerda actualizar tu perfil en las secciones de
“MyVolunteering” y MyPASS para mas detalles.
6. SQL Server 2017 Mejoras impulsadas por la
comunidad
14 de Junio de 2017
Moderador:
Javier Villegas
7. Javier Villegas
DBA Manager at Mediterranean Shipping Company Microsoft
MVP Data Platform.
Involved in the Microsoft SQL Server space since SQL Server 6.5
MCP and MCTS
Blogger and MSDN Forums contributor
Specialization in SQL Server Administration, Performance Tuning and
High Availability
Frequent speaker at SQL Saturdays and PASS Virtual Groups
10. 10
What’s coming in SQL Server 2017
Supported platforms
Linux Containers
Windows
Windows Server
• RedHat Enterprise Linux (RHEL) 7.3
• SUSE Enterprise Linux (SLES) v12 SP2
• Ubuntu 16.04 & 16.10
• Possibly other Linux distributions
• Docker: Windows & Linux containers
• Windows Server / Windows 10
11. Agenda
• Introduction
• Smart Differential Backup
• Smart Transaction Log Backup
• SELECT INTO …. ON Filegroup
• Tempdb Setup improvements
• Tempdb monitoring and planning
• Transaction log monitoring and diagnostics
• Improved backup performance for small databases on high-end servers
• Processor information in sys.dm_os_sys_info
• Capturing Query Store runtime statistics in DBCC CLONEDATABASE
• Resumable Online Index Rebuild
• Automatic plan correction
11
12. Introduction
Although SQL Server 2016 runs faster, SQL Server 2017 promises to run even faster and
empower customers to run smarter with intelligent database features like:
- The ability to run advanced analytics using Python in a parallelized and highly scalable way
- The ability to store and analyze graph data
- Adaptive query processing
- Resumable Online indexing
- Allow customers to deploy it on the platform of their choice (Windows or Linux) - Docker
SQL Server is one of the most popular DBMS among the SQL community and is a preferred
choice of RDBMS among customers and ISVs owing to its strong community support
In SQL Server 2017 CTP 2.0, there are several customer delighters and community-driven
enhancements based on the learnings and feedback from customers and the community from
in-market releases of SQL Server.
12
13. Smart Differential Backup
A new column modified_extent_page_count is introduced in sys.dm_db_file_space_usage to
track differential changes in each database file of the database.
The new column modified_extent_page_count will allow DBAs, the SQL community and
backup ISVs to build smart backup solutions, which perform differential backup only
if percentage changed pages in the database are below a threshold (say 70 to 80 percent),
otherwise full database backup is performed.
With a large number of changes in the database, cost and time to complete differential backup
is similar to that of full database backup, so there is no real benefit to differential backup in this
case; instead, it can increase database restore time.
By adding this intelligence to the backup solutions, customers can now save on restore and
recovery time while using differential backups.
13
14. Smart Differential Backup
Consider a scenario where you previously had a backup plan to take full database backup on
weekends and differential backup daily.
In this case, if the database is down on Friday, you will need to restore full database backup
from Sunday, differential backups from Thursday and then T-log backups of Friday.
By leveraging modified_extent_page_count in your backup solution, you can now take full
database backup on Sunday and let’s say by Wednesday, 90 percent of pages have changed, the
backup solution takes full database backup rather than differential backup since the time and
resources consumed remain the same.
If database is down on Friday, you will restore the full database backup from Wednesday, small
differential backup from Thursday and T-log backups from Friday to restore and recover the
database much quicker compared with the previous scenario.
This feature was requested by customers and community in connect item 511305.
14
15. Smart Differential Backup
15
USE <database-name>
GO
select CAST(ROUND((modified_extent_page_count*100.0)/allocated_extent_page_count,2) as
decimal(2,2)) from sys.dm_db_file_space_usage
GO
select
CAST(ROUND((SUM(modified_extent_page_count)*100.0)/SUM(allocated_extent_page_count),2)
as decimal(2,2)) as '% Differential Changes since last backup' from
sys.dm_db_file_space_usage
GO
16. Smart Transaction log Backup
In the upcoming release of SQL Server 2017 CTP, a new DMF
sys.dm_db_log_stats(database_id) will be released,
exposes a new column log_since_last_log_backup_mb.
The column log_since_last_log_backup_mb will empower DBAs, the SQL community and
backup ISVs to build intelligent T-log backup solutions, which take backup based on the
transactional activity on the database.
This intelligence in the T-log backup solution will ensure the transaction log size doesn’t grow
due to a high burst of transactional activity in short time if the T-log backup frequency is too
low.
It will also help avoid situations where default periodic interval for transaction log backup
creates too many T-log backup files even when there is no transactional activity on the server
adding to the storage, file management and restore overhead.
16
17. SELECT INTO …. ON Filegroup
One of the highly voted connect items and highly requested feature requests from the SQL
community to support loading tables into specified filegroups while using SELECT INTO is now
made available in SQL Server 2017 CTP
SELECT INTO is commonly used in data warehouse (DW) scenarios for creating intermediate
staging tables, and inability to specify filegroup was one of the major pain points to leverage
and load tables in filegroups different from the default filegroup of the user loading the table.
Starting SQL Server 2017 CTP, SELECT INTO T-SQL syntax supports loading a table into a
filegroup other than a default filegroup of the user using the ON <Filegroup name> keyword in
TSQL syntax shown below:
17
18. SELECT INTO …. ON Filegroup
18
ALTER DATABASE [AdventureWorksDW2016] ADD FILEGROUP FG2
select * from sys.database_files
ALTER DATABASE [AdventureWorksDW2016]
ADD FILE
(
NAME= 'FG2_Data',
FILENAME = 'S:sql_dataAdventureWorksDW2016_Data1.mdf'
)
TO FILEGROUP FG2;
GO
SELECT * INTO [dbo].[FactResellerSalesXL] ON FG2 from [dbo].[FactResellerSales];
19. Tempdb setup improvements
One of the constant pieces of feedback, the SQL community and the field after doing the SQL Server 2016
setup improvements is to uplift the maximum initial file size restriction of 1 GB for tempdb in setup.
For SQL Server 2017, the setup will allow initial tempdb file size up to 256 GB (262,144 MB) per file with a
warning to customers if the file size is set to a value greater than 1 GB and if “Instant File Initialization” (IFI)
is not enabled.
It is important to understand the implication of not enabling instant file initialization (IFI) where setup time
can increase exponentially depending on the initial size of tempdb data file specified.
IFI is not applicable to transaction log size, so specifying a larger value of transaction log can increase the
setup time while starting up tempdb during setup irrespective of the IFI setting for the SQL Server service
account.
19
20. Tempdb monitoring and planning
The SQL Server Tiger team surveyed the SQL community to identify common challenges experienced by
customers with tempdb.
Tempdb space planning and monitoring were found to be top challenges experienced by customers with
tempdb.
As a first step to facilitate tempdb space planning and monitoring, a new performant
DMV sys.dm_tran_version_store_space_usage is introduced in SQL Server 2017 to track version store
usage per database.
This new DMV will be useful in monitoring tempdb for version store usage for DBAs who can proactively
plan tempdb sizing based on the version store usage requirement per database without any performance
toll or overheads of running it on production servers.
20
21. Transaction log monitoring and diagnostics
One of the highly voted connect items and highly requested requests from the community is to
expose transaction log VLF information in DMV. T-log space issues
High VLFs and log shrink issues are some of the common challenges experienced by DBAs.
Some of the monitoring ISVs have asked for DMVs to expose VLF information and T-log space
usage for monitoring and alerting. A new DMV sys.dm_db_log_info is introduced in SQL Server
2017 CTP 2.0 to expose the VLF information similar to DBCC LOGINFO to monitor, alert and
avert potential T-log issues.
In addition to sys.dm_db_log_info, a new DMF sys.dm_db_log_stats(dbid) will released in the
upcoming CTP release of SQL Server 2017, which will expose aggregated transaction log
information per database.
21
22. Improved backup performance for small databases
on high-end servers
After migrating an existing in-market release of SQL Server to high-end servers, customers may
experience a slowdown in backup performance when taking backups of small to medium-size
databases.
This happens as we need to iterate the buffer pool to drain the ongoing I/Os.
The backup time is not just the function of database size but also a function of active buffer pool size.
In SQL Server 2017, we have optimized the way we drain the ongoing I/Os during backup, resulting
in dramatic gains for small to medium-size databases.
We have seen more than 100x improvement when taking system database backups on a 2TB
machine.
More extensive performance testing results on various database sizes is shared below.
The performance gain reduces as the database size increases as the pages to backup and backup IO
take more time compared with iterating buffer pool.
This improvement will help improve the backup performance for customers hosting multiple small
databases on a large high-end server with large memory.
22
25. Processor information in sys.dm_os_sys_info
Another highly requested feature among customers, ISVs and the SQL community to expose
processor information in sys.dm_os_sys_info is released in SQL Server 2017 CTP 2.0.
The new columns will allow you to programmatically query processor information for the
servers hosting SQL Server instance, which is useful in managing large deployments of SQL
Server.
New columns exposed in sys.dm_os_sys_info DMV are socket_count, core_count, and
cores_per_socket.
25
26. Resumable Online Index Rebuild
With this feature, you can resume a paused index rebuild operation from where the rebuild operation
was paused rather than having to restart the operation at the beginning.
In addition, this feature rebuilds indexes using only a small amount of log space.
You can use the new feature in the following scenarios:
• Resume an index rebuild operation after an index rebuild failure, such as after a database failover
or after running out of disk space. There is no need to restart the operation from the beginning.
This can save a significant amount of time when rebuilding indexes for large tables.
• Pause an ongoing index rebuild operation and resume it later. For example, you may need to
temporarily free up system resources to execute a high priority task or you may have a single
maintenance window that is too short to complete the operation for a large index. Instead of
aborting the index rebuild process, you can pause the index rebuild operation and resume it later
without losing prior progress.
• Rebuild large indexes without using a lot of log space and have a long-running transaction that
blocks other maintenance activities. This helps log truncation and avoid out-of-log errors that are
possible for long-running index rebuild operations.
26
27. Resumable Online Index Rebuild
27
ALTER INDEX IDX_2_5 ON [dbo].[A_Table02]
REBUILD WITH
( RESUMABLE = ON, ONLINE = ON );
SELECT total_execution_time, percent_complete, page_count,
object_id,index_id,name,sql_text,last_max_dop_used,partition_number,state,
state_desc,start_time,last_pause_time,total_execution_time
FROM sys.index_resumable_operations;
28. Automatic plan correction
Automatic plan correction is a new automatic tuning feature in SQL Server 2017 that identifies
SQL query plans that are worse than previous one, and fix performance issues by applying
previous good plan instead of the regressed one.
In some cases, new plan that is chosen might not be better than the previous plans. This is rare
situation and might happen if an optimal plan is not included in a list of plans that will be
considered as potential candidates. In other cases, SQL Server might choose the best plan for
the current T-SQL query, but the selected plan might not be optimal if the same T-SQL queries
is executed with different parameter values. In that case, SQL Server might reuse the plan that is
compiled and cached after first execution even if the plan is not optimal for the other
executions. These problems are known as plan regressions.
28
29. Automatic plan correction
If you identify that previous plan had better performance, you might explicitly force SQL Server
to use the plan that you identified as optimal for some specific query
using sp_force_plan procedure:
As a next step, you can let SQL Server 2017 to automatically correct any plan that regressed.
29
EXEC sp_force_plan @query_id = 1223, @plan_id = 1987
ALTER DATABASE current SET AUTOMATIC_TUNING ( FORCE_LAST_GOOD_PLAN = ON )
30. Automatic plan correction
This statement will turn-on automatic tuning in the current database and instruct SQL Server to force
last good plan if it identifies plan performance regression while the current plan is executed.
SQL Server 2017 will continuously monitor and analyze plan performance, identify new plans that
have worse performance than the previous ones, and force last know good plan as a corrective
action.
SQL Server 2017 will keep monitoring performance of the forced plan and if it does not help, query
will be recompiled.
At the end, SQL Server 2017 will release the forced plan because query optimizer component should
find optimal plan in the future.
30
ALTER DATABASE current SET AUTOMATIC_TUNING ( FORCE_LAST_GOOD_PLAN = ON )
31. String functions
A collection of new string function in SQL Server 2017
TRIM
Removes the space character char(32) or other specified characters from the start or end of a string
TRANSLATE
Allows us to perform a one-to-one, single-character substitution in a string
CONCAT_WS()
Stands for Concatenate with Separator, and is a special form of CONCAT(). The first argument is the
separator—separates the rest of the arguments. The separator is added between the strings to be
concatenated. The separator can be a string, as can the rest of the arguments be. If the separator
is NULL, the result is NULL.
STRING_AGG
Aggregate functions compute a single result from a set of input values. With the prior versions of
SQL, string aggregation was possible using T-SQL or CLR, but there was no inbuilt function available
for string aggregation, with a separator placed in between the values.
31
33. Other features
• Graph Data Processing with SQL Server 2017
https://blogs.technet.microsoft.com/dataplatforminsider/2017/04/20/graph-data-processing-with-sql-server-2017/
• Showplan enhancements in SQL Server 2017
https://blogs.msdn.microsoft.com/sql_server_team/sql-server-2017-showplan-enhancements/
• Adaptive Query Processing
https://www.youtube.com/watch?v=szTmo6rTUjM
33
36. Consistencia en Bases de Datos Distribuidas con
CosmosDM
21 de Junio (12 pm GMT -5)
Warner Chavez
Resumen:
Como profesionales de datos muchas veces hablamos y escuchamos hablar sobre la
consistencia de los datos. Con la llegada de sistemas distribuidos NoSQL como Mongo,
Cassandra y otros, ciertos términos se han popularizado como "consistencia eventual". Pero
que significa esto realmente? Existen otros niveles de consistencia? Que podemos encontrar
actualmente en las ofertas de nube publica? En esta sesión estudiaremos la teoría de niveles
de consistencia, porque son importantes en el desarrollo de sistemas de bases de datos
distribuidas y veremos como se aplican en Cosmos DB, la base de datos NoSQL de Azure.
Próximo Evento
Notas do Editor
Microsoft has delivered a number of products enabling choice for customers, including:
HD Insight on Linux - a managed Apache Hadoop, Spark, R, HBase, and Storm cloud service made easy
R Server on Linux - Use R—the powerful, statistical programming language—in an enterprise-class, big data analytics platform. Microsoft R Server is your flexible choice for analyzing data at scale, building intelligent apps, and discovering valuable insights across your business (https://www.microsoft.com/en-us/cloud-platform/r-server)
Linux in Azure – run Linux-based virtual machines in Microsoft Azure (IaaS)
Customers can take advantage of Microsoft–created database connectivity drivers and open-source drivers that enable developers to build any application using the platforms and tools of their choice, including Python, Ruby, and Node.js
With SQL Server 2017,now in public preview, and generally available to purchase targeting mid-calendar year 2017, the power of SQL Server is available on the platform of your choice.
Plataformas soportadas
Estos son lo puntos que veremos hoy
Ya conocemos que SQL Server 2016 es el motor de base de datos más rápido del mercado, también el mas seguro.
SQL Server 2017 promete ser incluso más rápido y permitir a los clientes a ejecutar más inteligente con funciones de base de datos inteligente como:
La capacidad de ejecutar analíticas avanzadas utilizando Python de forma paralela y altamente escalable
La capacidad de almacenar y analizar Graph Data
Adaptive Query Processing – teneiendo un procesamiento mas inteligente a la hora de seleccionar el mejor plan de ejecución para nuestro workload
Indexación Online reanudable
Permitir hacer el deployment en la plataforma de nuestra elección (Windows o Linux) - Docker
SQL Server es uno de los DBMS más populares entre la comunidad de SQL y es una opción preferida de RDBMS entre clientes e ISVs debido a su fuerte apoyo de la comunidad
En SQL Server 2017 CTP 2.0, hay varias mejoras impulsadas por la comunidad basadas en los aprendizajes , feedback de los clientes y la comunidad de profesionales asi como también de las versiones de SQL Server del mercado
Se introdujo una nueva columna modified_extent_page_count en la DMV sys.dm_db_file_space_usage para realizar un seguimiento de los cambios diferenciales en cada archivo de base de datos de la base de datos.La nueva columna modify_extent_page_count nos permitirá crear soluciones de backup inteligentes, que realizan una copia de seguridad diferencial sólo si el porcentaje de páginas modificadas en la base de datos está por debajo de un umbral (70-80%). .Con muchos cambios en la base de datos, el costo y el tiempo para realizaun un backup diferencial es similar al de la copia de seguridad full, por lo que no hay ningún beneficio real para la copia de seguridad diferencial.Al agregar esta inteligencia a las soluciones de backup, podemos ahorrar tiempo de restauración y recuperación.
Consideremos el escenario en el que previamente teníamos un plan backups para realizar full backup los fines de semana y la copia de seguridad diferencial diariamente.
En el caso que perdamos la base de datos y tengamos que restaurarla el dia viernes, tendremos que restaurar la copia de seguridad full desde el domingo, las copias de seguridad diferenciales del jueves y luego las copias de seguridad del T-log del viernes.
Considerando la nueva columna modify_extent_page_count en la solución de backup, ahora podemos realizar una copia de seguridad full el domingo y digamos que el miércoles, el 90% de las páginas han cambiado, la solución de backup toma copia de seguridad de base de datos full en lugar de copia de seguridad diferencial, .
Si necesitamos restaurar la base de datos el dia viernes, restauraremos la copia de seguridad full desde el miércoles, la copia de seguridad diferencial pequeña desde el jueves y las copias de seguridad T-de viernes para restaurar y recuperar la base de datos mucho más rápido en comparación con el escenario anterior.
Esta característica fue solicitada por los clientes y la comunidad
Connect case 511305.
ejemplo
Tendremos una nueva DMF sys.dm_db_log_stats (database_id)
donde tendremos una nueva columna log_since_last_log_backup_mb.
La columna log_since_last_log_backup_mb permitira crear soluciones de backup T-log inteligentes, haciendo backup basado en la actividad transaccional en la base de datos.
También ayudará a evitar situaciones en las que el intervalo periódico por defecto para la copia de seguridad del registro de transacciones crea demasiados archivos de copia de seguridad de T-log incluso cuando no hay actividad transaccional en el servidor que añade al almacenamiento, la gestión de archivos y la sobrecarga de restauración.
Uno de los ítems mas votados por la comunidad en el sitio de Microsoft Connect es la posibilidad de permitir la carga de tablas dentro de un FileGroup especifico cuando utilizamos SELECT INTO. Esto es posible ahora
SELECT INTO se utiliza comúnmente en escenarios de Data warehouse(DW) para crear tablas intermedias
Ejemplo
TempDB mas grande durante el setup
Monitorear tamano
Después de migrar una versión existente de SQL Server a servidores de gama alta, los clientes experimentan una desaceleración en el rendimiento de backup al realizar copias de seguridad de bases de datos pequeñas a medianas.
Esto ocurre cuando necesitamos iterar buffer pool para vaciar los I/O en curso.
El tiempo de backup no es sólo en función del tamaño de la base de datos sino también una función del tamaño del conjunto de búfer activo.
En SQL Server 2017, se optimiza la forma de liberar el I/O en curso durante la copia de seguridad, lo que resulta en ganancias para las bases de datos pequeñas y medianas.
Se ha reportado más de 100x de mejora al tomar los backups de la base de datos
Aca veremos algunos resultados de pruebas de rendimiento más extensos en varios tamaños de base de datos.
La ganancia de rendimiento se reduce a medida que el tamaño de la base de datos aumenta
Esta mejora ayudará a mejorar el rendimiento de copia de seguridad para los clientes que alojan varias bases de datos pequeñas en un gran servidor de gama alta con gran memoria.
Agunos ejemplos
Otra característica solicitada entre los clientes, ISVs y la comunidad SQL fue exponer la información del procesador en sys.dm_os_sys_info se publica en SQL Server 2017 CTP 2.0.
Las nuevas columnas permitirán consultar de forma programática la información del procesador de los servidores que alojan la instancia de SQL Server, lo cual es útil para administrar grandes deployments de servidores SQL.
Las nuevas columnas expuestas en sys.dm_os_sys_info DMV son socket_count, core_count y cores_per_socket.
Con esta función, puede reanudar una operación de reconstrucción de índice detenida desde donde se ha detenido la operación de reconstrucción en lugar de tener que reiniciar la operación al principio.
Además, esta característica reconstruye los índices utilizando sólo una pequeña cantidad de espacio de transaction log.
Puede utilizar la nueva función en los siguientes escenarios:
Reanudar una operación de reconstrucción de índice después de un error de reconstrucción de índice, como después de una conmutación por error de base de datos o después de quedarse sin espacio en disco. No es necesario reiniciar la operación desde el principio. Esto puede ahorrar una cantidad significativa de tiempo al reconstruir índices para tablas grandes.
Detener una operación de reconstrucción de índice en curso y reanudarla más tarde. Por ejemplo, puede que tenga que liberar temporalmente los recursos del sistema para ejecutar una tarea de alta prioridad o puede tener una sola ventana de mantenimiento que es demasiado corta para completar la operación de un índice grande. En lugar de abortar el proceso de reconstrucción del índice, puede detener la operación de reconstrucción del índice y reanudarlo más tarde sin perder el progreso previo.
Reconstruya índices grandes sin usar mucho espacio de registro y tenga una transacción de larga ejecución que bloquee otras actividades de mantenimiento. Esto ayuda a truncar el registro y evitar errores fuera de registro que son posibles para operaciones de reconstrucción de índices largas.
Automatic plan correction es una nueva característica de tuning automático en SQL Server 2017 que identifica los query plans que son peores que los anteriores y corrige problemas de performance mediante la aplicación de un buen plan anterior en lugar del degradado.
En algunos casos, el nuevo plan elegido podría no ser mejor que los planes anteriores. Esto es una situación rara y puede ocurrir si un plan óptimo no está incluido en una lista de planes que serán considerados como candidatos potenciales. En otros casos, SQL Server podría elegir el mejor plan para la consulta T-SQL actual, pero el plan seleccionado podría no ser óptimo si se ejecutan las mismas consultas T-SQL con diferentes valores de parámetro. En ese caso, SQL Server puede reutilizar el plan que se compila y se almacena en caché después de la primera ejecución incluso si el plan no es óptimo para las otras ejecuciones. Estos problemas se conocen como regresiones de plan.
En SQL Server 2016 con Query Store podiamos forzar manualmente la utilizacion del mejor plan que nosotros consideramos
Con SQL Server 2017 esto se puede realizer en forma automatica
Esta statement activará la sintonización automática en la base de datos actual e instruirá a SQL Server para forzar el último buen plan si identifica la regresión de rendimiento del plan mientras se ejecuta el plan actual.
SQL Server 2017 continuamente monitoreará y analizará el desempeño del plan, identificará nuevos planes que tienen un desempeño peor que los anteriores, y forzará al último a conocer un buen plan como una acción correctiva.
SQL Server 2017 seguirá supervisando el rendimiento del plan forzado y si no ayuda, la consulta será recompilada.
Al final, SQL Server 2017 liberara el plan forzado porque el query optimizar debería encontrar el plan óptimo en el futuro.
Un set nuevo de funciones de strings en SQL Server 2017
TRIM
Elimina el caracter de carácter de char(32) u otros caracteres especificados desde el principio o el final de una cadena
TRANSLATE
Permite realizar una sustitución unívoca de un solo carácter en una cadena
CONCAT_WS ()
Significa Concatenar con un separador, y es una variante de CONCAT (). El primer argumento es el separador: separa el resto de los argumentos. El separador se añade entre las cadenas a concatenar. El separador puede ser una cadena, al igual que el resto de los argumentos. Si el separador es NULL, el resultado es NULL.
STRING_AGG
Las funciones agregadas calculan un solo resultado de un conjunto de valores de entrada. Con las versiones anteriores de SQL, la agregación de cadenas era posible utilizando T-SQL o CLR, pero no había ninguna función incorporada disponible para la agregación de cadenas, con un separador colocado entre los valores.
Un set nuevo de funciones de strings en SQL Server 2017
TRIM
Elimina el caracter de carácter de char(32) u otros caracteres especificados desde el principio o el final de una cadena
TRANSLATE
Permite realizar una sustitución unívoca de un solo carácter en una cadena
CONCAT_WS ()
Significa Concatenar con un separador, y es una variante de CONCAT (). El primer argumento es el separador: separa el resto de los argumentos. El separador se añade entre las cadenas a concatenar. El separador puede ser una cadena, al igual que el resto de los argumentos. Si el separador es NULL, el resultado es NULL.
STRING_AGG
Las funciones agregadas calculan un solo resultado de un conjunto de valores de entrada. Con las versiones anteriores de SQL, la agregación de cadenas era posible utilizando T-SQL o CLR, pero no había ninguna función incorporada disponible para la agregación de cadenas, con un separador colocado entre los valores.