Seguridad Informática de los metadatos en documentos ofimáticos

Hoy os dejo un par de vídeos de Chema Alonso, consultor en seguridad en Informatica64, que nos habla de esa información oculta que queda residente en nuestros documentos de Office por ejemplo: los metadatos.

¡Intel compra McAfee!

Por 6.000 millones de euros Intel (empresa líder en procesadores) ha comprado McAfee, la segunda compañía mundial en seguridad informática (tras Symantec).

La verdad es que el mercado TI sigue con sus convulsionadas compras: Palm por parte de HP, Sun por Oracle...¡esto es una locura!, ¿dónde quedaron aquellas empresas especializadas, que el usuario de a pie podía identificar en un sector (procesadores, software, seguridad, etc)?. La verdad es que la informática ya hace tiempo que dejó su romanticismo en favor de lo económico. Ahora es mucho más rentable crear un producto, mejor si es lo más novedoso posible, y venderlo por el máximo dinero posible. Da igual quién y cómo lo utilizará en el futuro, y ni siquiera si servirá para lo que uno lo diseñó....lo importante es enriquecerse. Empresas en quiebra han existido siempre, otras las compraban...pero era porque querían crear una marca, una imagen que fuera reconocida en un campo y reinar gracias al trabajo bien hecho y al reconocimiento del usuario final.

Hay creadores gurús, de productos a los que todos nos viene alguno a la cabeza (Google, Facebook, etc), que, en mi opinión personal, han amasado en tan poco tiempo tal cantidad de dinero (y no son tan mal vistos como Bill Gates en su día en Microsoft,...no sé bien por qué...) que "les resbala" bastante si en unos años dichos productos forman parte de alguna subsección de la empresa del sector que sea. Ellos ya han conseguido más de lo que soñaban....quizás inmerecidamente, mientras empresas históricas desaparecen porque la sociedad ha dejado de entender que la informática está para servirla, para hacerle la vida más cómoda, y no para crearle cada vez más necesidades inútiles, y encima algunas muy, muy, muy caras como en el caso de Apple (por cierto, ¡vaya puff el nuevo IPhone 4!, y encima justifican sus gravísimos fallos técnicos acusando a la competencia de que tiene problemas similares: ¡venga Steve Jobs, te admiraba, no caigas en esos derroteros, por favor!). Nos vemos.

El plan de ejecución en SQL Server 2005/2008

Cuando se ejecuta cada query, internamente se ejecutan una serie de operaciones, que varían según la consulta, los datos y el motor. El conjunto de pasos que tiene que realizar el motor para ejecutar la consulta, se llama Plan de Ejecución. ¿Qué operaciones podemos encontrar en el plan de ejecución?.

Table Scan:

Significa que el motor tiene que leer toda la tabla. Esto solo puede suceder cuando la tabla es Heap (o sea, no tiene un índice clustered). En tablas con pocos registros un Table Scan es la mejor opción, ya que produce poco overhead. De hecho la tabla puede tener índices y sin embargo el SQL elige usar un table scan porque sería más rápido. Pero cuando la tabla es más grande, no debería haber Table Scan, ya que es muy costoso. Para solucionar este problema, hay ver si la tabla tiene índices y si se están usando correctamente. Lo importante es prestarle atención cuando vemos un table Scan. Muchas veces, nuestro problemas de performance pasan por ahí.

Ejemplo: (Creamos una tabla sin ningún tipo de índice y se le hace una consulta)

CREATE TABLE [TablaPrueba1]

(

Campo1 int IDENTITY (1, 1) NOT NULL ,

Campo2 int,

Campo3 int,

Campo4 int,

Campo5 char (30)

)

SELECT * FROM TablaPrueba1

Clustered Index Scan:

Esta operación es muy similar a un table scan. El motor recorre toda la tabla. La diferencia entre uno y otro, es que el Clustered Index Scan se realiza en una tabla que tiene un índice Clustered y el Table Scan en una tabla que no tiene este tipo de indice. Otra vez tenemos que evaluar si esta opción es la que realmente queremos. Muchas veces, por un mal uso de los índices, se ejecuta esta operación, cuando en realidad queríamos otra más eficiente.

Ejemplo:
CREATE TABLE [TablaPrueba3]
(

Campo1 int IDENTITY (1, 1) NOT NULL,

Campo2 int,

Campo3 int,

Campo4 int,

Campo5 char (30)

CONSTRAINT [PK_Campo3] PRIMARY KEY CLUSTERED ([Campo1])
)

SELECT * FROM TablaPrueba3


Clustered Index Seek:

Si vemos esta operación, en general, podemos estar contentos. Significa que el motor está usando efectivamente el índice Clustered de la tabla.

Ejemplo:

(Usamos la tabla creada en el ejemplo anterior con un índice Clustered, le insertamos 10000 registros para que el motor prefiriera usar el índice antes que un scan y filtramos por el índice).

SET NOCOUNT ON
DECLARE @Top int
SET @Top = 0
WHILE @Top <> 10000
BEGIN
INSERT INTO TablaPrueba3 VALUES (convert(int,rand()*20000),convert(int,rand()*20000),convert(int,rand()*20000), ‘P’)
SET @Top = @Top+1
END


