Home » Articulos etiquetados por 'SQLServer'
Listado de SQLServer
- Errores Tipicos de bases de datos cometidos por los Desarrolladores
Errores Tipicos de bases de datos cometidos por los Desarrolladores
A la pregunta ¿Cuales son los Errores Típicos de los Programadores con las Bases de Datos?, nos encontramos con un curioso listado de estos problemas típicos. La utilización de Índices, complejas consultas para obtener información, y no revisar el rendimiento a no ser que sea necesario.No utilizar Indices
Aunque es fácil de cumplir, muchas programadores no utilizamos una campo Índice cuando utilizamos consultas con Clausulas WHERE. Es más, si tenemos un campo Índice que utilizamos, pero transformamos el valor mediante TOLOWER o TOUPPER, rompemos el índice y queda inservible.No Forzar la Integridad Referencial
No configuramos las bases de datos mediante "Foreign Key", y dejarle la integridad de datos a la base de datos. Normalmente preferimos programar lo que la Base de Datos ya nos ofrece.Uso Natural de las Claves Primarias
Siempre estamos tentados a utilizar claves primarias como ID Autonuméricos o Secuencias, en lugar de utilizar campos únicos naturales en la funcionalidad del Negocio. Como por ejemplo el NIF, Email, etc. Más fácil de utilizar.El Uso de escribir Consultas con DISTINCT
El DISTINCT obliga a que no se recuperen filas duplicadas. Lo cual suele significar que existen errores de base y que deberían solucionarse. El Distinct podría utilizarse de forma provisional, pero hay que tener en cuenta que el Rendimiento de la consulta se ve afectada.Favorecer la Agregación en lugar de los JOINS
Normalmente se usan sentencias GROUP BY y HAVING TO en lugar de utilizar los JOINS. Esto implica en un alto coste en el rendimiento de la consulta ¡Haced la Prueba!No Simplicar consultas complejas en Vistas
Aunque nuestra cabeza de desarrollador nos facilita la tarea de abstraer y dividir complejos métodos en funciones. No tenemos este aspecto interiorizado en las Bases de Datos. La creación de Vistas simplifica la complejidad y nos ayuda a realizar otro tipo de consultas relacionadas.No Normalizar suficiente o Normalizar Demasiado
La Normalización no es una Técnica Exacta, y siempre tenemos que tener el sentido Común presente. Cuando grabamos Arrays en las Bases de Datos, estos valores deberían estar relacionados mediante tablas con sus correspondientes filas. Por contra, el exceso en la normalización provocará que las consultas tengan que tener demasiados JOINS para obtener los datos.Relaciones Exclusivas
Cuando se relacionan tablas mediantes Foreign Keys, pero sólo uno de los campos puede ser Not-Null. Las Foreign Key deberían ser Not-Null, sino puede provocar serios problemas en la integridad de los datos.El uso de OR en lugar de AND
Con un AND se puede hacer los mismo que un OR, pero es más restrictivo y mucho más eficiente.No diseñar Modelos para el Alto Rendimiento
Cuando para obtener datos sencillos se tienen que generar complejas consultas, es debido a que existe un problema de base en el modelo de la base de datos. Visto en Database development mistakes made by application developers... - Como Saber la Version del SQLServer y su Service Pack
Como Saber la Version del SQLServer y su Service Pack
Consulta SQL para obtener version SQL Server y su SP (Service Pack). Cuando las personas de Sistemas y de Desarrollo no son las mismas, es interesante saber que versión exacta de SQL Server tenemos instalada, porque podemos encontrarnos con el típico comentario "En mi Ordenador Funciona".Consultas para Obtener Version SQL Server
SELECT LTRIM(RIGHT(LEFT(@@VERSION,38),9))
SELECT 'SQL Server ' + CAST(SERVERPROPERTY('productversion') AS VARCHAR) + ' - ' + CAST(SERVERPROPERTY('productlevel') AS VARCHAR) + ' (' + CAST(SERVERPROPERTY('edition') AS VARCHAR) + ')'
Desde el Registro
HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ MSSQLServer\ HotFixes\
Más información en sqlserver2000.databases.aspfaq y en support.microsoft... - Que es el TOP 100 PERCENT de SQL Server
Que es el TOP 100 PERCENT de SQL Server
Que es la sentencia TOP n PERCENT y porque se inserta al crear vistas en SQL SERVER. En ocasiones cuando creamos las vistas desde SQL Server, nos inserta la sentencia TOP al principio de la vista, sobretodo cuando existe un "Order By", si tratamos de quitar este código la vista no puede ser creada.Sentencia TOP SQL Server
La Sentencia TOP sirve para limitar el número de filas devueltas por la consulta, ejemplo
Devuelve las 100 primera filas de la consulta, además se puede utilizar la palabra PERCENT para indicar un porcentaje de filas a devolver. Si esta limitación se combina con un "Order By", el resultado devolverá las primeras filas seleccionadas de la consulta ya ordenada. via MsdnSELECT TOP 100 FROM MyTablePorque se inserta TOP 100 PERCENT
La sentencia ORDER BY es una sentencia estándar del SQL ANSI. Pero cada base de datos amplia este lenguaje para ayudar a los desarrolladores, dando funcionalidades no estándars. SQL Server ha ampliado el uso del ORDER BY para que se pueda utilizar en otros lugares, como subconsultas, una ampliación que no pertenece al estándar. Este cambio ha provocado que el ORDER BY en SQL Server no ofrezca garantías de ordenación en algunos casos, cuando el estándar SQL define que si se utiliza un ORDER BY debe mostrarse las filas ordenadas. Podemos ver la explicación y un ejemplo de esto en el Blog.Msdn, donde nos ilustran y nos comentan que el uso del TOP y ORDER BY es considerado dañino, ya que puede que el resultado no sea el esperado. La siguiente consulta no garantiza el orden, además de que
En cambio, esta consulta si que garantiza el ordenSELECT TOP 99 PERCENT * FROM T ORDER BY col1
La recomendación es siempre poner el ORDER BY en el SELECT más exterior posible, ya que los ORDER BY en subconsultas anidadas no garantizan un orden correcto. Por definición de SQL Server, no se permiten ORDER BY en las vistas, ya que es similar a una tabla que por definición es un conjunto de filas. Para conseguir el resultado de una vista ordenado se le incorpora el TOP 100 PERCENT, aunque la mejor manera seríaSELECT * FROM (SELECT TOP 99 PERCENT * FROM T ORDER BY col1) AS A
Ahora cada cual utilice la forma que más le convezca para obtener las filas ordenadas de una vista....SELECT * FROM VIEW_EXAMPLE ORDER BY MYFIELD - Como escribir desde Base de Datos a un Fichero Fisico con SQL Server
Como escribir desde Base de Datos a un Fichero Fisico con SQL Server
Manipulación de ficheros de texto desde base de datos. Una opción sería crear logs de fichero desde la base de datos, aunque lo normal sería utilizar la propia base de datos para registrar trazas, en ocasiones puede ser una alternativa para funcionalidades específicas. Por ejemplo, en procedimientos automáticos que se ejecutan con tareas programadas o con el servicio SQL Agent de SQLServer. Por si en algún momento nos encontramos con la necesidad de manipular, crear o insertar texto en ficheros físicos (también podría servir para ficheros XML), vamos a crear un procedure de base de datos WRITE_TO_FILE para manipular ficheros, con los siguientes parámetros: Mensaje Ruta Nombre_Fichero... - Donde encuentro los estilos de Fecha DateTime para SQL Server
Donde encuentro los estilos de Fecha DateTime para SQL Server
Los Estilos de Formato de fecha para SQLServer (DateTime Format styles). Siempre que queremos hacer un Cast o un Convert nos encontramos con el dichoso formato de fecha, que cada ordenador tiene configurado (en función del "Regional Language" del panel de Control). Tantos dolores de cabeza y tantas "Chapuzas" que hemos podido hacer los desarrolladores cuando se trata de almacenar y recuperar fechas, y todo para solucionar incidencias con fecha de ayer. El Objetivo del Artículo es encontrar los diferentes estilos de fechas disponibles en SQL Server cuando queremos realizar una conversión a String.DateTime Formats Styles SQL Server
Without century (yy) (1)
With century (yyyy)
Standard
Input/Output (3)
-
0 or 100 (1,2)
Default
mon dd yyyy hh:miAM (or PM)
1
101
U.S.
mm/dd/yyyy
2
102
ANSI
yy.mm.dd
3
103
British/French
dd/mm/yyyy
4
104
German
dd.mm.yy
5
105
Italian
dd-mm-yy
6
106(1)
-
dd mon yy
7
107(1)
-
Mon dd, yy
8
108
-
hh:mi:ss
-
9 or 109 (1,2)
Default + milliseconds
mon dd yyyy hh:mi:ss:mmmAM (or PM)
10
110
USA
mm-dd-yy
11
111
JAPAN
yy/mm/dd
12
112
ISO
yymmdd
yyyymmdd
-
13 or 113 (1,2)
Europe default + milliseconds
dd mon yyyy hh:mi:ss:mmm(24h)
14
114
-
hh:mi:ss:mmm(24h)
-
20 or 120 (2)
ODBC canonical
yyyy-mm-dd hh:mi:ss(24h)
-
21 or 121 (2)
ODBC canonical (with milliseconds)
yyyy-mm-dd hh:mi:ss.mmm(24h)
-
126 (4)
ISO8601
yyyy-mm-ddThh:mi:ss.mmm (no spaces)
-
127(6, 7)
ISO8601 with time zone Z.
yyyy-mm-ddThh:mi:ss.mmmZ
(no spaces)
-
130 (1,2)
Hijri (5)
dd mon yyyy hh:mi:ss:mmmAM
-
131 (2)
Hijri (5)
dd/mm/yy hh:mi:ss:mmmAM
Tabla extraída del MSDN que explica las conversiones entre tipos, las funcionales y las implícitas.... - Diferencias entre Char, Varchar, NChar y NVarchar en SQL Server
Diferencias entre Char, Varchar, NChar y NVarchar en SQL Server
Las diferencias a la hora de escoger campos Varchar, NVarchar, Char o NChar. Es importante la diferencia existente para configurar la base de datos de la forma más óptima. Ya que dependiendo del tipo de campo "String" que configuremos, la capacidad o la información puede variar.Char y NChar
Cuando se configura un campo de tipo Char o NChar estamos indicando campos de tamaño fijo. Es Decir, si configuramos una tabla de la siguiente forma
La diferencia entre Char y NChar es el soporte a carácteres Unicode (los carácteres Unicode ocupan más de 1 byte). Por este motivo a la hora de almacenar algún valor, en el Campo1 siempre ocupará 10 bytes y en el Campo2 20 Bytes.Campo1 Char(10), Campo2 NChar(10)Varchar o NVarchar
Los campos de tipo Varchar o NVarchar son de almacenamiento variable. Es decir, si configuramos una tabla de la siguiente forma
El tamaño almacenado dependerá del valor que se quiere guardar, el número de carácteres sólo configura el tamaño máximo que este campo puede almacenar. En el caso del CampoVariable1 el tamaño máximo será de 10 bytes, y en el caso del CampoVariable2 el tamaño máximo será de 20 bytes.CampoVariable1 Varchar(10), CampoVariable2 NVarchar(10)Unicode o No Unicode
Dependiendo de la información que queremos almacenar en nuestra base de datos, tendremos que definir si permitimos o no valores Unicode (Por ejemplo diferentes idiomas como el Ruso, Japonés, chino, ...). Existen tablas de codificación de caracteres (Encodings) que poseen carácteres específicos de Doble Byte. Esto puede afectarnos a la hora de utilizar campos de tipo Char o Varchar, ya que un texto de 10 carácteres podría superar los 10 bytes, haciendo imposible la insercción del valor a la base de datos.Recomendación
Siempre que dudemos utilizar los campos Varchar y NVarchar, ya que al ser de almacenamiento de tipo variable, sólo ocupará lo que realmente necesitamos. Después habría que analizar si necesitamos almacenar carácteres Unicode o no, y que tabla de codificación vamos a utilizar. Si el Encoding es ASCII, no hace falta que sea Unicode el almacenamiento, pero en caso contrario, recomendaría NVarchar, por seguridad y evitar posibles futuros problemas. Para más información consultar Char, Varchar y NChar, NVarchar... - Caracteres especiales en un Like SQL Server
Caracteres especiales en un Like SQL Server
Los caracteres especiales que acepta una sentencia Like en SQLServer. Cuando en la clausula Where de una sentencia SQL queremos realizar búsquedas más personalizadas, lo normal es utilizar un LIKE, aunque esto perjudique al rendimiento, en algunas ocasiones no tenemos otra que utilizarlo.
Más información en LIKE (Transact-SQL)...% Cualquier cadena de cero o más caracteres. _ (carácter de subrayado) Cualquier carácter. [ ] Cualquier carácter individual del intervalo o conjunto que se ha especificado dentro de [*] <em>(Ej. [a-f] o [abcdef])</em> [^] Cualquier carácter individual que no se encuentre en el intervalo o conjunto especificado <em>(Ej. [^a-f] [^abcdef])<(em> - Altos picos de CPU en el servidor por w3wp.exe, IIS, mcshield.exe o SQLServer
Altos picos de CPU en el servidor por w3wp.exe, IIS, mcshield.exe o SQLServer
Todo comenzó un gran día, digamos que una nueva oportunidad para seguir aprendiendo. El escenario son varios servidores con distintas aplicaciones web que utilizan SQL Server, y el Problema es por el rendimiento (como siempre suele pasar, que la CPU se pone al 100% provocando la desesperación del usuario). Lo primero es identificar las diferentes partes y saber quien se pone al Rojo Vivo, en nuestro caso las opciones eran: w3wp.exe, sqlserver, mcshield.exe o "vete tu a saber".w3wp o Pool de Aplicaciones
En un Servidor IIS, es recomendable utilizar diferentes Pools de Aplicaciones (el proceso que se crea se llama w3wp.exe), pero en ocasiones la página web puede provocar una saturación el servidor. El problema es que si tenemos varios Pools de aplicaciones es difícil saber quien es quien a simple vista, pero siguiendo las instrucciones para saber que pool es el causante, podemos saberlo. Plan de acción Podemos configurar en Propiedades - Rendimiento, opciones tan útiles como "Supervisión de la CPU" para configurar un % máximo, y el "Hospedaje multiproceso" si fuera necesario. Arreglar la aplicación web, porque tiene un problemaMcshield o Internet Security de McAffe
Mcshield.exe es un proceso del McAffe, por lo que es necesario y recomendable, pero como tiene prioridad Alta en el sistema, cuando se pone a trabajar satura al resto. Algunas versiones del McAffe tienen bugs y pérdidas de memoria (como muchos programas), pero es posible que el motivo de que se ponga al 100% sea otro. Puede ser cualquier cosa, así que hay que ir poco a poco revisando las diferentes opciones. Uno de los motivos más simples y sencillos, es porque esta analizando los ficheros de logs de nuestras aplicaciones webs en tiempo real. (parte de nuestros quebradores de cabeza). Sólo tendremos que configurarlo para que excluya aquellos ficheros y carpetas que solemos usar normalmente. Análisis de diferentes tipos de Scripts "ScanScripts", como el Javascript, en tiempo real Análisis del Desbordamiento del Buffer, esto puede provocar pérdida de memoria en algunas versionesSQL Server
SQL Server son las bases de datos de Microsoft, muy esparcida y utilizada. En ocasiones se pone al 100% de CPU y alcanza memorias soñadas para muchos de nosotros. En principio, si con la instalación por defecto funciona bien ¡No la toques!, sino puedes. Configurar una memoria máxima cuando el servidor no esta dedicado para base de datos exclusivamente y se comparte con otras aplicaciones. De esta forma no dejará el servidor sin memoria. Utilizar el Analizador o Profiler del SQL Server para ver que consultas están provocando el problema. Llamar a un DBA (yo no lo soy), pero me baso en que si el SQLServer se pone al 100% es por algo, así que la pesquisa es que es una aplicación quien le esta achuchando, hay que identificarla y ver si lo que hace es correcto o no.Conclusiones
Espero que os sea de Ayuda, si es así "De nada". Normalmente estos problemas del 100% de CPU se solucionan a base de trabajo, pocas veces tenemos golpes de suerte porque suelen influir varios factores. Así que esto no es ninguna biblia, sino más bien un punto de inicio (por lo menos a mi ya me sirve).... - Como Obtener nvarchar de una Función o un Procedure en SQL Server
Como Obtener nvarchar de una Función o un Procedure en SQL Server
Podemos definir un stored procedure o una function dentro de nuestra base de datos sql server para que nos devuelve los valores que necesitamos, todo depende de la necesidad y de la estructura que queramos darle. Todo es cuestión de gustos y "colores".Function
Tendrá una estructura similar aLa Función tendrá una estructura similar a CREATE FUNCTION FooFunc(@ID int) RETURNS nvarchar(10) AS BEGIN DECLARE @FOO nvarchar SELECT @FOO=MyColumn FROM MyTable WHERE id=@ID RETURN @FOO ENDProcedure
El Procedure puede tener un Return, pero mi sospecha es que sólo puede devolver valores de tipo int o similares (Esta es mi sospecha). Normalmente se suele usar para devolver el @@Identity.
Pero si queremos devolver un nvarchar tenemos que utilizar un parámetro de salidaCREATE PROCEDURE FooProc @ID int AS BEGIN INSERT INTO MyTable VALUE ('myvalue') RETURN @@Identity ENDCREATE PROCEDURE FooProcOutput @ID int @OUT nvarchar(10) OUTPUT BEGIN SELECT @OUT =MyColumn FROM MyTable WHERE id=@ID ENDAhora Como llamamos a los Stored para Obtener el Resultado
Si queremos saber además como realizar estas llamadas desde C# y Obtener los valores pertinentes, podemos echar un vistazo a sqlteam, que es la página que me sirvió a mi para averiguar todo esto....--Para una función se realiza desde una Select DECLARE @EXT nvarchar(10) SELECT @EXT = FooFunc(1) --Para un Procedure tenemos dos opciones, con ReturnValue o un Parámetro tipo Output --Utilizando el ReturnValue DECLARE @ReturnValue int EXEC @ReturnValue = FooProc 1 -Utilizando el Output Parameter DECLARE @ReturnValue nvarchar(10) EXEC FooProcOutput 1, @ReturnValue OUTPUT