Claro, eso ya es conocer los datos y actualizar lo que sea necesario según las relaciones. Yo enseño a construir la consulta pero los datos de cada uno no puedo saber como están. Como siempre, esta es la teoría, en la práctica es igual pero tienes que tener en cuenta muchos más factores que no entran en un video de un minuto.

Gracias por el apoyo

Cuando restauras la bbdd el índice tendrá la misma fragmentación que antes, lo que te pudo pasar es que ya tenias planes cacheados para tus consultas y al restaurar tuvo que recompilarlos. Al detectar la fragmentación decidio no usar el índice. De todas formas pueden ser otras mil cosas, sin ver el caso es dificil saberlo

Gracias a ti @Santymarchulo. Si tienes alguna sugerencia o tema del que te gustaría que hable me lo comentas.

Siempre que se pueda debemos evitar los bucles. Para el caso que comentas lo más sencillo sería tener una tabla con los inicio y fin de mes y cruzar con ella. Si no tenemos la tabla la podemos generar para la ocasión, por ejemplo una CTE con una consulta recursiva que nos devuelva las fechas. Algo así: WITH RangoMeses AS -- CTE con consulta recursiva para calcular las fechas ( SELECT FechaInicio = DATEFROMPARTS(2012, 1, 1), -- Fecha inicial del rango FechaFin = EOMONTH(DATEFROMPARTS(2012, 1, 1)) -- Fin del mes (último día) UNION ALL SELECT DATEADD(DAY, 1, FechaFin), -- Día siguiente al último día del mes anterior EOMONTH(DATEADD(DAY, 1, FechaFin)) -- Fin del mes actual FROM RangoMeses WHERE FechaFin < '20121231' -- Ajusta el rango hasta el año deseado ) SELECT FechaInicio, FechaFin, c = COUNT_BIG(*) FROM dbo.Votes AS v INNER JOIN RangoMeses AS r ON v.CreationDate >= r.FechaInicio AND v.CreationDate <= r.FechaFin GROUP BY r.FechaInicio, r.FechaFin ORDER BY r.FechaInicio;

Me alegro mucho. Gracias por el feedback

Es exactamente lo mismo, siempre que uses la función en el lado del valor del filtro y no en el del campo de la tabla. Se calculará una vez y se usará para comparar con la tabla. No vas a notar la diferencia entre el calculo único de la última fecha de un mes a mano o con EOMONTH siempre que sea eso, solo una vez.

Lamentablemente no hay manera de restringirlo por configuración de manera sencilla. Trataré de explicar en un video como jugar con los triggers de inicio de sesión para poder controlarlo.

Ya lo tienes explicado en este video. Espero que te ayude. kzbin.info/www/bejne/i2WsaJuqrNCcmrs

Gracias !!!

Por cierto, mencionabas ideas para contenido, aprovechando la situación y es algo con lo que aún no he podido lidiar y casi no he encontrado contenido en español , es referente al doble salto ( double hop ) que usa autentificacion con kerberos ( el default es NTLM ).

Gracias por la idea aunque no lo termino de ver para un video. Me resulta demasiado teórico. Estas cosas las reservo para el blog y sobre Kerberos y NTLM con los problemas del doble salto tienes dos artículos. El primero, sobre la autenticación en SQL y como funciona www.soydba.es/autenticacion-en-sql-server/ Y este ya centrado del todo en Kerberos y los SPN www.soydba.es/kerberos-spn-para-sql-server/

@@SoyDBA No había buscado en el blog, gracias por mencionarlo, voy a echarle un vistazo. Gracias .!!

Muy cierto eso, al final, muchas veces, nos vemos limitados a las características que usamos en el día a día. Lo cierto es que desde que tengo el canal y el blog yo mismo estoy descubriendo y aprendiendo muchas nuevas funcionalidades. Sobre este RLS las capacidades son infinitas pero con cuidado, al final cuanto más compliquemos lo lógica peor será para el rendimiento general del servidor. Por ejemplo, tenemos que tener mucho cuidado de siempre indexar estos campos que se van a consultar siempre por la función de seguridad.

Muchas gracias a ti por seguir todos los videos. Me alegro mucho de que te sirva mi contenido, ya sabes que si hay algo de lo que quieras que hablemos en el canal puedes comentármelo y lo valoraré.

Muchas gracias Cesar, bienvenido a la comunidad de Telegram, charlamos por ahí.