SELECT * FROM TablaPrueba3 WHERE Campo1 = 2

Index Seek:
Aquí también si vemos esta operación, podemos estar contentos. Es similar al Clustered Index Seek, pero con la diferencia de que se usa un indice Non Clustered.

Ejemplo: (Creamos un índice Non Clustered sobre la tabla del ejemplo anterior)


CREATE INDEX [IDX_Campo3] ON [dbo].[TablaPrueba3](Campo2,Campo3) ON [PRIMARY]


SELECT Campo2 FROM TablaPrueba3 WHERE Campo2 = 2 and Campo3 = 2

Index Scan:

Esta operación se ejecuta cuando se lee el índice completo de una tabla. Es preferible a un Table Scan, ya que obviamente leer un indice es mas eficiente que una tabla. Esta operación puede ser síntoma de un mal uso del índice, aunque también puede ser que el motor haya seleccionado que esta es la mejor operación. Es muy común un Index Scan en un join o en un ORDER BY o GROUP BY.

Ejemplo: Usemos la tabla TablaPrueba3, creada en el ejemplo anterior:

(Como no hay ningún filtro, el motor debe leer toda la tabla. Sin embargo, al traer solo el Campo2, que pertenece a un índice Non Clustered, en vez de hacer un Table Scan, es mas optimo hacer un Index Scan).

SELECT Campo2 FROM TablaPrueba3

Bookmark Lookup:

Esta es una operación muy importante, donde hay algunas diferencias entre 2000 y 2005 que vale la pena saber. El Bookmark Lookup indica que SQL Server necesita ejecutar un salto del puntero desde la página de índice a la página de datos de la tabla para recuperar los datos. Esto sucede siempre que tenemos un índice Non Clustered. Para evitar esta operación, hay que limitar los campos que queremos traer en la consulta. Si el campo que vamos a extraer, esta fuera del índice, entonces se va a ejecutar esta operación y no queda otra opción (para SQL Server 2000). Acá reside la importancia de evitar los "SELECT * FROM".

Ejemplo:(Se trae todos los campos de la tabla, filtrando por un campo perteneciente a un índice non clustered).

SELECT Campo2, Campo3, Campo4 FROM TablaPrueba3 WHERE Campo2 = 2

SQL Server 2000:

SQL Server 2005:

Si vemos el plan de ejecución (de SQL Server 2000), se realizó la operación Index Seek, pero además, aparece la operación Bookmark Lookup. Esto pasa porque en este ejemplo además de traer el campo2 y campo3 que son parte del índice, debe leer el campo5, que solo está en la página de datos y no en el índice. Ademas, como podemos ver, la misma consulta, para exactamente la misma tabla con los mismos datos e índices, pareciera generar un plan de ejecución diferente en SQL Server 2000 y SQL Server 2005.

Pero sin embargo, no es así. Dado que dentro de la estructura interna de un índice non clustered, se almacena un puntero al índice clustered, el boorkmark lookup internamente se traduce como un salto a la lectura del índice clustered de la tabla.  Pero la real diferencia entre ambas versiones (2000 y 2005) no es una simple cuestión estética. Una de las más interesantes nuevas características de SQL Server 2005, es la posibilidad de incorporar en la pagina final del índice (donde residen los valores), campos de la tabla que son externos al índice. Significa que el campo no es parte de la estructura del índice, que no va a ser utilizado por el motor a la hora de filtrar y buscar, pero sin embargo, su contenido está copiado a la estructura de la última página del índice. La ventaja de esto, es que le ahorra al motor del SQL, hacer el boorkmark lookup, operación bastante costosa. La desventaja, es que al hacer más grande el índice, entran menos registros por página, lo cual podría llevar a que se tengan que hacer mas operaciones de I/O. Por lo tanto, es necesario hacer una evaluación de costo/beneficio, antes de incluir campos adicionales al índice.

Joins:

Un join es la relación entre 2 tablas. SQL tiene 3 tipos de joins: Neested Loop Join, Merge Join y Hash Join. Dependiendo de las características de la consulta y de la cantidad de registros, el motor puede decidir uno u otro. Ninguno es peor o mejor “per se”. Todo depende de las características de la consulta y del volumen de datos.

• Neested Loop Join: Es el más frecuente. Es también el algoritmo más simple de todos. Este operador fisico es usado por el motor cuando tenemos un join entre 2 tablas y la cantidad de registros es relativamente baja.

• Merge Join: Generalmente se usa cuando las cantidades de registros a comparar son relativamente grandes y están ordenadas. Aun si no están ordenadas, el motor puede predecir que es más rápido ordenar la tabla y hacer el merge join que hacer un Neested Loop Join. En muchas situaciones es frecuente ver que una consulta anteriormente usaba Neested Loop Join y en algún momento paso a usar un Merge Join. La razón de esto, es porque el volumen de datos aumentó y por lo tanto, es más optimo usar un Merge join.

