Last week we had an internal event called GeekReady, where PFE’s all over LATAM (Latin America) could get together to hear from the management team the latest updates, acquire and share knowledge, meet with new-hires and reunite with old friends (which in our case is great, as we usually are constantly travelling)!!!
On this 3-day event, which happened in Hotel Sofitel Jequitimar in Guaruja Beach-SP (Brazil), 120 sessions were presented in different tracks like Database, Development, Platform, SharePoint & IIS, IT OPS, Manageability and Messaging, with PFE’s from Argentina, Brazil, Canada, Chile, Colombia, Ecuador, El Salvador, USA, Mexico, Panama, Peru, Puerto Rico and Venezuela. The experience sharing was awesome, and we still had some free-time to enjoy the beach in the middle of the week!!! =)
Yeah, even working we have lots of fun during the event, returning to home with our batteries recharged, and really READY to face new challenges!!! =)
Traduciendo a Español el post de nuestro colega Eduardo Nakahara!
La semana pasada tuvimos un evento interno llamado GeekReady, donde los PFE's de todo LATAM (Latinoamérica) nos reunimos para escuchar las últimas noticias de la organización PFE de parte del equipo de administración, adquiriendo y compartiendo conocimiento, conociendo a los nuevos PFE's y reuniéndonos con los viejos amigos (lo que en nuestro caso es genial, pues generalmente estamos viajando)!!!
En éste evento de 3 días, que tuvo lugar en el Hotel Sofitel Jequitimar en la playa de Guaruja en Sao Paulo (Brasil), 120 sesiones fueron presentadas para diversas tecnologías como Base de Datos, Desarrollo, Plataforma (Windows, AD, etc), SharePoint y IIS, IT OPS, Servicios de Administración y Mensajería, con PFE's de Argentina, Brasil, Canadá, Chile, Colombia, Ecuador, El Salvador, USA, México, Panamá, Perú, Puerto Rico y Venezuela. La experiencia fue impresionante, y aun a pesar de todo tuvimos tiempo libre para disfrutar de la playa a mitad de la semana!!! =)
Impresionante no lo creen?, aun trabajando nos divertivmos bastante durante el evento, regresando a casa con las baterías recargadas, y realmente LISTOS para enfrentar nuevos retos!!! =)
Saludos Comunidad,
Entregando para ustedes un resumen simple del proceso de migración a SharePoint 2010 desde una granja de MOSS 2007, debido a que muchos usuarios de SharePoint se encuentran en este proceso y de pronto leer tanta documentación es un poco complicado por el tiempo que consume la operación diaria, espero les sea de utilidad:
Partiendo del diagrama abajo mostrado resumiremos las actividades propias de la migración:
Aprendizaje:
- Determinar cuáles son los requerimientos para la migración, por ejemplo tener instalado Service Pack 2 para SharePoint Technologies
- Preupgradecheck para determinar cuáles pueden ser los posibles problemas que pudiéramos enfrentar (psconfig -cmd preupgradecheck, solo disponible en SP2)
- Que método de migración escogeremos, Inplace, DB Attach o Hybrid (http://technet.microsoft.com/en-us/library/cc263447.aspx)? Tengo los recursos para realizar un Hybrid y minimizar el tiempo de la migración?
- Identificar problemas comunes en el proceso de migración como el ambiente nuevo de SharePoint 2010 no esta preparado correctamente o bien no hay un Capacity Planning.
- Formas soportadas para la migración:
Preparación:
- Inventario completo: Customizaciones (Master Page, Temas), Definiciones de Sitios, Plantillas, Paquetes de Soluciones (wsp), Codigo personalizado (Web.Config), SPSFarmReport (http://spsfarmreport.codeplex.com/ - Mini Inventario)
- Las personalizaciones deben ser probadas y aprobadas en un ambiente de SP2010 que no será el de producción
- La migración contempla reestructuración de Sitios, Colecciones de Sitios, Aplicaciones Web, Listas, Bibliotecas de documentos?
- Se usan web parts de terceros que no están soportadas en SP2010, hay elementos Flash? Si fuera el caso se requiere soporte para las web parts y convertir los objetos Flash a Silverlight (Usar herramientas de terceros es una opción). Revisar también (http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.webpartpages.silverlightwebpart(office.14).aspx)
- Generar plan de capacidades (http://technet.microsoft.com/en-us/library/ff758645.aspx) para la nueva granja de SharePoint 2010, que servicios se brindaran y cuales deberán permanecer apagados
Pruebas:
Una vez determinado lo anterior y revisados cada uno de los elementos que componen la granja actual es necesario comenzar la fase de pruebas
- Construir una granja de SharePoint 2010 de pruebas y utilizar bases de datos de producción para realizar las pruebas
- Evaluar técnicas de migración, por ejemplo es necesario usar Central Administration para montar las bases de datos o es preferible PowerShell, ambas alternativas son útiles, pero es preferible usar PowerShell
- Usar Test-SPContentDatabase (http://technet.microsoft.com/en-us/library/ff607941.aspx) para validar que las bases de datos de contenido pueden ser migradas exitosamente y no existen elementos no instalados en la nueva granja de SharePoint 2010
- Adjuntar las bases de datos utilizando Visual Upgrade (-updateuserexperience / http://technet.microsoft.com/en-us/library/ff607813.aspx / http://technet.microsoft.com/en-us/library/ff607581.aspx)
Implementación
Habiendo superado todos los pasos anteriores entonces se habrá de crearla nueva granja de SharePoint 2010 que será la definitiva
- Basado en el plan de capacidades previo: generar la nueva topología y arquitectura de SharePoint 2010, servidores virtuales o físicos, si son virtuales revisar el modelo de virtualización para SharePoint 2010 (http://technet.microsoft.com/en-us/sharepoint/ff602849.aspx; http://technet.microsoft.com/en-us/library/ff621103.aspx)identificando que roles pueden ser virtualizados y cuales no es recomendado
- Instalar e implementar todas las customizaciones previamente identificadas
- Una vez que se determinaron los posibles problemas, el tiempo de baja del servicio podrá ser reducido, es posible utilizar AAM Redirection en conjunción con READ-ONLY para las bases de datos (http://technet.microsoft.com/en-us/library/ee720448.aspx / http://technet.microsoft.com/en-us/library/dd793608(office.12).aspx)
- Monitorear el proceso de migración puede llegar a ser extenuante, por lo que se sugiere establecer un grupo de monitoreo para la migración donde se asignen tareas especificas
Validación
Al final es importante revisar
- Logs de migración y ULS
- Revisar cada elemento mediante la interface gráfica para garantizar que todo esta OK
- Validar que la información migrada es efectivamente la información que existía en la granja de SharePoint 2007
Suerte
Hola que tal, sean todos bienvenidos al nuevo blog del equipo de PFEs (Premier Field Engineers - Ingenieros de Soporte Premier) para Latinoamérica y ISS (Incubation Support & Services - Incubación, Soporte y Servicios).
El propósito de este Blog, es compartir el conocimiento y la experiencia de los distintos PFEs de Latinoamperica a travéz de este medio., y al decir compartir no sólo nos referimos a compartir conocimientos técnicos sino de experiencia del día a día con lo que hacemos. Los Ingenieros de Soporte Premier (PFE) somos Ingenieros de Microsoft con gran experiencia técnica en los distintos productos y tecnologías de Microsoft, y que formamos parte del gran grupo de CSS (Customer Support & Services) dentro de la compañía. De igual forma también contaremos con la participación del equipo de proyectos de incubación y soporte -ISS- quietes tienen también mucha información y experiencia que compartir.
En este Blog podrán encontrar información de distintos temas e intereses en distintas formas como Artículos, WebCasts etc, y organizados de la siguiente manera:
Esperamos sea de su agrado y los invitamos a que nos compartan sus comentarios para nuevo contenido.
NOTA: Por ningnún motivo este Blog planea suplantar las ya existentes y variadas formas de soporte técnico de Microsoft, es únicamente un medio para poder conocer a los PFEs y aprender de ellos.
Atte
Equipo de Social Media PFE Latinoamerica
¿Qué es Integration Services?
Es una herramienta que permite obtener datos de diversas fuentes, transformarlos y cargarlos a bases de datos, hojas de trabajo, archivos de texto u otro destino que sea compatible con OLE-DB.
Historia
En las versiones SQL Server 7 y 2000, las capacidades de ETL (Extracción, Transformación y Carga) eran provistas por Data Transformation Services (DTS)
A partir de SQL Server 2005, Microsoft decidió que la gran variedad de innovaciones implementadas en la nueva versión justificaban el nuevo nombre. Como resultado surgió SQL Server Integration Services (SSIS)
Mejoras en la versión 2012 de SSIS
Cambios generales en la interfaz
1. Caja de herramientas de SSIS
La caja de herramientas de SSIS te permite agregar treas y componentes del flujo de data a un paquete, en vez de usar la caja de herramientas de Visual Studio, que se utiliza en versiones anteriores. Además incluye una descripción para el ítem que está seleccionado. También incluye dos categorías: Favoritos y Común.
2. Parámetros
El diseñador del paquete incluye una nueva lengüeta para abrir la ventana de los parámetros para un paquete. Los parámetros permiten que usted especifique los valores en tiempo de ejecución para el paquete, el contenedor, y las propiedades de la tarea o las variables.
3. Botón de variable
Este nuevo botón en la barra de herramientas del diseñador del paquete proporciona el acceso rápido a la ventana de las variables.
4. Botón de Caja de herramientas de SSIS
Este botón permite que usted abra la caja de herramientas de SSIS cuando no es visible.
5. Comenzando (Getting Started)
Proporciona el acceso a los enlaces de los vídeos y los ejemplos que usted puede utilizar para aprender a trabajar con Integration Services.
6. Control de Acercamiento (Zoom control)
Usted puede acercar o alejar a un tamaño máximo de 500 por ciento de la visión normal o a un tamaño mínimo del 10 por ciento, respectivamente.
7. Administrador de Conexiones Compartidas (Shared Connection Managers)
La carpeta Administrador de Conexiones es un nuevo contenedor que puede ser compartido entre múltiples paquetes. Para crear un nuevo Administrador de Conexiones compartidas siga los siguientes pasos:
8. Deshacer y Rehacer (Undo / Redo)
Estas opciones fueron añadidas como parte de las herramientas de datos de SQL Server. A través de esta opción se puede editar el control de flujo o flujo de datos y revertir o reaplicar los cambios. Estas opciones también funcionan en la ventana de variables, en el manejador de eventos y parámetros. Se puede utilizar Ctrl+Z para Deshacer o Ctrl+Y para reaplicar.
9. Paquetes ordenados por Nombre
Los paquetes pueden ser ordenados por nombre al presionar el botón de la derecha del ratón sobre la carpeta Paquetes de SSIS.
10. Indicador de estatus
La interfaz del usuario ahora presenta íconos en la esquina superior derecha de cada ítem para indicar si la ejecución fue exitosa o fallida.
Control de flujo
1. Tarea de Expresión
El propósito de esta tarea es el facilitar la asignación de un valor dinámico a una variable.
2. Tarea de Ejecución de Paquete
Esta tarea incluye una nueva propiedad llamada Tipo de Referencia que permite especificar la localización del paquete a ser ejecutado. Si se selecciona Referencia del Proyecto, usted podrá seleccionar el paquete hijo desde una lista. Si se selecciona Referencia Externa, usted podrá configurar la ruta del paquete hijo como se hacía en versiones anteriores.
Flujo de Datos
Entre las mejoras se encuentran:
1. Los Asistentes para la selección de fuentes y destinos.
2. Transformaciones de Merge y Merge Join
Estas transformaciones permiten recolectar datos de dos fuentes y producir una sola salida de los resultados combinados. La versión actual se ajusta automáticamente a las presiones de memoria.
3. Transformación de Limpieza de Datos para DQS
Es un nuevo componente que se usa en conjunto con Data Quality Services (DQS)El propósito es ayudar a mejorar la calidad de los datos a través de reglas establecidas para el dominio de los datos. Se pueden crear reglas para hacer pruebas a los datos por errores comunes como errores de escritura en un campo tipo texto o asegurar que el largo de una columna cumple con las especificaciones.
4. Grupo que puede ser Colapsado
Permite consolidar los componentes del flujo de datos en grupos que pueden expandir o colapsar. Para crear un grupo, siga los siguientes pasos:
Transferencia del Proyecto (Deployment)
En SSIS 2012 se utiliza un proyecto el cual es almacenado en un archivo con la extensión ISPAC. El proyecto es una colección de paquetes y parámetros. Usted puede transferir el proyecto a un catálogo de Integration Services. A diferencia de versiones anteriores donde se utilizaban configuraciones, en esta versión se utilizan parámetros para asignar valores a las propiedades del proyecto en tiempo de ejecución. Antes de ejecutar un paquete, se debe crear un objeto de ejecución en el catálogo y opcionalmente asignarle valores a los parámetros o hacer referencia al ambiente del objeto de ejecución.
El catálogo de SSIS esencialmente es una aplicación de SQL (una base de datos del usuario en una instancia de SQL con un conjunto de procedimientos almacenados y un API de T-SQL.
Creación del catálogo
El instalar Integration Services no crea automáticamente el catálogo. Para crear el catálogo hay que realizar los siguientes pasos:
1) En SQL Server Management Studio, conéctese a la instancia, presione el botón de la derecha del ratón sobre la carpeta de Integration Services en el Explorador de Objetos y seleccione Crear el Catálogo.
2) En la pantalla de Creación del Catálogo, seleccione la opción de habilitar la integración CLR. Esta opción es requerida para administrar la funcionalidad de Integration Services.
3) Opcionalmente se puede seleccionar la opción de Ejecución automática de Procedimientos Almacenados de Integration Services. Este procedimiento almacenado realiza una operación de limpieza cuando el servicio se ejecuta y ajusta el estatus de los paquetes que fueron ejecutados cuando el servicio es detenido.
4) El nombre de la base de datos no puede ser cambiado (SSISDB) así que como paso final se requiere proveer una contraseña compleja y presionar OK. La contraseña crea una llave maestra a nivel de base de datos que es utilizada por Integration Services para cifrar los datos sensitivos que han sido almacenados en el catálogo.
Herramientas para detección de fallas y bitácoras
Los reportes de Integration Services localizados en SQL Server Management Studio proveen información a cerca de los resultados de ejecución de los paquetes en las últimas 24 horas. Estos incluyen información de rendimiento y mensajes de error para el caso de los paquetes fallidos.
Cambios en el formato de los paquetes
La meta de estos cambios fue el facilitar la lectura e identificar más fácilmente las diferencias cuando se trabaja con sistemas de control de fuentes.
Formato de SSIS 2008
Formato de SSIS 2012
Resumen
Unos de los cambios mayores es la introducción del modelo de proyecto para simplificar los cambios a los valores del paquete en tiempo de ejecución. Un beneficio de este modelo es el catálogo. El catálogo almacena información a cerca de paquetes, validaciones, y resultados de ejecución en tablas que pueden ser consultadas a través de vistas o de reportes. El acceso a la información nos provee de una gran visibilidad de Integration Services lo cual no era posible realizar fácilmente en versiones anteriores.
“Las opiniones e ideas expresadas en este blog son las de los Autores y no necesariamente declaran o reflejan la opinión de Microsoft”
Este material tambien lo podras acceder en http://blogs.technet.com/b/sql_pfe_latam/
What is Integration Services?
SQL Server Integration Services (SSIS) is a tool to allow for gathering of data from diverse sources, scrubbing and homogenizing the data into a format for unified use, and loading that data into databases, spreadsheets, text files, or any other OLE-DB compliant destination.
History
In SQL Server 7.0 and 2000, ETL capabilities have been provided by Data Transformation Services (DTS). With the advent of SQL Server 2005, Microsoft decided that a wide range of ETL related innovations implemented in the new version justified its re-branding, resulting in the introduction of SQL Server Integration Services (SSIS).
SQL 2012 SSIS Enhancements
General Interface Changes
SSIS Toolbox: The SSIS Toolbox add tasks and data flow components to a package, rather than the Visual Studio toolbox that you use in earlier versions of Integration Services.
Parameters: The package designer includes a new tab to open the Parameters window for a package. Parameters allow you to specify run-time values for package, container, and task properties or for variables.
Variables button: This new button on the package designer toolbar provides quick access to the Variables window.
SSIS Toolbox button: This button allows you to open the SSIS Toolbox when it is not visible.
Getting Started: Provides access to links to videos and samples that you can use to learn how to work with Integration Services.
Zoom control: You can zoom in or out to a maximum size of 500 percent of the normal view or to a minimum size of 10 percent, respectively.
Shared Connection Managers: The Connections Manager folder is the new container for connection managers that you want to share among multiple packages. To create a shared connection manager, follow these steps:
Undo and Redo: Is the newly added ability to use Undo and Redo while developing packages in the SQL Server Data Tools.You can now make edits in either the control flow or data flow designer surface, and use Undo to reverse a change or Redo to restore a change that you had just reversed. This capability also works in the Variables window, and on the Event Handlers and Parameters tabs. You can also use Undo and Redo when working with project parameters. You can also use Ctrl+Z for Undo or Ctrl+Y for Redo
Package Sort By Name: Sort the list of packages without closing the project by right-clicking the SSIS Packages folder, and selecting Sort By Name.
Status Indicators: The user interface now displays icons in the upper-right corner of each item to indicate success or failure
Control Flow
Apart from the general enhancements to the package designer interface, there are two notable updates for the control flow.
Expression Task: The purpose of this task is to make it easier to assign a dynamic value to a variable.
Execute Package task: Include a new property, ReferenceType, which you use to specify the location of the package to execute. If you select Project Reference, you then choose the child package from the drop-down list. If you select External Reference, you configure the path to the child package just as you do in earlier versions of Integration Services.
Dataflow
The data flow also has some significant updates. Some user interface changes have also been made to simplify the process and help you get your job done faster when designing the data flow.
Source and Destination Assistants: Add the Source Assistant to the data flow design surface by using drag-and-drop or by double-clicking the item in the SSIS Toolbox, which opens the Add New Source dialog box
Merge and Merge Join Transformations: Allow you to collect data from two inputs and produce a single output of combined results. Integration Services introduce a mechanism to better manage memory pressure. This memory management mechanism operates automatically with no additional configuration of the transformation necessary.
DQS Cleansing transformation: Is a new data flow component that you use in conjunction with Data Quality Services (DQS). Its purpose is to help you improve the quality of data by using rules that are established for the applicable knowledge domain. You can create rules to test data for common misspellings in a text field or to ensure that the column length conforms to a standard specification.
Collapsible Grouping: Consolidate data flow components into groups and expand or collapse the groups. To create a group, follow these steps:
Deployment
With this deployment model type, the unit of deployment is a project, stored as an ISPAC file, which in turn is a collection of packages and parameters. You deploy the project to the Integration Services Catalog. Instead of configurations, you use parameters to assign values to package properties at run-time. Before executing a package, you must create an execution object in the catalog and optionally assign parameter values or environment references to the execution object.
This catalog is essentially a SQL application - a user database on a SQL instance (SSISDB) with a set of stored procedures and a T-SQL API.
Catalog Creation: Installation of Integration Services on a server does not automatically create the catalog. To do this, follow these steps:
1. In SQL Server Management Studio, connect to the SQL Server instance, right-click the Integration Services folder in Object Explorer, and select Create Catalog.
2. In the Create Catalog dialog box, select the Enable CLR Integration checkbox. This feature is required to manage Integration Services functionality.
3. Optionally, you can select the Scan For Automatic Execution Of Integration Services Stored Procedure At SQL Server Startup checkbox. This stored procedure performs a cleanup operation when the service restarts and adjusts the status of packages that were executing when the service stopped.
4. Notice that the catalog database name cannot be changed from SSISDB, so the final step is to provide a strong password, and then click OK. The password creates a database master key that Integration Services uses to encrypt sensitive data stored in the catalog.
Logging and Troubleshooting Tools
The built-in reports in SQL Server Management Studio for Integration Services provide information on package execution results for the past 24 hours, performance, and error messages from failed package executions. Hyperlinks in each report allow you to drill through from summary to detailed information to help you diagnose package execution problems.
Package Format Changes
The goal of these changes was to make the SSIS package format easier to read, and easier to diff when working with source control systems.
SSIS 2008
SSIS 2012
Summary
One of the biggest changes is the introduction of the project deployment model to simplify changes to package values at run-time. A side benefit of the project deployment model is the catalog which captures information about packages, validations, and execution results in tables that you can query through views or by using built-in reports. This access to information gives you greater visibility into Integration Services than was not possible in previous versions without extensive customization.
“The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of Microsoft”
Durante una plática con amigos sobre cómo obtener un mejor performance de SQL Server, me hicieron la siguiente pregunta… ¿Existe alguna otra optimización para aplicar a un servidor de SQL Server, aparte de aplicación de Best Practice a nivel de sistema operativo y Aplicación? A lo cual les indique que también se podrían hacer optimizaciones a nivel Hardware, en este caso a nivel Storage.
Con lo anterior, empezamos a explicar el tema de SAN pero enfocándolo a Administradores de Base de Datos.
Son muchos factores los que afectan el buen rendimiento de I/O de los discos, factores como el Discos compartidos o dedicados, niveles de RAID, la velocidad del bus, configuraciones de adaptadores HBA, un punto muy importante que frecuentemente se pasa por alto es la alineación en las particiones de disco.
Algunos de los factores no-disco en los que se puede observar cuellos de botella son:
- HBA (Host Bus Adapters) o tarjetas de interface de red
- Capacidad de procesamiento de FC (Fibre Channel) o puertos iSCSI
- Switch
- Numero de paths entre el servidor y el storage.
Es importante considerar y entender los límites de los componentes envueltos en la arquitectura, algunos de los límites que se tienen establecidos en el mercado son:
Component
Limits
SAS cable
Theoretical: 1.5 gigabytes per second (GB/s)
Typical: 1.2 GB/s
PCI-X v1 bus
X4 slot: 750 MB/s
X8 slot: 1.5 GB/s
X16 slot: roughly 3 GB/s
PCI-X v2 bus
X4 slot: 1.5 – 1.8 GB/s
X8 slot: 3 GB/s
Note: Be aware that a PCI-X bus can be v2 compliant but still run at v1 speeds.
Fibre Channel HBAs, switch ports and front end Fibre Channel array ports
4 gigabits per second (Gbps): 360-400 MB/s
8 Gbps: Double the speed of 4 Gbps
Note: Make sure to consider the limits of the PCI bus. An 8-Gbps card requires a PCI-X4 v2 slot or faster.
Pero, ¿Cómo se liga todo lo anterior con SQL Server? La unidad fundamental de almacenamiento de datos en SQL Server es la página (8KB), el espacio asignado a un archivo de datos (mdf o ndf) de una base de datos se divide lógicamente en páginas enumeradas de forma continua de 0 a n. La operación de I/O de disco se realiza a nivel página.
Los Discos duros están conformados por platos finos y circulares, en su superficie poseen medios de comunicación electrónicos que almacenan información. Cada lado de cada plato cuenta con miles de pistas o tracks, un set de tracks con el mismo diámetro en toda la superficie del plato conforman un cilindro (Para los nuevos dispositivos el concepto de cilindro no es relevante, ya que no están dispuestas en círculos concéntricos, sin embargo es útil entender el origen de los términos). Cada superficie de disco tiene dedicada una cabeza de I/O. Las pistas o tracks se dividen en sectores. Un sector es el fragmento mínimo de datos que se pueden leer o escribir en un disco duro. Las nuevas unidades pueden ofrecer sectores de 1KB, 3KB o 4 KB.
Con la tecnología RAID, la data es repartida a través de un grupo de discos físicos. El esquema de distribución de la data determina como el sistema operativo hace las operaciones de I/O de los datos. La granularidad con la cual la data es almacenada en un disco antes de que la data se almacena en otro de los discos del grupo de llama stripe unit size. La colección de stripe units, desde el primer disco al último del grupo se conoce como stripe.
Pero con todo esto que es la Alineación de las particiones? Y que efecto tiene en el performance de SQL Server??? En el siguiente diagrama se explica.. La línea verticl punteada negra que se superponen a un a la línea de color rojo corresponden a los límites entre diferentes discos físicos de un RAID. Las versiones anteriores a Windows Server 2008 nuestra los 63 sectores reservados reportados por el hardware del disco, inmediatamente después de lo cual el resto de la partición son expuestas al usuario. En la figura, el tamaño común del sector que se utiliza es de 512 bytes. El tamaño del Stripe unit en el ejemplos es de 64 KB, y 4KB para el tamaño de clúster NTFS, adecuado para, un file server. La falta de alineación de discos obliga a que el octavo clúster de 4KB de data se establezca a través de dos stripe units. Iniciando con el último sector vacío de 512 bytes del primer stripe unit y continuando con el segundo stripe unit. Esta situación se perpetua en el resto de la partición, ya que cada cierto numero el clúster de data se establecerá en dos stripe unit, por lo tanto dos I/O son requeridos para realizar una Lectura o Escritura.
El file allocation Unit size (Clúster size) recomendado para SQL Server es de 64KB; esta mejor practica en combinación con la desalineación de disco que existe por defecto fuerza que la data se establezca en dos stripe units, iniciando con el primer sector disponible del primer stripe unit y continuando con el segundo stripe unit. Esta situación es perpetuada en el resto de la partición. En esta configuración, cada clúster es escrito en dos stripe units, esto significa que todas las escrituras y lecturas se ven afectadas
El siguiente es un experimento en el cual se analizó el performance de disco, la prueba se realizó Windows Server 2003 y SQL Server 2005. Se ejecutó un query para extraer la información de SQL Server, durante cada ejecución se aplicó DBCC DROPCLEANBUFFERS para limpiar el buffer cache de SQL Server, con esto obtener pruebas satisfactorias. Los contadores de performance que se monitorearon fueron Avg. Disk Transfer/sec de los objetos PhysicalDisk y LogicalDisk los cuales son utilizados para la métrica de la latencia del disco. Los resultados muestran una mejoría significante comparando la alineación de discos, las métricas muestran una mejoría mayor al 30% entre latencia y duración.
Para la revisión de una correcta alineación de discos, es recomendable tener claro varios conceptos:
- Starting Partition Offset: Es el punto inicial en la partición del volumen que garantiza la omisión de asignación de páginas de datos en n sectores ocultos al principio de los volúmenes.
- Stripe Unit Size: Es la granularidad a la que la data se almacena en un disco del arreglo antes de que la data subsiguiente sea almacenada en otro disco del arreglo. Este valor es proporcionado por su administrador de la SAN
- File Allocation Unit Size: Es conocido también como Clúster Size, y representa la cantidad mínima de espacio de disco que puede ser suministrado para contener un archivo y se determina cuando la partición es formateada por el sistema operativo.
Existen dos reglas, que se deben cumplir para una correcta alineación de discos. Los resultados de los cálculos siguientes han de dar un valor entero.
Partition_Offset / Stripe_Unit_Size
Stripe_Unit_Size / File_Allocation_Unit_size
De las dos reglas anteriores, la primera es la más importante para conseguir un rendimiento óptimo.
Ejemplos de Escenarios con desalineación en los discos
Dada una partición con Starting Partition Offset de 32.256 bytes (31,5Kb) y con un tamaño en Stripe Unit Size de 65.536 bytes (64 Kb), el resultado de Partition_Offset ÷ Stripe_Unit_Size es de 0.4921875, no es un número entero, por lo que se consideran que los discos no están alineados.
Ejemplo de escenario con alineación en los discos
Dada una partición con Starting Partition Offset de 1048576 bytes (1Kb) y con un tamaño de Stripe Unit Size de 65.536 bytes (64 Kb), el resultado de Partition_Offset ÷ Stripe_Unit_Size es exactamente 8, un numero entero exacto, lo cual se puede decir que la alineación es correcta.
Después de todo lo anterior explicado, la pregunta que hace falta contestar es… ¿Y como puedo consultar el estado actual de los discos?
Para revisar el valor del Starting Offset en discos basicos, podemos utilizar el comando WMIC (Windows Management Instrumentation Command-line) para obtener los datos del disco, la sintaxis es la siguiente:
wmic partition get BlockSize, BootPartition, DeviceID, DiskIndex, HiddenSectors, NumberOfBlocks, StartingOffset, Name, Index
El valor a verificar con el commando anterior es StartingOffset, en este ejemplo está alineado a 1024 kb.
También se puede obtener el resultado a través de DISKPART, seleccionando el disco a analizar y ejecutando el comando list partition, en el cual se obtendrá el Offset.
Para revisar el Starting Offset en discos básicos se deberá utilizar la utilidad dmdiag con el switch -v
Si se desea revisar el valor del File_Allocation_Unit_Size se puede ejecutar el comando
fsutil fsinfo ntfsinfo [drive]
El siguiente ejemplo muestra la ejecución de todos los comandos anteriormente escritos.
Conclusión
Muchos factores contribuyen para un óptimo performance de disco. Para las particiones de disco creadas con Windows Server 2003, es adecuado validar la correcta correlación entre el Stripe Unit Size y File Allocation Unit Size como best practice. Windows Server 2008 crea particiones alineadas por default y aunque para la mayoría de los casos es adecuada, es importante siempre preguntar y seguir las mejores practicas del Vendor de discos. Cuando los servidores son actualizados de Windows Server 2003 a Windows Server 2008, las particiones preexistentes no se alinean automáticamente, es recomendable reconstruirlas para un rendimiento óptimo.
Después de hacer bastantes pruebas y dañar muchas máquinas virtuales intentando configurar FBA en SharePoint 2010 como lo haciamos en MOSS 2007, finalmente creo que encontré la manera más simple y fácil de hacerlo para SharePoint Server 2010, espero en realidad que lo que digo sea verdad, por favor lean cuidadosamente todas las instrucciones y no brinquen ningún paso.
Para configurar FBA usando SQL Server con autenticación de Windows Integrada (Recomendado) seguiremos los siguientes pasos:
a) Conocimiento sobre SharePoint 2010, IIS 7.5 y SQL Server 2008 (No indispensable, solicitud de apoyo del DBA)
b) SQL Server configurado como Windows Integrated Authentication
c) ASP.Net SQL Server Database (Base de datos de membresia)
d) Cuenta de usuario de dominio (esta puede ser el mismo administrador de la granja de SharePoint)
e) Asegurarse de respaldar los archivos de configuración "web.config" de: Central Administration, el servicio web llamado Security Token Service y también la Web Application en la que vamos a configurar FBA
Basicamente cuando se instala SQL Server, por defecto la autenticación de Windows integrada es provisionada, en caso de que el equipo de base de datos haya configurado SQL como Mixed-Mode entonces tienen que hacer lo siguiente:
Si tuviste que realizar el paso anterior entonces TIENES que reiniciar el servicio de SQL Server o reiniciar el servidor
Ahora es necesario agregar la cuenta de dominio que vamos a utilzar para el acceso a la base de datos de ASP .Net a los SQL Logins para darle control total sobre dicha base de datos cuando sea creada despúes en este artículo.
Dos cosas son importantes en este punto, escoger al SharePoint Farm Administrator que ya usas o crear una nueva cuenta de usuario de dominio para administrar la base de datos de ASP.NET . Mi recomendación es que utilices el SharePoint Farm administrator, cualquiera que sea la opción que tomes aquí está el proceso a seguir (Apóyate en tu DBA para crear el login si es necesario):
Abrir el asistente de ASP.Net y crear la base de datos de membresia donde los usuarios externos serán alojados para el acceso Extranet:
- Ve a la ruta: C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regsql.exe desde el explorador de Windows y doble clic sobre el ejecutable
- Selecciona la primera opcón “Configure SQL Server for application services”
- Escribe el nombre del servidor de SQL donde se alojará la base de datos. No es necesario que sea el mismo servidor donde las bases de datos de SharePoint se alojan
- Mantén la configuración de autenticación por defecto Windows Authentication
- Utiliza “Default” o escribe un nombre para la base de datos de membresia y completa el procedimiento
TLa primera vez que la base de datos de ASP.NET es creada debes elegir Windows Authentication como se menciona arriba y después crear una nueva base o incluso USAR la que tenías en MOSS 2007*
- Confirma la configuración creada y listo
*Puedes crear una nueva base de datos de ASP.NET para el almacenamiento y administración de nuevos usuarios o TAMBIÉN pudes utilizar la que tenías creada en tu granja de MOSS2007, solamente asegurate que estas configurando correctamente los permisos sobre esa base de datos migrada, el SQL Login creado (usuario de dominio o SharePoint Farm Admin) deben ser db_owenr.
- Regresa al SQL Server Management Studio
- Localiza la nueva base de datos ASP.NET que creaste o asignaste en el paso anterior
- Haz clic derecho sobre ella y selecciona propiedades
- En el panel del lado derecho haz clic sobre el cuadro con los 3 puntos y busca la cuenta de usuario (escribe domainname\username) y clic OK
- Copia el nombre del campo Login name y pégalo en el campo User name
- Al final de la ventana en la sección Database Role Membership selecciona db_owner y haz click in OK
Es tiempo de crear: Connection String, Role Provider, y Membership Provider en el IIS Manager para obtener acceso a la nueva base de datos de ASP.NET.
Hagámoslo primero para el sitio de SharePoint Central Administration y después repitamos exactamente los mismos pasos para el servicio web Security Token service, y la aplicación web de SharePoint, al final vamos a crear un sitio de IIS común para administrar a los usuarios de la base de datos ASP .NET.
No olvides realizar respaldos de los archivos de configuración web.config, es sumamente importante en caso de que necesites regresar al estado original. Usa siempre ambientes de prueba antes de hacerlo en producción
- Abre IIS Manager y encuentra el sitio SharePoint Central Administration v4 debajo de la carpeta Sites
- En el panel del centro haz clic en Connection Strings
- En el panel del lado izquierdo llamado Actions haz clic en Add
- Escribe un nombre para la conexión
- Escribe el nombre del servidor de base de datos donde se encuentra la base de datos de ASP .NET
- Escribe el nombre de la base de datos que recientemente creaste o migraste
- Mantén seleccionada la opción Use Windows Integrated Security
- Clic OK
- Regresa al sitio de IIS para ahora crear los proveedores
- Haz doble clic sobre Providers en la vista llamda IIS Features view y vamos a crear Role Provider y Membership Provider
- Sobre el menu desplegable selecciona primero .Net Roles para crear el proveedor de roles, después seleeciona .Net Users para configurar las membresias de usuarios
- Esto es todo para el sitio de Central Administration v4
Repitamos exactamente los mismos pasos ahora para configurar el servicio web llamado Security Token service. Tenemos que usar los mismos nombres para: Connection String, Role Provider y Membership Provider
Ahora vamos a SharePoint en el sitio de la Central Administration y vamos a crear la nueva aplicación web que usará la autenticación basada en formas
Es importante recordar que en SharePoint 2010 la única manera de configurar FBA es creando las aplicaciones web seleccionando la opción “Claims Based Authentication” de lo contrario no podrás hacerlo.
- Vamos a la Central Administration
- En la categoría llamada Application Management hacemos clic en Manage Web Application
- En el menú superior seleccionamos New
- Escogemos Claims Based Authentication para que las opciones de Forms Based Authentication se habiliten
- Es importante que la opción Enable Windows Authentication con NTLM se mantengan seleccionadas por lo siguiente:
- Ahora debemos seleccionar Enable Forms Based Authentication (FBA) y escribir tanto el Membership Provider como el Role Provider
- Ahora es necesario crear la colección de sitios para la aplicación web, cualquier definición de sitios que escogas será decisión tuya
- Hasta este punto el administrador de la colección de sitios TIENE que ser el SharePoint Farm Admin ya que nuestra base de datos de ASP.NET SQL esta vacia, o bien puedes usar la cuenta de usuario de dominio que especificaste como db_owner de la base de datos
- Ahora tenemos que repetir los pasos anteriores para crear: Connection String, Role Provider, y Membership Provider usando los mismos nombres no lo olviden
SharePoint Server 2010 tiene que usar “i” como Membership Provider por defecto, así mismo “c” como Role Provider por defecto, ya que “I” es el proveedor relacionado directamente con: Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider. (http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.claims.spclaimsauthmembershipprovider_members.aspx)
Vamos a crear un sitio común de IIS para administrar los roles y las cuentas de usuario de nuestra base de datos de ASP.NET
- Desde el IIS Manager hagamos clic derecho sobre la carpeta Sites y seleccionamos New Site
- Le damos un nombre y los demas valores los dejamos por defecto
- Revuisamos lo que hicimos para configura el sitio de la Central Administration v4 y configuramos:
- Para este sitio no debemo dejar como “i” y “c” los proveedores por defecto, esta vez vamos a usar FBARoleProvider & FBAMembershipProvider
- Tiempo de hacer pruebas, abre el sitio de SharePoint que creaste y configuraste con FBA
- Primero utiliza Windows Integrated Authentication, y escribe las credenciales del SharePoint Farm Admin o la cuenta de dominio que diste de alta como administrador del sitio, funcionó?
- Cambia de usuario y escoge ahora Forms-Based Authentication, funcionó? Estoy seguro que no pues no hemos dado de alta usuarios en la base de datos de ASP .NET y tampoco les hemos dado permisos en SharePoint
- Regresemos al IIS Manager y vamos a crear roles y usuarios para FBA
- Ok, Ahora ya podemos agregar a estos usuarios como miembros de los sitios de SharePoint, volvamos al sitio de SharePoint e iniciemos sesión con el SharePoint Farm Administrator
- En la colección de sitios vamos a Site Actions > Site Permissions
- Seleccionamos el grupo al cual deseamos que pertenezcan el o los usuarios externos
- Hagamos clic en New
- Clic sobre el icono de la libreta de direcciones o simplemente escribimos el nombre de usuario que se encuentra en la base de datos de ASP .NET
Les deseo mucha suerte y recuerden que su retroalimentación es muy importante para nosotros, por favor déjenos saber si el artículo es realmente útil y si en verdad esta configuración de FBA para SharePoint 2010 es como lo describí la más simple y rápida.
Hasta la próxima
This is a very common problem I see when visiting customers. Most of people, right after installing OpsMgr, start to create overrides, and store then to Default Management Pack. This could be a problem, because:
So, for moving overrides from the Default MP, these are the main steps:
In Administration Pane, right-click “Management Packs” and select “Create Management Pack”
Type a Name and Description (if desired) and click Next, and then Finish.
In the Administration Pane, click in the left on Management Pack, and you will get a list of all installed MPs. Right-click the ones you want to export, and select the folder.
Before we proceed, let me just show you the override I will be moving, it’s for a monitor called AD Database Free Space Monitor, and it’s possible to see in the picture it’s stored in the Default Management Pack.
Now, I will look for the exported MPs in Windows Explorer. The default MP will be stored as Microsoft.SystemCenter.OperationsManager.DefaultUser. I will just right-click it, and select “Edit”. It should open notepad or another XML editor, if you have one installed.
These are the two sections in default MP we are interested in. The first one is about the references. You could have many here, so I highlighted only the ones I will use. You could do some analysis to understand each ones are really needed, but I will just pick up the ones related to AD. Copy them, and remove if you want. In case you remove, but there is still an override using it, SCOM won’t let you import back the MP. Copy everything inside the red square.
In the Test.ManagementPack, I already have the References section, so I will just paste the references, between the end of existing reference (After </Reference>) and the end of References section (Before </References>).
This second section is about overrides. I have three of them, but will only copy the one I wanted, the last in the list. Again, copy everything inside the red square, but remove these lines from Default MP, since this can create a conflict of the same override in two Management Packs.
Now, for the overrides, Test.ManagementPack doesn’t have the section created, so we will manually add the lines, right after </Manifest>.
Then we can paste the override:
Now, save the changes made to both MPs, and let’s go to the final step.
First I will import back the edited Default Management Pack. In administration panel, right-click “Management Packs” and select “Import Management Packs…”
Click Add…, then Add from disk… and No, for the Online Catalog Connection message box.
I will first import only the Default MP, select Install, and then Close:
I will check my overrides view now:
Ok. The override is gone, because I only imported the Default MP. I will now import the Test.ManagementPack and check again my Overrides view:
Great! Now the Override is in the correct MP.
This post is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified in the Terms of Use
Un cordial saludo comunidad Technet.
Hoy tengo el privilegio de comenzar a publicar ( y retribuir un poco tanto conocimiento que he podido consultar tanto de Technet como MSDN) en este medio, y aprovecho el reciente lanzamiento de SQL 2012 ( http://www.microsoft.com/es-es/sqlserver/default.aspx) para hacer una breve y precisa referencia a la documentación que nos permitirá explorar algunas de sus nuevas características de BI desde SharePoint 2010
Particularmente en Venezuela, la semana pasada se reunieron en el Hotel Renaissance de Caracas, socios de negocio y clientes para conocer de primera mano la propuesta de valor que MIcrosoft ofrece para gestionar la información de organizaciones tanto con fines de lucro como de desarrollo social, con necesidades de análisis y generación de repotes de forma rápida, simple ("Power View"), sobre altos volúmenes de datos ("Parallel Datawarehouse"), en cualquier ubicación (On Premise, Nube o mixto) y con alto porcentaje de disponibilidad ("Always On")
SQL 2012 está aquí para fortalecer con nuevas características su compromiso con la misión crítica de la információn transaccional, espacial y multidimensional.
Desde el punto de vista de colaboración e Insights, Este compromiso se traduce en la capacidad para:
- Soportar las bases de datos SharePoint 2010 con Service Pack 1 (SP1).
- La edición y publicación en sitios SharePoint, de reportes en cualquier formato Office, utilizando "Power View", una nueva característica de complemento de SQL Server Reporting Services para SharePoint.
- Fortalecer la alta disponibilidad para las bases de datos SharePoint 2010 (con SP1), mediante "Always On"
Si bien hasta el momento no se menciona SQL 2012 en la documentación de requerimientos de software para SharePoint 2010, tenemos disponible la guía para utilizar las características de BI de SQL 2012 en una granja SharePoint 2010: http://technet.microsoft.com/en-us/library/hh231680(v=SQL.110).aspx Esta guía describe la posibilidad de desplegar una granja SharePoint sobre SQL 2012, previamente actualizada con el Service Pack 1.
Espero que esta referencia sea una razón más para promover la actualización de su granja SharePoint 2010 (sí aún no lo ha hecho) y así poder comenzar a familiarizarse con las nuevas caracterísitcas de BI en SQL 2012.
En los últimos 6 meses me encontré con 2 casos de linked servers entre una instancia de SQL Server 2008 R2 64 bits en un Cluster de Windows 2008 R2 y una instancia standalone de SQL Server 2000 32 bits en los cuáles los cuáles las transacciones distribuidas no estaban funcionando.
La causa raíz del problema sigue en investigación, sin embargo, tratando de entender el problema verifiqué que todo estuviera bien configurado y realicé algunas pruebas.
Revisé lo siguiente:
- Que la resolución de nombres funcionara bien
- Que el DTC estuviera bien configurado en cuanto a la sección de seguridad
- Se probó el linked server sin transacción distribuida y funcionaba
- El DTCPing dio resultado correcto
- Hasta donde recuerdo el DTCTester también dio resultado correcto.
Aún cuando todos los puntos anteriores fueron exitosos, las transacciones distribuidas seguían fallando. En las pruebas que hice, probé creando un DTC Clusterizado en el grupo de SQL Server 2008 y siguió fallando.
Después, sin muchas esperanzas, probé borrando todos los DTC Clusterizados y configurando los DTC locales y, para mi sorpresa, funcionó.
En éste punto la pregunta se convirtió en, ¿Que desventajas tengo en utilizar los local DTC’s en lugar de los DTC’s clusterizados?, así que tuve que investigar y probar éste punto.
Antes que nada, ¿Cuál es la razón de tener DTC’s clusterizados?, antes de Windows Server 2008, la razón era que en Windows Cluster la única forma de utilizar el MSDTC era clusterizándolo, sin embargo en Windows Server 2008 el número de opciones aumentó. Ahora es posible tener más de un DTC clusterizado y también es posible utilizar el DTC no clusterizado de cada nodo. Entonces, ¿Sigue siendo necesario clusterizar el DTC?, ¿Cuáles son los beneficios de clusterizarlo y cuáles son las limitantes de solo utilizar el local DTC?
La respuesta corta (basado en mi conocimiento y pruebas) es que hay algunos escenarios por los que el ambiente clusterizado tiene beneficios, pero en muchos casos la diferencia es muy pequeña y puedes usar el local DTC en lugar del DTC clusterizado con muy poco riesgo.
¿Cuándo es preferible usar el DTC Clusterizado en lugar del local?, Un escenario es cuando tienes múltiples instancias de SQL Server en cada nodo. En ese caso con local DTC todas las instancias usarán el único DTC disponible en la instancia, si quieres mayor escalabilidad y disponibilidad entonces es recomendable configurar múltiples DTC’s clusterizados, uno para cada instancia.
Otro escenario sería cuando el DTC local falla, en ese caso, las instancias no van a hacer failover automático, en cambio, si estuviéramos utilizando un DTC Clusterizado, el failover del DTC es automático y solo las transacciones distribuidas activas hacen rollback, las nuevas transacciones distribuidas corren sin problema.
En resumen, es recomendable tener los DTC clusterizados, sin embargo, si estás teniendo problemas prueba con los DTC locales para ver si eso soluciona tu problema.
Saludos comunidad
Recientemente una nota acerca de la politica de Microsoft Support Lifecycle fue liberada notificando que a partir del 10 de Julio de 2012 SharePoint Server 2010 dejará de ser soportado en sus versiones actualizas previas al Service Pack 1. El equipo de SharePoint de Latinoamerica les suguiere que actualicen sus granjas de SharePoint 2010 al menos al Service Pack 1 con el respectivo Refresh de Junio, o bien al último update acumulativo de Abril de 2012 (http://support.microsoft.com/kb/2598151) recién liberado.
Referencias:
Microsoft Lifecycle Support Policy FAQ - http://support.microsoft.com/gp/lifePolicy
Lifecycle support team - https://support.microsoftonline.com/eform.aspx?productKey=lifecycle&ct=eformts
MSL Customer Newsletter Sign-up - https://profile.microsoft.com/RegSysProfileCenter/subscriptionwizard.aspx?wizid=98973176-f0b1-4f60-957d-5936c3b933c0&lcid=1033
Si desean actualizar sus granjas de SharePoint por favor consulten la información siguiente:
Updates for SharePoint 2010 Products - http://technet.microsoft.com/en-us/sharepoint/ff800847
Hola a todos, esta vez les voy a hablar de tema que no esta relacionado con SQL Server directamente, les voy a hablar de un issue relacionado con Windows Server 2003 Failover Clustering.
El problema en si es que luego de instalar los discos compartidos en los Nodos del Cluster no podían ser agregados como un recurso de Disco físico en el clúster, al realizar el procedimiento para crear un Physical Disk Resource los discos no aparecían en la lista de para seleccionar discos, en realidad no aparecía ningún disco.
Luego de introducir algunas palabras claves en Bing encontré un artículo donde se menciona el problema. Unable to select disk from dropdown in Cluster Administrator http://support.microsoft.com/kb/969053
Aunque me ayudo, la solución no resolvió completamente el problema, vamos a seguir los pasos del método Alternativo:
1. The following command will create a resource of type physical disk: cluster res "Disk F:" /Create /group:"Cluster Group" /Type:"physical disk"
Este paso te permite crear el un recurso de disco con el nombre Disk F: en el grupo Cluster Group, el recurso se crear offline y sin propiedades especificas.
2. The next command is needed for associating the disk through its disk signature to the physical disk resource.
Este paso se utiliza para asociar el disco compartido al recurso del disco físico creado en el paso anterior a través de la firma (signature) del disco. Sin embargo al ejecutar el comando se generaba un error System Error 87.
Por lo tanto decidí asociarlo directamente a través del registro. Con los siguientes pasos:
- Abro el clúster administrator en el nodo donde esta el Grupo de clúster donde quiero agregar el disco
- Añado el recurso de disco a través de cluster.exe como se muestra en el artículo. Ejm: cluster res "Disk F:" /Create /group:"Cluster Group" /Type:"physical disk". El recurso es agregado offline
- En la llave de registro HKEY_LOCAL_MACHINE\Cluster\Resources ubico el {GUID} para el recurso de disk agregado anteriormente, deberás ir uno a uno hasta encontrar el que tenga el mismo nombre, Ejm: Disk F:
- En el Key Parameters, añadir un valor DWORD llamado Signature, y en el mismo agregaras la firma hexadecimal del disco
- Ahora podrás ir al cluster administrator y colocar el disco en línea. Puedes ver la propiedades para verificar que esta mapeado al disco adecuado.
De esta manera podrás agregar los discos como recursos del cluster. Este problema es poco común y generalmente se da cuando hay algún tipo de incompatibilidad o issue con los drivers de los discos de la SAN. Es probable que un reinicio de todos los nodos del cluster también resuelva
Si deseas saber como obtener la firma (Signature) del disco sigue los siguientes pasos:
1) Ir al command prompt y escribir "diskpart".
2) En DISKPART> prompt, escribe “list disk”
3) En DISKPART> prompt, escribe "select disk n" <- donde n es el disco que deseas saber la firma
4) En DISKPART> prompt, escribe "detail disk"
5) El valor de "Disk ID: " es el valor en Hexadecimal de la firma del disco
Hi Technet community.
Today I have the privilege to start write in this blog (and a little reward the knowledge I've gained in Technet and MSDN). A few weeks ago it was the launch of SQL 2012 (http://www.microsoft.com/es-es/sqlserver/default.aspx) and I would like to make a brief reference to the current documentation that will allow us to explore some of its new BI features from SharePoint 2010 perspective.
A few weeks ago in Caracas-Venezuela, business partners and customers met at the Renaissance Hotel, to see first hand the value proposition offered by MIcrosoft to help companies and NGOs in the information management: analysis, reporting fast and simple ("Power View"), over huge data ("Parallel Datawarehouse"), in any location (On Premise, cloud or mix) with high availability ("Always On"). SQL 2012 is here with new features in order to strengthen their commitment with the transactional, spatial, multidimensional and critical information.
From the point of view of collaboration and Insights, this commitment translates into the ability to: - Support SharePoint 2010 with Service Pack 1 (SP1) databases.- Editing and publishing in SharePoint sites, reports in any format Office, using "Power View", a new feature of SQL Server Reporting Services for SharePoint.- Strengthen the high availability databases, SharePoint 2010 (with SP1), by "Always On"
At this moment, SQL 2012 is not mentioned in software requirements documentation for SharePoint 2010, However, We have the following Guide for use SQL 2012 BI features in a SharePoint 2010 farm: http://technet.microsoft.com/en-us/library/hh231680(v=SQL.110).aspx This guide describes the possibility of deploying a farm SharePoint on SQL 2012, previously updated with Service Pack 1.
I hope this reference help you to promote the updating of your SharePoint 2010 farm and start to familiarize with the new features of BI in SQL 2012.
Una vez más trayendo para ustedes algo que pueda ser de utilidad.
Desde que Microsoft liberó la nueva y más reciente versión de su sistema operativo para dispositivos móviles, todos deseamos que el hardware nos permitiera hacer lo que se hace con la competencia (iPhone) relacionado a la personalización de nuestro teléfono y contactos sobre todo. Cuando intentábamos usar un archivo wma como timbre simplemente no era posible.
Pero esto se acabo, ahora podemos usar archivos no protegidos como MP3 o WMA como timbres personalizados y poder usarlos en la configuración de nuestro teléfono, solo debemos cumplir ciertas condiciones y seguir los siguientes pasos:
Requisitos
Procedimiento
Y listo a disfrutar, si tienes dudas o deseas información más detallada y oficial sobre este tema consulta: http://www.microsoft.com/windowsphone/en-us/howto/wp7/start/create-ringtones.aspx
Uno de los clientes para los que labore posee una base de datos central completamente transaccional. Esta base de datos es leída por una aplicación web, la cual posee una capa intermedia de servidores de aplicación los cuales se conectan directamente a las bases de datos.
En este punto podemos diferenciar 3 niveles: web, aplicación y bases de datos. Las correctas practicas de programación nos llevarían a mantener la mayor parte del código dentro de la base de datos para de esta forma obtener un mejor performance disminuyendo la cantidad de información que viaja por la red, en este caso a través de los 3 niveles ya explicados anteriormente.
Sin embargo por una serie de antiguas practicas de programación incorrectas los desarrolladores mantienen mas del 70% de código fuente en las rutinas de .NET en los servidores de aplicación.
Esto no se convirtió en un problema real en cuanto el nivel de transacciones no era tan alto como lo ha llegado a ser, al igual como el tamaño y la complejidad de las bases de datos ha alcanzado atreves del tiempo.
Una de las políticas de la compañía es no hacer cambios en el código y en las bases de datos de Producción fuera de los “Service Packs” o cambios de versión de las aplicaciones, por lo que podrán suponer que cada “Service Pack” conlleva una gran serie de actualizaciones que son liberadas en el ambiente de Producción al mismo tiempo.
Habiendo aclarado el tipo de ambiente, practicas de programación y alguna de las políticas para los deployments podre llegar al punto que deseo exponer en este blog; una vez, un día después de la liberación de uno de los “Service Packs”, un lunes, los clientes comenzaron a contactar a servicio al cliente quejándose que nadie podía ingresar a ninguna de las aplicaciones, al aparecer la pantalla de LOGIN y darle aceptar, nada sucedía hasta obtener un time-out como respuesta.
Inmediatamente tuve que ingresar a los servidores de bases de datos y me lleve la desagradable sorpresa que el CPU de uno de ellos estaba al 100% de utilización, solo me preguntaba que cambio pudo venir con el Service Pack que estuviera ocasionando este extraño comportamiento!!
Después de un tiempo capturando traces, obteniendo información de las DMV’s entre otras herramientas llegamos a la conclusión que el nivel de compilamiento era muy superior al mostrado históricamente antes del cambio de versión, pero entre tantos cambios que vinieron con este Service Pack hubiéramos tenido que tener la aplicación abajo por demasiado tiempo hasta encontrar los statements responsables de semejante horror.
Dos cosas se hicieron para solucionar este problema, primero; por medio del análisis de los traces llegamos a la conclusión que había que crear índices en un par de tablas que los necesitaban desesperadamente y segundo; al saber que la mayoría de las ejecuciones eran tipo BATCH, ya que las llamadas del código están en los servidores de aplicación cambiamos el tipo de PARAMETERIZATION de simple a forced.
Comando:
ALTER DATABASE <DB_NAME> SET PARAMETERIZATION FORCED
Que es lo que esta opción de base de datos realiza?
Parametriza todos los valores que vienen con los selects, updates, deletes e inserts que sean tipo batch, individualmente, para que estos no sean recompilados cada vez que son ejecutados. O sea los mantiene a nivel de memoria.
Lógicamente esta opción no aplica para todos los statements que estén dentro de los procedimientos almacenados ya que estos son compilados efectivamente por el motor de base de datos.
También hay otras situaciones donde la parametrizacion no aplica, pueden acceder a estas ingresando al siguiente link.
http://technet.microsoft.com/en-us/library/ms175037.aspx
Al aplicar estos cambios el grado de recompilamiento bajo significativamente y junto a los índices creados el CPU volvió a niveles normales de entre 20% y 30%, y todos los usuarios pudieron felizmente ingresar de nuevo a las aplicaciones.
Antes de finalizar este tema sugiero siempre recomendar a los desarrolladores mantener todo el código posible siempre dentro del motor de base de datos y cuando nos topamos con ambientes como el expuesto aquí recomiendo hacer el cambio de la parametrizacion a “FORCED” antes de que ocurran los desastres.
One of the clients that I worked for has a fully transactional core database. This database is accessed by a web application, which has an intermediate layer of application servers which connect directly to databases.
Here we can distinguish 3 different levels: web, application and database. The right programming practices lead us to keep most of the code within the database in order to obtain a better performance by decreasing the amount of information that goes over the network, in this case through the 3 levels explained before.
However a big number of old wrong programming practices maintain over 70% of source code routines within the application servers.
This did not become a real problem until the transaction level was increasing over time, as well as size and complexity of the database had reached.
One of the company policies is not to make code changes to databases production outside the "service packs" or application version upgrades, so you can assume that each "Service Pack" carries a large number of changes that are released into the Production environment at the same time.
Having clarified the environment, programming practices and deployments policy I can expose the case I had to face to at that time in this blog. Once, a day after a "Service Packs" release, Monday, customers began to contact customer service complaining that no one could enter to any of the applications, after the LOGIN screen appears, nothing happened until a time-out pop up in response.
Immediately I had to go through the database servers and I got the unpleasant surprise that in one server the CPU was 100% of usage; just wondering what change might come with the service pack that was causing this strange behavior!
After a while, some SQL traces were captured, and obtaining information from the DMV's and other tools, we conclude that the compiling level was much higher than historically shown before the version upgrade, but among so many changes that were pushed with the service pack we would have had the application down for too long in order to find the statement(s) responsible for such horror.
Two things were done in order to solve this issues, first, by analyzing the traces we conclude that we had to two indexes on a couple of tables that were desperately needed them, and second, by knowing that most of the executions were BATCH type, we came out with the possibility of changing the PARAMETERIZATION database option from SIMPLE to FORCED.
Command:
ALTER DATABASE <db_name> SET PARAMETERIZATION FORCED
What does this option do to a database?
Parameterizes all the values which come with selects, updates, deletes and inserts that are BATCH type, individually, this way they won’t need to be recompiled each time they are executed. The execution plan is kept at memory level.
Obviously, this option does not apply to all statements that are within stored procedures as these are compiled by the database engine instead.
There are other situations where the parameterization is not applicable, you can see all the cases by entering the following link.
By implementing these changes, the degree of recompiling decreased significantly and the CPU returned to normal levels between 20% and 30% of usage; this way all users could happily accessed the applications.
Conclusion
Before concluding this post I want to suggest recommending to developers to keep most of the code within the database engine as much as possible and if you came across with environments like the exposed here, I recommend changing the parameterization database option to "FOCED" before the disasters occurred.
Hola comunidad,
Después de mucho tiempo regresamos a continuar con información que puede ser valiosa para ustedes, en esta ocasión para los principiantes de SharePoint 2010 que desean saber las opciones de Respaldo y Restauración que SharePoint 2010 tiene out-of-the-box y como usar las tareas programadas de Windows para calendarizar respaldos.
Primero entendamos las opciones que tenemos desde la Administración Central de SharePoint
Como podemos observar en la imagen anterior tenemos 2 categorias "Respaldo y Restauración de la granja" y "Respaldo Granular".
Después tenemos las opciones para los respaldos granulares. SharePoint 2010 integra estas opciones que solo estaban disponibles a traves de stsadm en la versión anterior, para que el administrador de la granja de SharePoint pueda en un momento dado ejecutar un respaldo de una lista o biblioteca de documentos sin tener que usar PowerShell:
3. Y finalmente un acceso directo a revisar el estado del respaldo granular
Usando las tareas programadas de Windows
La calendarización de los respaldos será siempre una función fundamental pues la mayoría de los administradores de sistemas programa estas actividades durante la noche, en primer lugar por el impacto que puede existir en los datos a respaldar ya sea para mantener la integridad o para tener en el respaldo la mayor actualización de la información y por otro lado para no afectar el desempeño de las aplicaciónes debido al alto I/O que un respaldo conlleva.
Esta sección tiene la intención de proveer de algunos ejemplos con la sintaxis apropiada para que cada administrador de SharePoint calendarice sus respaldos.
Primero es necesario saber que requeriremos de un archivo .bat para la ejecución del respaldo desde PowerShell, por ejemplo:
@echo onSET SOURCE_SITE=<URL>http://intranetSET DEST=<Path>echo “backup Started at” %DATE% %TIME% >> <LogFileCustom>
powershell -command <PS1 File> %SOURCE_SITE% %DEST%echo “Backup completed successfully at %DEST%” on %DATE% %TIME% >> <LogFileCustom>@echo on
Donde:
<URL> Será la Colección de sitios a respaldar
<Path> La ubicación completa incluyendo el nombre del archivo donde se creará el respaldo. Ej.: Drive:\backupintranet\backupintranet.bak
<LogFileCustom> El archivo de log de los respaldos (Opcional) Ej.: Drive:\backupintranet\backupLog.txt
<PS1 File> La ubicación del script de PowerShell que será ejecutado para el respaldo. Ej.: Drive:\backupintranet\Bckptl.ps1
Ahora bien que deberá incluir el archivo PS1?, bien pues tenemos varias opciones. De inicio debemos de tomar en cuenta que las opciones del sitio de Administración Central de SharePoint nos permite hacer respaldos a nivel de toda la granja o de aplicación web, pero no de una colección de sitios en particular, siendo importante destacar que haciendo esta clase de respaldos el administrador de SharePoint tendrá la capacidad de restaurar información imporntate en menor tiempo que si lo hiciera restaurando toda la base de datos de contenido, pues ésta podría llegar a medir hasta 200 GB, lo que implicarían horas en una restauración.
Bien pues el archivo PS1 deberá iniciar con la siguiente línea que permitirá ejecutar la llamada de PowerShell
Add-PsSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue
Ahora si las opciones para respaldos:
Colecciones de Sitios:
Backup-SPSite -Identity <Site collection name> -Path <backup file> [-Force] [-NoSiteLock] [-UseSqlSnapshot] [-Verbose] (http://technet.microsoft.com/en-us/library/ee748617.aspx)
Sitios, Listas o Bibliotecas de documentos
Export-SPWeb -Identity <Site URL> -Path <Path and file name> [-ItemUrl <URL of site, list, or library>] [-IncludeUserSecurity] [-IncludeVersions] [-NoFileCompression] [-GradualDelete] [-Verbose] (http://technet.microsoft.com/en-us/library/ee428301.aspx)
Configuración de la granja
Backup-SPConfigurationDatabase -Directory <BackupFolder> -DatabaseServer <DatabaseServerName> -DatabaseName <DatabaseName> -DatabaseCredentials <WindowsPowerShellCredentialObject> [-Verbose] (http://technet.microsoft.com/en-us/library/ee428320.aspx)
Esta última es una nueva característica que permitirá respaldar cierta configuración almacenada en la base de datos de Configuración de SharePoint, con el objetivo de restaurar dicha configuración en una nueva base de datos de configuración en una nueva granja de SharePoint y reducir el tiempo de creación de una nueva granja, por ejemplo en el caso de granjas para DRP (Disaster Recovery Plan)
Si desean conocer más opciones y ejemplos de scripts de PowerShell para los diferentes objetos de SharePoint 2010 pueden consultar el siguiente contenido:
http://technet.microsoft.com/en-us/library/ee428315.aspx
Hasta la próxima...!!!
Hello Community,
After many time of abscense I'm back to continue providing you with more information that can be valuable or useful, this time for SharePoint 2010 beginners that would like to know the new OOB Backup/Restore features and how to schedule backups using Windows scheduled tasks.
First we need to know and understand SharePoint Central Administration site options
As we can see on the image above we have 2 categories "Farm Backup and Restore" & "Granular Backup".
Here we have granular backup options now. SharePoint 2010 includes export/import options that was only available through stsadm in MOSS 2007, in order SharePoint administrator can execute a backup of a site, list or document library without PowerShell:
3. Finally a shortcut to review the status of the granular backup
Using Windows Scheduled Tasks
Having scheduled backups are fundamental for SharePoint adminsitrators, most of the times this taks are executed overnight, first of all, to grant data integrity and get the last updated data ,and then to minimize performance impact because of the heavy I/O on disks
In this section you will find some examples with the correct syntaxis for PowerShell scripts, but first we need to build a .BAT file like this one
@echo on
SET SOURCE_SITE=<URL>SET DEST=<Path>
powershell -command <PS1 File> %SOURCE_SITE% %DEST%echo “Backup completed successfully at %DEST%” on %DATE% %TIME% >> <LogFileCustom>
Where:
<URL> Will be the Site Collection to be backed up
<Path> Path for the backup file. Drive:\backupintranet\backupintranet.bak
<LogFileCustom> Log file(Optional) Drive:\backupintranet\backupLog.txt
<PS1 File> PowerShell script location Drive:\backupintranet\Bckptl.ps1
But, what's inside PS1 file?, we have many options. Before we need to understand that SharePoint Central Administration site only allows us to make backups of the entire farm or at web application level only, but not for a specific site collection or site, we need to highlight that SharePoint administrator will be able to restore SharePoint objects as fast as possible, rather than restoring the entire content inside the content database that can be 200 GB of size and taking hours to be restored.
Well PS1 file MUST start with the following line in order to start PowerShell
What we have for backups:
Site Collections:
Sites, Lists or Document Libraries
Farm configuration
This last option is a new feature in SharePoint 2010 that allows SharePoint administrator to backup farm CONFIGURATION located in Configuration database, the objective is to restore some configuration settings in a different Configuration database like a DRP SharePoint farm (Disaster Recovery Plan)
If you want to know more backup/restore options and some PowerShell sample scripts for SharePoint 2010 you can check the following technet article:
See you soon...!!!
Hace unos días visite un cliente en Puerto Rico que tenía problemas de rendimiento en una aplicación transaccional y entre las opciones que quería considerar era el uso de índices almacenados por columnas. Este tipo de índice es una de las nuevas funcionalidades que tiene SQL 2012 pero como veremos a continuación sus características lo hacen idóneo para ciertos escenarios no para todos. Las versiones de SQL 2012 donde está disponible la funcionalidad de índices almacenados por columnas son: SQL Server 2012 Enterprise, Evaluation, y Developer.
Los índices tradicionales son almacenados por filas en vez de columnas. Esta forma de almacenamiento es extremadamente eficiente cuando se requiere acceder una fila o un rango compuesto de un grupo pequeño de filas. Sin embargo cuando se solicitan todas las filas o un rango grande, este método se vuelve ineficiente.
En un índice almacenado por columnas, en vez de almacenar juntas todas las columnas de un registro, cada columna es almacenada de forma separada con todas las demás filas en el índice. El beneficio de este tipo de índice consiste en que solo las columnas y las filas requeridas para contestar una consulta serán leídas. En escenarios de Datawarehouse, a menudo se utiliza menos de un 15% de las columnas de un índice para obtener el resultado de una consulta.
Hay dos restricciones principales a considerar cuando se trabaja con índices almacenados por columnas. En primer lugar un índice almacenado por columna es de solo lectura. Una vez se ha creado, no se pueden realizar modificaciones a los datos en la tabla. Es decir las operaciones: INSERT, UPDATE y DELETE no están permitidas. Por esta razón a menudo se utiliza el particionamiento de tablas para reducir la cantidad de datos que necesitan ser almacenados en un índice almacenado por columnas y para permitir el reconstruir un índice cuando se insertan nuevos datos a la tabla. Debido a esta restricción, los índices almacenados por columnas son idóneos en situaciones donde los datos no cambian con frecuencia como es el caso de los datawarehouse. La segunda restricción limita a uno el número de índices almacenados por columnas que pueden existir en una tabla. Esta restricción no se considera un problema ya que se acostumbra a incluir todas las columnas de la tabla en el índice almacenado por columnas.
Otra limitación está relacionada con el tiempo que toma la creación de un índice en comparación con un índice nonclustered. El tiempo promedio podría ser de dos a tres veces más. Sin embargo, a pesar de las restricciones antes mencionadas, los índices almacenados por columnas pueden proveer un valor significativo en términos de rendimiento si se considera que el índice solo cargará las columnas que sean requeridas por la consulta. Además de la mejora en compresión que se puede obtener por contar con data similar en la misma página.
Los siguientes tipos de datos no pueden ser utilizados en índices almacenados por columnas: binary, varbinary, ntext, text, image, nvarchar(max), varchar(max), uniqueidentifier, rowversion, sql_variant, decimal (mayor de 18 dígitos), datetimeoffset, xml, y tipos basados en CLR. Además el número de columnas está limitado a 1,024. Finalmente por la naturaleza del índice no puede ser UNIQUE, CLUSTERED, contener columnas incluidas o tener definido un orden (ascendente o descendente).
Los índices almacenados por columnas utilizan su propia tecnología de compresión por lo cual no se pueden combinar con la opción de compresión a nivel de fila o página. Tampoco pueden ser utilizados en esquemas de replicación, change tracking o Change data capture, filestream. Estas tecnologías trabajan en escenarios de lectura/escritura lo cual no es compatible con la naturaleza de solo lectura de los índices almacenados por columnas.
Como crear un índice almacenado por columnas
La creación de un índice almacenado por columnas puede ser realizada a través de T-SQL o utilizando SQL Server Management Studio.
T-SQL
CREATE NONCLUSTERED COLUMNSTORE INDEX <ColumnStoreIndexName> ON <Table> (col1, col2, col3);
<ColumnStoreIndexName> ON
<Table> (col1, col2, col3);
-- Create the columnstore index
CREATE NONCLUSTERED COLUMNSTORE INDEX [csindx_FactResellerSalesPtnd]
ON [FactResellerSalesPtnd]
(
[ProductKey], [OrderDateKey], [DueDateKey], [ShipDateKey], [CustomerKey], [EmployeeKey],
[PromotionKey], [CurrencyKey], [SalesTerritoryKey], [SalesOrderNumber], [SalesOrderLineNumber],
[RevisionNumber], [OrderQuantity], [UnitPrice], [ExtendedAmount], [UnitPriceDiscountPct],
[DiscountAmount], [ProductStandardCost], [TotalProductCost], [SalesAmount], [TaxAmt], [Freight],
[CarrierTrackingNumber], [CustomerPONumber], [OrderDate], [DueDate], [ShipDate]
);
Management Studio
Índices almacenados por columnas con tablas particionadas
Crearemos una tabla particionada llamada FactResellerSalesPtnd utilizando el siguiente código de MSDN (http://msdn.microsoft.com/en-us/library/gg492088.aspx).
Paso #1: Crear la tabla FactResellerSalesPtnd (Versión particionada de la tabla: FactResellerSales)
USE AdventureWorksDW2012;
GO
CREATE PARTITION FUNCTION [ByOrderDateMonthPF](int) AS RANGE RIGHT
FOR VALUES (
20050701, 20050801, 20050901, 20051001, 20051101, 20051201,
20060101, 20060201, 20060301, 20060401, 20060501, 20060601,
20060701, 20060801, 20060901, 20061001, 20061101, 20061201,
20070101, 20070201, 20070301, 20070401, 20070501, 20070601,
20070701, 20070801, 20070901, 20071001, 20071101, 20071201,
20080101, 20080201, 20080301, 20080401, 20080501, 20080601,
20080701, 20080801, 20080901, 20081001, 20081101, 20081201
)
CREATE PARTITION SCHEME [ByOrderDateMonthRange]
AS PARTITION [ByOrderDateMonthPF]
ALL TO ([PRIMARY])
-- Create a partitioned version of the FactResellerSales table
CREATE TABLE [dbo].[FactResellerSalesPtnd](
[ProductKey] [int] NOT NULL,
[OrderDateKey] [int] NOT NULL,
[DueDateKey] [int] NOT NULL,
[ShipDateKey] [int] NOT NULL,
[CustomerKey] [int] NOT NULL,
[EmployeeKey] [int] NOT NULL,
[PromotionKey] [int] NOT NULL,
[CurrencyKey] [int] NOT NULL,
[SalesTerritoryKey] [int] NOT NULL,
[SalesOrderNumber] [nvarchar](20) NOT NULL,
[SalesOrderLineNumber] [tinyint] NOT NULL,
[RevisionNumber] [tinyint] NULL,
[OrderQuantity] [smallint] NULL,
[UnitPrice] [money] NULL,
[ExtendedAmount] [money] NULL,
[UnitPriceDiscountPct] [float] NULL,
[DiscountAmount] [float] NULL,
[ProductStandardCost] [money] NULL,
[TotalProductCost] [money] NULL,
[SalesAmount] [money] NULL,
[TaxAmt] [money] NULL,
[Freight] [money] NULL,
[CarrierTrackingNumber] [nvarchar](25) NULL,
[CustomerPONumber] [nvarchar](25) NULL,
OrderDate [datetime] NULL,
DueDate [datetime] NULL,
ShipDate [datetime] NULL
) ON ByOrderDateMonthRange(OrderDateKey);
-- Using simple or bulk logged recovery mode, and then the TABLOCK
-- hint on the target table of the INSERT…SELECT is a best practice
-- because it causes minimal logging and is therefore much faster.
ALTER DATABASE AdventureWorksDW2012 SET RECOVERY SIMPLE;
-- Copy the data from the FactResellerSales into the new table
INSERT INTO dbo.FactResellerSalesPtnd WITH(TABLOCK)
SELECT * FROM dbo.FactResellerSales;
[ProductKey],
[OrderDateKey],
[DueDateKey],
[ShipDateKey],
[CustomerKey],
[EmployeeKey],
[PromotionKey],
[CurrencyKey],
[SalesTerritoryKey],
[SalesOrderNumber],
[SalesOrderLineNumber],
[RevisionNumber],
[OrderQuantity],
[UnitPrice],
[ExtendedAmount],
[UnitPriceDiscountPct],
[DiscountAmount],
[ProductStandardCost],
[TotalProductCost],
[SalesAmount],
[TaxAmt],
[Freight],
[CarrierTrackingNumber],
[CustomerPONumber],
[OrderDate],
[DueDate],
[ShipDate]
Paso #2: Vamos a correr una consulta y confirmaremos que se utilizó el índice almacenado por columnas.
SELECT SalesTerritoryKey, SUM(ExtendedAmount) AS SalesByTerritory
FROM FactResellerSalesPtnd
GROUP BY SalesTerritoryKey;
Beneficios en términos de rendimiento de los índices almacenados por columnas
Costo
FROM FactResellerSales
-- Índice almacenado por columnas
SELECT SalesTerritoryKey, SUM (ExtendedAmount) AS SalesByTerritory
El costo relativo de la segunda consulta (utilizando un índice almacenado por columnas) es de 16% en comparación con el costo relativo de la primera consulta que es de 84% y utiliza un índice regular.
Actividad de disco
Al correr las consultas con STATISTICS IO ON (Muestra información relacionada con la cantidad de actividad de disco generada por las instrucciones Transact-SQL) se observa una mejora en rendimiento en la segunda consulta relacionada principalmente con las lecturas lógicas y read-ahead.
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
SET STATISTICS IO ON
SET STATISTICS IO OFF
(10 row(s) affected)
Table 'FactResellerSales'. Scan count 1, logical reads 2982, physical reads 2, read-ahead reads 2972, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'FactResellerSalesPtnd'. Scan count 1, logical reads 599, physical reads 4, read-ahead reads 235, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Tiempo
Al correr las consultas con STATISTICS TIME ON (Muestra el número de milisegundos necesarios para analizar, compilar y ejecutar cada instrucción) se observa una reducción de tiempo en la segunda consulta relacionada con el tiempo transcurrido y tiempo de CPU.
SET STATISTICS TIME ON
SET STATISTICS TIME OFF
SQL Server Execution Times:
CPU time = 46 ms, elapsed time = 109 ms.
CPU time = 32 ms, elapsed time = 85 ms.
Expertos coinciden que la mejora en rendimiento obtenida al utilizar índices almacenados en columnas fluctúa entre un 10% a un 100%. Sin embargo como hemos mencionado en este artículo las aplicaciones que se benefician más son las relacionadas con altos volúmenes de lectura y no en sistemas altamente transaccionales. Los esquemas de estrella y copo de nieve usualmente forman parte de los datawarehouse y datamarts donde la velocidad de la extracción de los datos es más importante que la eficiencia en la manipulación de los datos. La tecnología de índices almacenados en columnas puede detectar y agilizar las consultas dirigidas a estos esquemas por lo cual son los escenarios típicos idóneos para su aplicación.
Some days ago I visit a client on Puerto Rico that was having some performance problems on a transactional application and after resolving the issue the client express interested on learning about Column Store Index, this kind of indexes is a new functionality on SQL Server 2012, as we will see his kind of index work great on some scenarios but not all. The SQL Server versions that support this functionality is SQL Server 2012 Enterprise, Evaluation and Developer Edition.
Traditional Indexes are stored by rows instead of by columns. This kind of storage is extremely efficient when you require to access the data on a row or a small amount of rows. However if you request all the rows or a really big range, this approach becomes not as effective.
The Store Column Indexes allow you to present a big range of rows by storing the data organizing it by columns. When you create the Column Store Index you usually include all the columns on a table, this will assure that all columns will
In a Column Store Index, instead of storing all column of a specific row, each column is store a part from each other with all the rows from that column. The benefit of this type of index is that only the columns and rows needed to reply a request will be read. Usually a Dataware House scenarios only a 15% of the columns of an index to obtain the result of a request.
There are two principal restriction to consider when working with Column Store Indexes. First a Column Store Index is read-only, once created you can modify the base table, this means operations like INSERT, UPDATE and DELETE are not allowed, for this reason is a good practice to use table partitioning to reduce that amount of data that need to be inserted on a Column Index Store and allow an easier reconstruction of an index when inserting new values to the table, because of this restriction the Column Index Store are more suited for scenarios that data don’t change frequently, like in Dataware House. The second restriction is that there can be only one Column Index Store per table, this limitation is not a real problem because you usually include ALL the columns of a table on the Column Index Store.
Another limitation is related to the creation time of the Column Index Store in comparison with a non-clustered Index, the average time could be from 2 to 3 times longer than the non-clustered index. However, despite the restrictions mentioned earlier, the Column Index Store can provide a great value on performance benefits, and also the compression you get from similar data on the same page.
The following data types can NOT be used on the Column Index Store: binary, varbinary, ntext, text, image, nvarchar(max), varchar(max), uniqueidentifier, rowversion, sql_variant, decimal (greater than 18 digits), datetimeoffset, xml, and data types based on CLR. Also the number of columns are restricted to 1024. Finally the index cannot be UNIQUE or CLUSTERED, contain Included Columns or have a defined order (Ascending or Descending)
The Column Index Store use their own compression technology, and that why they can be combined with the page and row compression data options. They can’t also be used on replication schemas, change tracking, change data capture or filestream. This technologies works on a Read/Write scenario and that why are not compatible with the read-only nature of the Column Index Store.
How to create a Column Index Store:
The creation of the Column Index Store can be done through T-SQL or SQL Server Management Studio
Column Index Store and Partitioned Tables
Let’s create a partitioned table named FactResellerSalesPtnd using the following code from MSDN
Step #1: Create the table FactResellerSalesPtnd (A Partittioned versión of: FactResellerSales)
Step #2: Let’s execute an query and confirm if the Column Index Store was used
Performance Benefits for Column Index Store
Cost
The relative cost of the Second Query (using a column index store) is 16% in comparison with the relative cost of the First Query (using a regular clústeres index)
Disk I/O
When executing the queries using STATISTICS IO ON (show the information related with the Disk I/O activity for the queries) you see a big improvement on the Second Query
Time
When executing the queries using STATISTICS IO ON (show the information in milliseconds related with the analyzing, compile and executing the queries) you see a time reduction on the Second Query
Experts agree that the performance improvement when using column index store on a table fluctuate between 10% and 100%. However as mentioned in this article applications that benefit the most are the ones with high read volumes like data warehousing, but not for high write scenarios like OLTP systems. The star and snow flake schemas usually take part on data warehousing and datamarts where the velocity on data extraction is more important that the efficiency on the data manipulation. The column index store can improve this type of scenarios that are ideal for this technology.
Bajen todos los servicios de SQL, incluyendo el SQL Engine, Analisys Services, Reporting Services, Integration Services, Full Text Search o cualquier otro que pueda hacer una sesión a SQL. También es bueno deshabilitar el TCP/IP protocol en caso que alguna aplicación se esté conectando a SQL server remotamente y haga sesión.
Ahora agreguen el switch –m (se debe agregar “;-m” sin espacios, ni las comillas) en los parámetros de inicio de SQL, esto hará iniciar el Servicio de SQL Server en modo single-user y solo podrá accederlo un solo usuario (es por esto que deben para cualquier servicio que haga sesión a SQL) y además debe tener privilegios de administrador en la maquina Windows
Luego de esto deberán ingresar a SQL usando sqlcmd en modo trusted podrán entrar a SQL Server, recuerden que deben estar logueados con una cuenta que sea miembro de los Administradores locales del Servidor
sqlcmd –E –S NombreServidor\NombreInstancia
Luego de entrar a sqlcmd podrá ejecutar cualquier comando que desee, ya que entrar con el contexto de un sysadmin, para colocar a alguno login como sysadmin podrán usar el stored procedures sp_addsrvrolemember: EXEC sp_addsrvrolemember 'NombreLogin', ‘sysadmin’; GO
Ya con esto tendrá un Login con privilegios de sysadmin, ahora ya puede bajar el servicio de SQL, remover el swith –m (esto remueve el modo single-user) e iniciar SQL Server, podrá usar el login al que se le otorgo los derechos de sysadmin y hacer los cambios que requieran.
Hola!!
Una de las nuevas características de SQL Server 2012 son las Contained Databases , gracias a esta característica podemos parcialmente aislar algunos objetos que por su naturaleza residen en la instancia de bases de datos como lo son los “logins”, si bien en términos de migración y consolidación esta es una gran ventaja, permítanme comentarles algunos aspectos a considerar a nivel de seguridad.
Se debe tener en consideración que si algún usuario en la contained database tiene el permiso de ALTER ANY USER, tendrá la capacidad de modificar los permisos de los usuarios y dar permisos de conexión a cualquier persona sin conocimiento del Administrador de SQL, usuarios que pertenezca a los roles de bases de datos “db_owner” y “security_admin” obtendrán automáticamente dicho permiso, dando como resultado un hueco de seguridad, por esto tenemos que ser muy cuidadosos con dar estos permisos a usuarios no administradores de SQL.
Otro escenario que debemos considerar es que cuando nos conectamos a un contained database y en esa misma instancia se encuentra alguna base de datos con la cuenta “guest” habilitada, una vez que el usuario se ha podido conectar a la contained database, también tendrá la capacidad de acceder a esa base de datos, esto en conjunto que el escenario anterior donde una usuario con el permiso de ALTER ANY USER pude dar acceso a cualquier persona para conectarse al servidor, se convierta en un gran problema de seguridad. Es por ello que debemos minimizar el uso de este permiso y constantemente auditar el acceso y uso del permiso ALTER ANY USER en las bases de datos.
Ahora platiquemos de otro escenario, ¿Que sucedería si creamos un usuario en nuestra base de datos de contenido, con el mismo nombre de un login existente en nuestra instancia? Si accedemos a la base por medio de este login y a su vez al momento de conectarnos especificamos la Contained Database como catálogo inicial, lo que obtendríamos sería una negación del servicio para este login, ya que el contexto de seguridad evalúa usuario y contraseña sobre la Contained Database en lugar de el entrono de logins de SQL.
Para finalizar y tomando en cuenta mis dos recomendaciones anteriores, les expongo lo siguiente. ¿Cual es el impacto de darle “attach” a una base de datos de contenido en una nueva instancia? , al attachar una Contained Database estaremos abriendo una puerta de conexión a los usuarios con password de la Contained Database attchada. ¿Cómo podemos evitar el riesgo de acceso a usuarios no autorizados a esta instancia? usando la opción de RESTRICTED_USER, ya que esta previene la autenticación para usuarios con passwords de la Contained databases.
Todas estas consideraciones son fácilmente manejables teniendo una adecuada delegación de control de acceso y mejores prácticas de seguridad.
Espero les sean de utilidad estos puntos y para mayor información de este y tros escenarios pueden consultar en TechNet:
http://technet.microsoft.com/en-us/library/ff929055
Hello community,
This time I was working on a customer in Jamaica and faced an issue installing updates in a SharePoint 2010 farm, basically we were installing a CU and when we try to start the PsconfigGUI we got an error screen preventing us to update SharePoint properly:
At first sight I though reinstalling the hotfix is an option but I got a message saying, the fix is already installed, so that meant binaries were already there.
Ok a reboot will fix it like in the most cases, but this time didn't work.
Then looking into the KB I found that Installcheck -noInstallcheck psconfig parameters could help, so I ran PowerShell and typed psconfig -cmd installcheck -noinstallcheck.
Magic, this time SharePoint Configuration Wizard started and completed successfully.
Hope this can help you in some way!
Hola SharePointeros
Esta ves estuve trabajando con un cliente en Jamaica y me encontré con un problema instalado actualizaciones en una granja de SharePoint 2010, básicamente estábamos instalando un CU y después de instalar los binarios ejecutamos el Asistente de Configuración de SharePoint como mandan los cánones y nos arrojó una pantalla de error y no nos permitió seguir:
En primera instancia tratamos de re-instalar el CU pero nos arrojó el clásico mensaje diciendo que el CU ya estaba instalado.
Entonces pensé, reiniciemos y eso seguro lo corrige, pero sorpresa no fue así.
Tuve que ir a mirar en la base de datos de conocimientos y encontré que los parámetros Installcheck -noInstallcheck del psconfig me podría ayudar, así que abrí una sesión de PowerShell como administrador y escribí: psconfig -cmd installcheck -noinstallcheck.
Magia, en esta ocasión el asistente de configuración de SharePoint inició y completó sin errores.
Espero que les sea útil!