Gracias por el comentario, me alegra que el contenido os sea de utilidad. Si tienes alguna sugerencia o quieres que tratemos algún tema en particular dímelo y trataré de traerlo aquí o al blog.

Hola Jorge. Desde SQL Server 2017 existe la posibilidad de que Always On funcione sin WSFC pero requiere una serie de configuraciones extra y tiene muchas limitaciones. Trataré de dedicarle un video cuando pueda sacar un rato para montar toda la infra necesaria para las pruebas. Gracias por comentar

@@SoyDBA Gracias ojala te des un tiempo, ya que aveces no se cuenta con mucha infraestructura para tener varios servidores o se quiere implementar algo mas sencillo

Seguro que si lo pasaremos genial. Una pena que no puedas venir. Pero al de Valencia si que vendrás !!

@SoyDBA esta vez estaré entre las sombras, pero Valencia nos está esperando jajajaja

Hola, poco se puede hacer pero tampoco es que no puedas hacer nada para mejorar los tiempos de copia. Existen una serie de parámetros de la copia que son BLOCKSIZE, MAXTRANSFERSIZE y BUFFERCOUNT con los que puedes jugar. Me apunto preparar contenido sobre ello pero será en el blog ya que es más teórico. Si quieres algo más simple pero que igual no has tenido en cuenta echale un ojo a este artículo de Brent Ozar, tiene ya 8 años pero sigue siendo válido: www.brentozar.com/archive/2015/12/how-to-make-sql-server-backups-go-faster/

Hola, gracias por el feedback. Ya me lo habéis dicho varios y es cierto, la calidad del audio de este video no está al nivel de los demás. Para mi el audio es una de las partes más importantes del video y que puede enturbiar todo lo demás. Trabajo mucho en edición en este sentido pero no soy ningún experto en la materia y a veces no llego. Espero que podáis perdonarlo y pondré los medios para mejorar en futuros videos. Si te ha quedado alguna duda sobre lo que se ve en el video por este tema o cualquier otro ponte en contacto conmigo a través del mail que aparece en mi perfil y lo comentamos sin problema. Gracias de nuevo y disculpa.

Hola amigo, gracias por el feedback. Ya me lo habéis dicho varios y es cierto, la calidad del audio de este video no está al nivel de los demás. Para mi el audio es una de las partes más importantes del video y que puede enturbiar todo lo demás. Trabajo mucho en edición en este sentido pero no soy ningún experto en la materia y a veces no llego. Espero que podáis perdonarlo y pondré los medios para mejorar en futuros videos. Si te ha quedado alguna duda sobre lo que se ve en el video por este tema o cualquier otro ponte en contacto conmigo a través del mail que aparece en mi perfil y lo comentamos sin problema. Gracias de nuevo y disculpa.

Genial, me alegro mucho. Para eso era este vídeo, para entenderlo.

Entonces le contratamos para el canal?

Muchas gracias por tu comentario. Lo importante es la calidad no la calidad y en eso puedo estar orgulloso. Me alegro que te haya servido el vídeo.

Gracias a ti por ver y comentar mi video. Me alegro que te haya sido de utilidad

Buenas Daniel, es un tema muy interesante que da para mucho más que una respuesta rápida de un comentario. Me lo apunto para analizarlo con detenimiento en el blog. Mientras tanto, algo te puedo adelantar. Obviamente QueryStore agrega carga de trabajo al servidor pero realmente es una sobrecarga mínima que no va a ser perceptible más que en casos muy concretos. En cuanto al espacio en disco, es configurable, con un máximo de 10 Gb en bases de datos de Azure y sin límite en las versiones de SQL Server on-premise. Sobre el consumo de CPU y RAM piensa que todo los datos de QureyStore se almacenan de manera asíncrona por lo que no afectan a la ejecución de la consulta directamente. Indirectamente si que consume recursos pero ten en cuenta que QueryStore va a usar sus propios clerks de memoria para almacenar los datos en caché antes de volcarlos a disco (flush) en intervalos configurables. El principal problema del rendimiento de esta herramienta nos lo encontramos cuando el espacio reservado en disco llega al máximo y se deben borrar datos pero esto es fácilmente evitable con limpiezas programadas en horas de menos carga de trabajo. Además desde SQL Server 2019 tenemos un modo de captura CUSTOM que nos permite limitar mucho la información capturada. Tras todo esto, yo solo he visto que pueda generar problemas de rendimiento en servidores con una alta carga de consultas ad-hoc con muchos (muchísimos) batch/sec y, la mayoría de las veces, el problema era solucionable con una correcta configuración de captura de datos y, sobre todo, de la configuración de esos flush interval y mantenimiento de los datos almacenados.