• Hash Join: Mientras que los Loop Joins trabajan bien para pequeños volúmenes de datos y los merge join para conjuntos moderados de datos, el hash join es especialmente útil en grandes conjuntos de datos, generalmente en datawarehouses. Este operador es mucho mas paralelizable y escalable. También se usa generalmente cuando las tablas relacionadas no tienen índice en ninguna de los campos a comparar. Hay que prestar atención si vemos este tipo de operaciones, ya que puede significar un mal uso de los índices. Sin embargo, los hash joins consumen mucha memoria y SQL Server tiene un límite en la cantidad de operaciones de este tipo que puede efectuar simultáneamente. Existen varios subtipos de hash joins. Pulsa aquí para más información.

Ejemplo: (Se va a ejecutar exactamente la misma consulta con una tabla con 50 registros y con 2000 registros, para ver cómo cambia en función del volumen de datos, el tipo de operación)

SELECT T1.* FROM tablaprueba3 T1 INNER JOIN TablaPrueba3 T2 ON T2.Campo4 = T1.Campo1

Consulta con 50 registros en la tabla

Consulta con 20000 registros en la tabla

 

Agregaciones:

Las agregaciones refieren a agrupar un conjunto grande de datos en un conjunto de datos más pequeño.

• Stream Aggregate: Este tipo de operaciones ocurre cuando hay se llama a un función de agregación, como MIN, COUNT, MAX, SUM, etc. El operador Stream Aggregate requiere que la información esté ordenada por las columnas dentro de sus grupos. Primero, el optimizador ordenará si los datos no están ordenados por un operador Sort anterior. En cierta manera, el Stream Aggregate es similar al Merge Join, en cuanto a en que situaciones se produce.

• Hash Match (Aggregate): Hay que tener cuidado cuando vemos este operador. Esta operación también ocurre cuando se llama a funciones de agregación del tipo MIN, COUNT, AVG, etc. Así como el Stream Aggregate es comparable al Merge Join, el Hash Match Aggregate es similar al Hash Join. Lo que hace internamente es armar una tabla de hash. En situaciones donde la cantidad de registros es elevada o no se están indexadas las columnas por las cuales agrupa la consulta, el motor del SQL va a elegir esta operación.

Ejemplo:

SELECT MAX(Campo2) FROM TablaPrueba3 GROUP BY Campo2

SELECT MAX(Campo4) FROM TablaPrueba3 GROUP BY Campo4

Como podemos observar en este ejemplo, las 2 consultas son prácticamente similares en estructura, solo que el primer caso agrupa el campo2 que esta indexado y en el segundo caso, agrupa el campo4, que no está indexado y por eso usa el operador Hash Match.

Sort:

Otro punto para observar, es cuando vemos un sort. Como el nombre lo indica, esta operación ordena. Ahora, el Sort solo se hace cuando el campo o los campos que se desean ordenar, no están indexados. A veces esta operación se ejecuta sola, sin que nosotros hayamos puesto en la consulta el ORDER BY, porque el motor necesita ordenar los datos por alguna razón, por ejemplo, para ejecutar un Merge Join. Pero recordemos que si ordenamos por un campo indexado y este indice esta siendo utilizado, no se ejecuta esta operación.

Ejemplo:

SELECT * FROM TablaPrueba3 ORDER BY Campo3

Y ahora para practicar y profundizar todo un poco más entra en el siguiente post de TechNet Magazine. ¡Felíz optimización!. Nos vemos.

Windows XP SP2: instalando nuevas actualizaciones de seguridad

Sí, has oído bien.... A pesar que Microsoft dejó de dar soporte a esta versión de XP, si eres de esos bichos raros que por algún motivo no has actualizado a SP3 (ni tampoco decidiste dar el paso a Vista o Seven), aún puedes seguir recibiendo actualizaciones importantes sin más que seguir las instrucciones que F-Secure nos da. Básicamente consiste en editar el registro de Windows la clave HKLM\System\CurrentControlSet\Control\Windows, y cambiar el valor DWORD de CSDVersion desde 200 a 300. Reinicias y ¡listo!.

El portátil más barato del mundo

Sí, lo tenía claro, pero con esta noticia ahora lo tengo cristalino: en la India se están haciendo las cosas bien, muy bien, acercando la tecnología a una población de más de 1.000 millones de habitantes. Para el próximo año 2011 saldrá este modelo de portátil por un precio de ¡27 euros!, o incluso menos (se habla de 10-15 euros). La tasa de alfabetización de este país es una de las más bajas del planeta y este tipo de noticias seguro contribuirá a mejorar. De hecho detrás de este proyecto (y de otros más ambiciosos) está el mismísimo gobierno de la nación (Instituto Indio de Tecnología y el Instituto Indio de Ciencia). India aporta un 3% de su presupuesto anual a educación. Un aplauso por todo esfuerzo que lleve a impulsar la sociedad de la información para todos.

El equipo en sí estará equipado con Linux, y todo un abanico de aplicaciones libres. Además dispondrá, dado su diseño modular, de la posibilidad de incorporar nuevas características, hardware y software.