Selects em DB2

Bem, recentemente estou trabalhando em uma solução que integra um pouco de SQLServer e um pouco de DB2. Estou apanhando muito para me ambientar neste novo ambiente. Ainda não achei material prático que mostre as diferenças entre SQLServer e DB2. Uma hora eu monto um site que mostra as diferenças... Mas, enquanto isso, vou compartilhar alguns SELECTs complexos que precisei ( e apenhei muito ) montar...

Este SELECT mostra as médias de uns contadores, agrupada por hora, por servidor. Se fosse no SQLServer eu criaria uma tabela temporária com 4 colunas e incluiria os registros nela. Mas o usuário que eu tenho não permite criar tabelas temporárias, então, o jeito foi tentar jogar tudo em uma mesma coluna.

SELECT M.VNOMESERVIDOR,

HOUR(m.VHoraInicio) AS hora ,
------------------------------------------------------------
( SELECT
AVG( M1.VVALORCOLETADOMEDIA ) * 100
FROM
MNT.VIW_ITEMCONSOLIDADO M1
WHERE
M1.VIDITEMMONIT = 124 -- % Processador dotNET
AND M1.VDATAREGISTRO = M.VDATAREGISTRO
AND M1.VNOMESERVIDOR = M.VNOMESERVIDOR
AND HOUR( M1.VHORAINICIO ) = HOUR( M.VHORAINICIO )

) AS Processador_DotNet,
-----------------------------------------------------------
( SELECT
AVG( M1.VVALORCOLETADOMEDIA ) * 100
FROM
MNT.VIW_ITEMCONSOLIDADO M1
WHERE
M1.VIDITEMMONIT = 103 -- % Processador IIS
AND M1.VDATAREGISTRO = M.VDATAREGISTRO
AND M1.VNOMESERVIDOR = M.VNOMESERVIDOR
AND HOUR( M1.VHORAINICIO ) = HOUR( M.VHORAINICIO )

) AS Processador_IIS,
-----------------------------------------------------------
( SELECT
AVG( M1.VVALORCOLETADOMEDIA ) * 100
FROM
MNT.VIW_ITEMCONSOLIDADO M1
WHERE
M1.VIDITEMMONIT = 2 -- % Processador COM+
AND M1.VDATAREGISTRO = M.VDATAREGISTRO
AND M1.VNOMESERVIDOR = M.VNOMESERVIDOR
AND HOUR( M1.VHORAINICIO ) = HOUR( M.VHORAINICIO )

) AS Processador_COMPlus

FROM
MNT.VIW_ITEMCONSOLIDADO M
WHERE
M.VDATAREGISTRO = CURRENT DATE
GROUP BY M.VNOMESERVIDOR , M.VDATAREGISTRO, HOUR( M.VHORAINICIO )

Session State - Compartilhando sessões no ASP.Net

Session-State

Fonte: http://forums.asp.net/p/7504/7504.aspx#7504

1-Localização do armazenamento:

InProc – a sessão é mantida como objetos ativos no web Server (aspnet_wp.exe)

StateServer – A sessão é serializada e armazenada em memória, em um processo separado (aspnet_state.exe). A vantagem é que o Stateserver pode ser executado em outra máquina

SQLServer – a sessão é serializada e armazenada em um MS-SQLServer.

Performance:

No InProc é mais rápido, mas, quanto mais dados de sessão, mais memória é consumida no webserver, que pode afetar a performance. Além disso, qualquer situação que provoque o restart do aspnet_wp.exe fará com que um novo processo seja criado e, assim, todas as sessões atuais serão perdidas.

StateServer: quando tipos básicos, como string, inteiros, etc. são armazenados, é cerca de 15% mais lento que o método In-Proc. Quanto mais serialização/desserialização for necessária, maior a penalidade na performance. A vantagem é que, rodando em um servidor separado, este pode ser dedicado a essa função (um luxo?).

SQLServer: quando tipos básicos, como string, inteiros, etc. são armazenados, é cerca de 25% mais lento que o método In-Proc. Mesmas considerações para o StateServer. A vantagem desse método é que se o aspnet_wp for reiniciado, os dados das sessões serão preservados (dentro do tempo limite de validade). Pode-se ainda, utilizar um SQL em cluster, para garantir escalabilidade e, combinado com um balanceamento de carga de rede, distribuir as requisições, diminuindo o tempo de resposta.

Prevalece o entendimento de que se deve procurar armazenar as sessões com tipos básicos, visto que estes utilizam um código performático para a serialização, desserialização. Para outros tipos, é utilizado um método binário, que é mais lento, para esta tarefa.

Mais dicas, acesse: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/aspnetsessionstate.asp

Postado por Blog do Lucilius às 05:13 0 comentários

Acessando base de dados remotas com linkedserver

Estou trabalhando em um projeto que tem a necessidade de restringir os acessos de usuários a uma base de dados, dando permissão de leitura e escrita com base em Application Roles.

Até aí tudo bem, elas fucionam e são rápidas. Mas acontece que a aplicação está distribuída em várias bases de dados, em servidores diferentes. Então entra em cena a figura do LinkedServer.

Vou postar aqui um case onde, conectando como um usuário sem restrições totais, aplicando uma Application Role, a partir de uma aplicação, liberar um linkedserver temporariamente para o mesmo usuário e fazer os devidos acessos.

Fácil, depois de fuçar um pouco... Aguardem

Postado por Blog do Lucilius às 09:53 0 comentários