@@SoyDBA Gracias por tu respuesta Roberto, será cuestión de hacer pruebas, la verdad es que no lo he probado nunca. Cuando abordo algún problema de rendimiento me suelo limitar a utilizar consultas a las DMVs, ver planes de ejecución, etc.

Gracias a ti por el comentario.

Existen varias maneras, que con una simple busqueda en google puedes encontrar. Yo no seré quién lo promocione ni te anima a hacerlo. Además ve con CUIDADO porque al hacerlo pierdes el soporte de Microsoft sobre esa base de datos. Sobre todo, no lo hagas JAMAS EN PRODUCCIÓN ya que puede no tener vuelta atrás y puedes incurrir en problemas legales como la empresa lo detecte.

@@SoyDBA jeje gracias por las advertencias, solamente era para hacer el lab. Me gusta hacer con mis manitas los ejercicios que veo en videos. Saludos!

@@totanlj18 mándame un mail a la dirección que tengo en el blog o escríbeme por LinkedIn y te lo paso

Por norma general no afecta al rendimiento. Me explico, tu puedes poner los filtros del WHERE en el HAVING (al revés no funciona), eso quiere decir que el motor de base de datos, al compilar la consulta va a detectar que eso es un filtro que debería ir en el WHERE y lo va a hacer antes del GROUP BY por lo tanto el orden lógico de ejecución de la consulta no se altera y por consiguiente tampoco el rendimiento. Si no fuese así, el menor de tus problemas sería el rendimiento, ya que el filtro no aplicaría antes del GROUP BY y el resultado no sería correcto.

Gracias por tu feedback, me alegro que te haya gustado.

Claro, en este caso tienes bloqueos porque tienes la configuración por defecto en tu base de datos y tiene un nivel de aislamiento READ COMMITTED, con un READ COMMITTED SNAPSHOT no tendrías ese problema ya que, mientras dura la actualización, se almacena el dato anterior en TempDB y cuando otra consulta lo quiere leer accede directamente a ese. De esta manera siempre vas a leer un dato confirmado y a la vez no tienes bloqueos. En los artículos que enlazo en la descripción del video lo explico más en detalle.

@@SoyDBA muchisimas gracias, por contestar y tu gran aporte, voy a leer, ahora mismo estoy buscando rendimiento y segun tu contestación entiendo porque se me bloquean, y a veces hastta tengo que reiniciar el servicio, yo uso 4 store procedure en los cuales uso tablas tipo variables no se si será esto tambien, al grabar envio unos parametros mas un xml este lo pongo en una variable tipo tabla y luego lo paso a las tablas en producción, sql server 2017.

@@servicioinformaticods y por qué has llegado al nolock? Has visto que los tiempos de espera mayoritarios son por bloqueos? Tienes un buen plan de mantenimiento de índices y estadísticas? Has visto en query store cuales de tus consultas son las que más consumen y las has optimizado ya? De todo esto tienes videos en el canal. Dale una vuelta y verás como mejora la cosa.

No es una sintaxis sencilla. Yo cuando comencé a aprenderla tuve que ver muchos ejemplos y casos de uso. Y al final solo terminas aprendiéndolo de verdad con el uso. Y cuando dejas de usarlo se te termina olvidando pero, no pasa nada, lo importante es saber que se puede hacer. Para buscar la sintaxis siempre tendrás este y otros cientos de videos y ya no hablemos de artículos escritos...

Gracias por el comentario @yerkolopez3467 Me alegro que te guste. Permanece atento al canal que esta semana saldrá otro vídeo de esta serie y la semana que viene otros dos. Y así las próximas semanas hasta que lleguemos al final del programa que me he marcado para esta serie. También puedes encontrar todo el soporte que necesites en nuestro canal de Telegram SQL Server Español (enlace en la descripción de este video).

Gracias por el comentario Saray. Me alegro que te guste. Permanece atenta al canal que esta semana saldrá otro vídeo de esta serie y la semana que viene otros dos. Y así las próximas semanas hasta que lleguemos al final del programa que me he marcado para esta serie.

Gracias 👍

Muchas gracias por el apoyo Juan Carlos. Un saludo.