Frequentemente eles pecam nas questões de desempenho e segurança. Veja como encontrar um equilíbrio na visão de diversos especialistas

Parece que gestão de riscos de TI se resume apenas em identificar dados críticos e fornecer mais proteção a eles. Mas, infelizmente, quando se trata de banco de dados, muitas companhias retrocedem ao utilizarem certas fórmulas.

O problema é que em muitas empresas o desempenho do banco de dados pode ter prioridade sobre a segurança. Embora o ideal seja manter equilíbrio entre os dois, a segurança, em diversas ocasiões, acaba ficando de lado.

“Os DBAs e desenvolvedores de aplicativos simplesmente não têm tempo ou não querem lidar com segurança. Isso aumenta o custo do desenvolvimento de produtos”, avalia Julie Lockner, analista do Enterprise Strategy Group. Eles são pressionados para adicionar mais aplicações e funcionalidades, além de ter que lidar com o aumento do volume de dados, e isso aumenta os ciclos de testes. Para Lockner, “isso é prioridade. Temos que abandonar os recursos? Ou temos que fazer ciclos extras para amarrar e adicionar camadas de segurança em volta dela?”

Invasões maliciosas e hackers podem tirar proveito desta guerra de prioridade dentro dos departamentos de TI. Eles acessam dados que não deveriam, lançando ataques SQL para tirar proveito da vulnerabilidade de links de aplicativos do banco de dados e espalhar o problema para o sistema de gestão e, assim, acessar dados estratégicos.

A única maneira de conseguir proteção é colocar a segurança de dados críticos como primeira preocupação. A começar com estes três princípios de proteção de base de dados.

Conhecer a si mesmo:
Muitas companhias não são capazes de proteger dados de missão crítica, porque, simplesmente, não entendem como as partes móveis do seu ambiente de banco de dados funcionam. Para controlar o trabalho, a TI deve ter o claro entendimento de onde estão as informações mais importantes e como são usadas.

“Você tem armazenamento de dados, mas deve ter muitas aplicações em conjunto. E você pode não saber quem usa os sistemas caso tenha concedido muitos privilégios”, ensina Mel Shakir, CTO da NitroSecurity, companhia de gerenciamento de banco de dados e segurança da informação, recentemente adquirida pela McAfee. “Você pode nem sequer saber onde os dados críticos estão e se foram copiados para fora do sistema ou movidos para testes em outro lugar.”

Etapas valiosas incluem digitalizações não autorizadas de banco de dados que podem ter sidos criados por outros departamentos, documentando esquemas de privilégio e classificando BDs da companhia de acordo com os riscos. Isso pode ajudar a obter o máximo do investimento em segurança do banco de dados.

Uma vez que a TI sabe onde estão os bancos de dados, pode ter certeza que a segurança está configurada e atualizada, além de usar avaliações de vulnerabilidades para decidir o nível de proteção que precisam. Eles podem decidir, por exemplo, se querem supervisão constante por meio de monitoramento de software para rastrear o que os usuários fazem com as informações armazenadas em todos os momentos.

Se as organizações de TI não encontram todos os bancos de dados espalhados por suas infraestruturas, elas podem entrar em choque se outra pessoa encontrá-los. O caso em questão é de um escritório de controladoria do Texas. No início deste ano, a companhia foi publicamente constrangida quando encontraram nomes e endereços, datas de nascimento, números do seguro social e números de licença de motorista de mais de 3,5 milhões de pessoas nos bancos de dados de três agências do estado que haviam sido expostas por quase um ano em um banco público, não criptografado e acessível.

Medo de ocorrências de desempenho é a principal razão pela qual as organizações de TI não usam ferramentas de monitoramento e auditoria. A primeira geração desta ferramenta ganhou reputação entre os DBAs por causar lentidão no banco de dados e falhas de segurança. Fornecedores de segurança tentaram limpar estes problemas, mas o medo persiste.

As aplicações destas bases de suporte de dados são, geralmente, tarefas críticas, tais como atendimento ao cliente, onde o desempenho é altamente visível. “Quando se trata de servir os consumidores, desempenho geralmente ganha, ou a equipe decidi se comprometer”, aponta Noa Bar Yosef, estrategista de segurança da Imperva, empresa de aplicação de firewall. “Mas no final a falha é crucial para a descoberta, responsabilização e recuperação daquilo que está faltando.”

Boa higiene do banco de dados:
Hackers podem se aproveitar quando as empresas não alteram as senhas dos banco de dados, concedem privilégios excessivos para os usuários, deixam dados críticos sem correção ou falham no gerenciamento das configurações de banco de dados.

Muitos DBAs e desenvolvedores deixam a senha padrão inalterada para agilizar a administração e integração com as aplicações. Mas essa atitude também torna a invasão de sistemas e o acesso a dados da empresa mais fáceis.

Todos os bancos de dados vêm com nomes de usuários padrão e senhas que deixam a instalação mais fácil. Um invasor pode usar o Google para compilar uma lista de combinações e usá-las de forma maliciosa como, por exemplo, fazer download ou deletar tabelas de banco de dados. Ao eliminar o padrão, como nomes de usuários e senhas se torna fácil e barato de corrigir e, assim, melhorar a postura de segurança da companhia. Talvez, por ser óbvio, muitos departamentos de TI não se preocupam em verificar isso.

Ao distribuir muitas credenciais também pode criar vulnerabilidades internas. Quando o tempo e recursos estão apertados, companhias não gastam tempo definindo quem e o quê acessar ou qual banco de dados. Eles dão privilégios aos mesmos grupos inteiros, razão pelo qual os mesmo grupos de pessoas executam o mesmo trabalho no banco de dados, disse Bar Yosef, da Imperva. Da mesma forma muitas empresas continuam lutando com atualizações e gerenciamento de vulnerabilidades.

Isso normalmente leva de cinco a nove meses para a companhia atualizar o banco de dados, de acordo com o grupo de usuários independentes da Oracle, deixando aberto a ataques durante este tempo. Mais uma vez, questões de desempenho são barreiras para qualquer atualização, assim como os testes de atualização de TI devem testar o impacto das atualizações.

O risco de desempenho é real. Segundo Rajesh Goel, CTO da Brainlink International, por exemplo, disse que trabalhou com atualização de 20 milhões de banco de dados para uma grande empresa de logística, a qual a atualização da Oracle otimizou o desempenho global para um fator 16.

Mas empresas também não podem se dar o luxo de deixar bases de dados críticas sem correção. Uma vez lançados, informações de correções estão disponíveis para qualquer um, segundo Alex Rothacker, da TeamShatter, assim, os delatores terão que fazer engenharia reversa das correções para criar invasões bem sucedidas contra servidores sem atualizações.

Companhias devem considerar o uso de compensação de controles, como melhor segmentação e configuração de rede, que irá manter os bancos de dados críticos protegidos de algumas forma, assim que examinarem como as atualizações afetam missões críticas.“Se você não pode manter os valiosos servidores com as últimas atualizações do momento, então você deve incluir esses ativos críticos dentro de uma zona para defendê-los”, disse Mike Lloyd, CTO na RedSeal Systems, empresa de software de monitoramento e gerenciamento de risco. Isso significa colocar ativos críticos em servidores altamente seguros com sistemas prontos para serem atualizados, com configurações atualizadas e monitoramento abrangente.

Qualquer um esforço de segurança de base pode não ser uma grande tarefa para enfrentar por si só, mas a escala de viagens de muitas companhias. Isso pode levar um grande tempo para implantar um plano de segurança cuidadoso por meio de centenas ou até mesmo milhares de bancos de dados.

Por meio da segmentação e compartilhamento de banco de dados, os times de TI podem colocar controles ao redor das informações mais importantes. Este modelo de segurança “garoto na bolha” determina um perímetro interno em torno das máquinas mais sensíveis, disse Lloyd.

Nenhum banco de dados é uma ilha:
Por último, o mais importante para assegurar as infraestruturas de bancos de dados é protegê-las tão bem quanto os próprios bancos de dados em si. Invasores frequentemente acessam banco de dados por meio de camadas de aplicações, usando ataques SQL. Isso pode enganar bancos de dados oferecendo mais acesso as informações do que o desenvolvedor pretendia. “Muitas organizações permitem esses ambientes de aplicações para continuarem expostos”, afirmou Scott Crawford, analista e consultor da Management Associates. “Ataques SQL infelizmente permanecem comum.”

As equipes de segurança devem trabalhar em conjunto com DBAs e gerentes de aplicações para não ficarem expostos – da mesma fora que as validações requeridas no banco de dados são usadas para evitar estes tipos de vulnerabilidades. “Dividir direitos e regras levam um longo caminho”, avisa José Nazário, gerente sênior de pesquisa em segurança da Arbor Networks. Ele adicionou que companhias não deveriam permitir que usuários não confiáveis consultassem informações do banco de dados como tabelas, funções, entre outros.

Times de TI precisam considerar todos os ângulos de ataque quando planejarem a segurança do seu banco de dados. Companhias devem usar as entradas dos usuários dentro do banco de dados para prevenir ataques como estouro de buffer e injeção de SQL. “Tudo em torno do banco de dados deve estar seguro: o nível de hospedagem da rede e de aplicação.”

Essa advertência deve ser parte dos alicerces de qualquer boa estratégia de proteção crítica de banco de dados. Os esforços precisam ocorrer em múltiplos níveis: não pare de configurar e monitorar os bancos de dados. TI também deve corrigir e verificar o regulamento das aplicações e colocar os bancos de dados críticos na parte mais segura da rede.

Fonte: Passos para tornar seu banco de dados mais seguro

Aplicativos web recebem 71 tentativas desse tipo de taque por hora, mas isso pode chegar a 1,3 mil. Considere os conselhos de segurança para impedir ataques SQL

Em médias, aplicativos web recebem 71 tentativas de ataque por injeção de comandos SQL por hora. Mas durante picos de ataque, esse volume pode atingir 1,3 mil por hora. Essa descoberta veio da fornecedora de segurança Imperva, que divulgou uma nova pesquisa sobre ataques SQL. Para tal estudo, a companhia monitorou 30 aplicativos web diferentes – todos reais, de diferentes tamanhos e utilizados por diferentes indústrias – durante nove meses. Nesse período, a empresa viu o número de ataques diários aumentar, em média, 34%.

Os ataques contra aplicativos web, infelizmente, já são muitos eficientes. Desde 2005, eles resultaram em 83% das brechas bem sucedidas relacionadas à hacking, de acordo com a Privacy Rights Clearinghouse. O motivo é simples: a maioria dos aplicativos web tem vulnerabilidades que podem ser facilmente exploradas por quem comanda os ataques.

A disponibilidade de ferramentas automáticas para testes de penetração facilita o trabalho. Só em injeção de SQL, por exemplo, o código aberto Sqlmap pode lançar cinco tipos diferentes de ataques. Popular também – e usada por LulzSec, entre outros – é o Havij, uma ferramenta automática de SQL para Windows, distribuída pela empresa de segurança iraniana ITSecTeam. As duas ferramentas podem identificar (pela digital) bancos de dados individuais, restaurar senhas e nomes de usuário, eliminar colunas e tabelas, rodar SQL e, às vezes, até executar comandos por meio do sistema operacional do servidor de banco de dados.

Com tais ferramentas em circulação, e grandes vulnerabilidades em aplicativos web, o que empresas podem fazer para se protegerem? Quando se trata de impedir ataques SQL, comece com esses conselhos:

1. Lista negra de hosts maliciosos.

Quase um quarto dos ataques SQL registrados pela Imperva, em julho de 2011, vieram de três hosts. Além disso, metade dos dez principais hosts que lançaram ataque SQL geraram até duas mil ameaças em um período entre um e sete dias, e mais de 30 hosts geraram, ao menos, 100 ataques num período de 48 horas. Tudo isso significa que os hosts mais perigosos podem ser identificados e adicionados à lista negra de acesso ao banco de dados.

2. Pool de recursos.

Negócios que compartilham inteligência em ataques SQL podem ter uma ideia melhor de quais hosts lançam os ataques. Dito isso, de acordo com a Imperva, “a velocidade de atualização da lista negra deve ser maior para ficar em dia com as novas ameaças”, porque, em média, os hosts se mantêm ativos apenas por meio dia.

3. Acesso minimizado.

Restrinja os dados que qualquer aplicativo web pode resgatar do banco de dados. Nunca permita acesso ao banco de dados em nível de administrador a aplicativos web.

4. Codifique dados.

Nunca armazene dados em formato de texto simples. Em vez disso, codifique os dados e dificulte senhas, para que caso um ataque chegue ao banco de dados, extraia o mínimo possível de informações valiosas.

5. Desconfie de usuários.

“Qualquer input é maligno”. Esse é um mantra essencial para aplicativos web, de acordo com a Microsoft. O que significa que, em um cenário ideal, desenvolvedores de aplicativos web somente permitiriam input esperados e bloqueariam todo o resto.

6. Perfil de aplicativo.

Compreenda o comportamento normal do aplicativo web, para que fique mais fácil identificar qualquer comportamento anormal, como tentativas de executar mais buscas em bancos de dados do que o normal ou utilizando inputs incomuns.

7. Padronize inputs.

Padronize input de banco de dados “para evitar tentativas de evasão”, aconselha a Imperva. Depois compare o padrão com inputs maliciosos conhecidos para identificar ataques em andamento.

8. Cuidado com automação.

Como os ataques SQL são lançados por meio de ferramentas automáticas, preste atenção aos indicadores dessa técnica. De acordo com a Imperva, “existem diversos mecanismos para detectar o uso de clientes automáticos, como políticas baseada em taxas e coerção de resposta à desafios por clientes válidos”.

As técnicas acima ajudarão a equipe de TI a bloquear ataques SQL. Elas não vão impedir absolutamente todos os ataques a aplicativos web, mas, devido à prevalência de vulnerabilidades nesses aplicativos e à habilidade dos responsáveis pelos ataques em explorar, com êxito, essas falhas, os negócios precisam de toda ajuda que conseguirem.

fonte:8 técnicas para bloquear ataques SQL

Com a chegada de cada nova versão do SQL Server, novas tecnologias são introduzidas ou ha melhorias nas ja existentes. Quando o SQL Server 2005 foi lançado, uma nova solução de alta disponibilidade denominada Mirror foi um dos grandes diferenciais em relação sua versão anterior (SQL Server 2000).

Como o Mirror Funciona:
Vamos supor que exista o servidor SRV01 com a base BSE1 na instancia ITC1, ja no servidor SRV2, existe a instancia ITC2. Voce foi designado para propor uma solução de alta disponibilidade, porem, voce não possui uma storage (Armazenamento externo), e como lhe foi dito que a diferença entre a base de contingencia e a principal deve ser minima, o log shipping pode até ser aceitavel, porem não é recomendado cria-lo para ficar rodando em um intervalo muito pequeno, como voce precisa ter alta disponibilidade de toda uma base, a replicação se torna uma solução inviavel, portanto sua melhor opção (Até o SQL Server 2008) é a utilização do Mirror.
Claro que o mirror possui sua vantagens e desvantagens, cujas quais são listadas abaixo:

Vantagens:
- Facil configuração e monitoramento.
- Base primaria e secundaria sincronizadas em tempo real.
- Não é necessario uma solução de hardware de discos externos (Storage).
- FailOver automatico com a utilização de uma instancia Witness.

Desvantagens:
- Necessario espaço em disco igual nos servidores envolvidos.
- Por ser sincrono, problemas de infra-estrutura em relação a rede podem atrapalhar a performance entre os servidores.
- FailOver de apenas uma base por mirror.
- Base secundaria fica em modo restoring não podendo nem ser acessada para consultas via SELECTs.

No SQL Server 2011 que ainda será lançado, existe uma nova solução atualmente chamada de High Avaiability Disaster Recovery AlwaysOn, ou simplismente HADRON, esta solução funciona como um mirror, porem possui algumas vantagens sobre seu concorrente.

Vantagens sobre o mirror comum:
- Escrita assincrona e com intervalo pequeno, ou seja, voce tera seus dados atualizados o mais rapido possivel em sua base secundaria, porem a performance de rede não ira impactar as ações na base primaria.
- FailOver automatico gerenciado pelo WSCS (Windows Server Cluster Service) para mais de uma base automaticamente.
- Como todo o FailOver é pelo WSCS, não é mais necessario uma instancia Witness para verificação do estado dos servidores envolvidos.
- Bases secundarias podem ser configuradas com 3 roles basicas de acesso:

1. Leitura -> Os usuarios podem se conectar porem apenas para leitura.
2. Leitura de conexão -> Não existe conexão direta na base, porem um select informando esta base, schema e tabela ira funcionar.
3. Sem leitura -> Mesmo estado do mirror comum.

Como conclusão final é possivel dizer que a solução HADRON não é realmente uma mudança extremamente impactante ou inovadora como foi o Mirror para o SQl Server 2005, mas possui conceitos e melhorias interessantes a serem considerados para sua implantação em alguns ambientes, principalmente pelo acesso de leitura na base secundaria.

Fonte: Nova classe de banco de dados emerge

Fonte: Banco de dados: processos distribuídos

Um relatório realizado pela Forbes Insight aponta quais os grandes equívocos das áreas de TI e de negócios em relação ao tema

Hoje, a maioria das organizações lida com o aumento e a pulverização dos dados. Na prática, isso gera uma necessidade sem precedentes de coletar e tratá-los de forma adequada para que se transformem em informações relevantes para as áreas de negócio.

De acordo com o Gartner, ao longo dos próximos cinco anos, deve haver um aumento de 650% no volume de Terabytes gerados pelos sistemas corporativos. Ao mesmo tempo, os usuários demandarão cada vez mais um acesso individualizado a informações analíticas. Mas como as organizações têm lidado com essas perspectivas?

Não muito bem, de acordo com o resultado de um recente levantamento realizado pela consultoria Forbes Insight – com o patrocínio da SAP – com 200 executivos das áreas de TI e negócios que atuam em grandes corporações. Acompanhe algumas das principais constatações do levantamento:

1.    Importância dos dados

O estudo confirmou a percepção de que os dados são extremamente relevantes para as empresas. 85% dos entrevistados concordam que suas organizações tratam as informações como uma questão estratégica. Além disso, quase todos (95%) analisam que a gestão das informações é fundamental para o sucesso do negócio.

2.    Consciência dos problemas

82% dos executivos consultados concordam que as informações ruins geram um custos desnecessários para o negócio. Mas quanto esse prejuízo representa?  A maioria dos respondentes estima que equívocos relacionados a dados custam mais de 5 milhões de dólares ao ano para sua companhia. Para 1/5 deles essas cifras anuais chegam a 20 milhões de dólares.

3.    Conflitos com as áreas de negócio

Grande parte dos executivos reconhece a importância de gerenciar bem os dados e as informações, bem como entende as consequências negativas de não fazer isso de forma adequada. Contudo, os problemas continuam a existir por problemas de comunicação, principalmente na hora de definir os requisitos para dar mais inteligência aos dados.

Como reflexo, entrevistados que eram da área de TI deram uma nota maior à qualidade dos dados corporativos do que os demais entrevistados que atuam nas áreas de negócio.

4.    Quem é o dono dos dados?

Os resultados da pesquisa mostram que a responsabilidade dividida pelos dados é a maior barreira para implementar um modelo bem-sucedido de gestão das informações corporativas. 79% dos gestores de TI consultados afirmaram que a qualidade dos dados está sob responsabilidade deles. Ao mesmo tempo, 74% dos profissionais das outras áreas (provenientes de marketing, finanças e vendas) disseram que faz parte do seu trabalho garantir a qualidade dos dados.

“Essas diferentes perspectivas colocam a TI e os executivos de negócio em conflito, particularmente em relação à qualidade dos dados”, aponta o relatório.

5.    A falha de conhecimento persiste

Outra constatação do estudo é que em conseqüência da falta de comunicação e das diferentes expectativas, alguns executivos acabam não utilizando de forma adequada os sistemas oferecidos hoje por suas empresas para gestão de dados.

De acordo com o relatório, 51% dos gestores de TI disseram que estão diretamente engajados em projetos para assegurar a qualidade da gestão dos dados. Essa porcentagem cai para 25% entre os demais executivos.

Como conclusão, o relatório destaca que se os profissionais das áreas de negócio não estiverem diretamente envolvidos com os projetos para garantir a qualidade da gestão dos dados, as iniciativas dificilmente terão sucesso.

Fonte: As cinco falhas que as empresas cometem na gestão de dados

Fique atento! O suporte ao SP2 do SQL Server 2005 encerrou no dia 12/01. O suporte a versão RTM do SQL Server 2008 vai encerrar em 13/04. Confira a tabela abaixo ou acesse o blog oficial da Microsoft  aqui.

Como se tornar um DBA

Vamos falar um pouco com quem esta querendo se tornar um DBA (Administrador de Banco de Dados) ou empresa que esta tentando contratar um. Existe uma carência grande de profissionais de TI no mercado e a tendência é aumentar ainda mais, entre os profissionais de TI, os DBA só podem estar em extinção, pois é difícil encontrar um que tenha experiência e esteja desempregado.

Para se tornar um DBA não é tão simples como as outras áreas de TI, se um DBA faz uma “besteira” podemos perder informações importantes dos bancos de dados da empresa e leva-lá a falência ou provocar prejuízos grandes e irreparáveis, com isso as empresas preferem contratar DBA que já tenham experiência, colocar um estagiário como DBA é o mesmo que colocar uma “arma de fogo” na mão dele.

Se você quer se tornar um DBA e não sabe por onde começar, as empresas procuram contratar obedecendo a seguinte ordem: Experiência no trabalho com o banco de dados utilizado na empresa, que tenha certificações e cursos oficiais, especialização na área de banco de dados e tenha curso superior.

Com exceção da “experiência”, você pode se qualificar para ser um DBA buscando fazer os cursos oficiais e tirando as certificações referentes a banco de dados, apos isso é só torcer para ser “adotado” por um DBA Sênior, uma vez trabalhando junto com o DBA da empresa você passa a ter experiência e a ser disputado no mercado de trabalho.

Não basta apenas querer ser DBA, você tem que se identificar com essa atividade, se você gosta de desenvolver sistemas ou de rede, não perca seu tempo, o nível técnico exigido dos DBA é alto, o seu tempo para estudar novas tecnologias será praticamente destinado a estudar sobre banco de dados e ferramentas de BI.

Na tabela abaixo esta dividida de forma simplificada a área de TI e a porcentagem do tempo de estudo em cada função.

Se você gosta de banco de dados, procure se qualificar é uma área promissora.

Neste Link tem um artigo legal em .pdf sobre como se tornar um DBA.

Sua empresa esta precisando de Consultoria de uma profissional DBA, entre em contato

Fonte: Como se tornar um DBA?

“As estruturas de gestão que proporcionam mais agilidade são aquelas em que o poder de tomar decisões está distribuído pela organização.” Esta é uma das constatações do 4º Technology Forecast, estudo anual realizado pela PricewaterhouseCoopers (PwC) com o propósito de antecipar algumas tendências de TI que podem ter impacto na forma de gerir o negócio. Nesta quarta edição, a PwC examinou os métodos e tecnologias emergentes que estão sendo desenvolvidos para tratar o significado e o contexto dos dados considerados críticos para gerir uma organização.

A pesquisa realizada pela consultoria aponta que o tema business intelligence (BI) liderou novamente a lista de prioridades dos CIOs neste ano, tanto que muitas empresas continuam a investir bastante em BI, mesmo com a economia em declínio. “Mas a maioria delas reconhece que a promessa do BI não foi cumprida até hoje. Ele ainda tem um viés muito departamental e uma das razões é que não é tão simples montar um BI”, observa Sérgio Lozinsky, consultor da PwC.

O problema, segundo ele, é que a maioria dos executivos não dispõe de um contexto adequado de dados quando estão avaliando uma questão específica para a tomada de decisão. Lozinsky observa ainda que o problema do BI não é nem com o software em si nem com a geração de relatórios, mas de como gerenciar e extrair os dados. De acordo com ele, uma das soluções para o problema de gestão dos dados é a tecnologia de web semântica, que nada mais é que uma web com toda sua informação organizada, de forma que tanto os computadores como as pessoas possam trabalhar em cooperação. Lozinsky diz que a web semântica possibilita entender o que os dados significam e acrescenta que aqueles que conseguem trabalhar o significado dos dados ampliam a capacidade de gerar relatórios, interpretá-los e compartilhá-los, seja internamente, para a tomada de decisões empresariais, seja com parceiros, seja com fornecedores e até mesmo com o público.

A PwC acredita que um banco de dados web proporcionará o desenvolvimento pleno dos documentos da web atuais, por meio do qual será possível encontrar e extrair partes de dados alocados em diferentes locais, agrupá-los sem a necessidade de um repositório de documentos e analisá-los de uma forma mais simples do que atualmente.

Lozinsky lista alguns tópicos que podem facilitar o caminho das empresas para compor um banco de dados na web. Entre eles, cita a necessidade de incluir os temas web semântica e linked data na agenda de BI; de estudar o assunto e desenvolver uma iniciativa piloto – formal ou informal; identificar os “domínios” de informação que interessam à empresa; verificar quais desses domínios já se encontram na web semântica; estabelecer padrões para definir univocamente os dados do negócio e as relações entre eles; avaliar o uso de MDM (Master Data Managment); e, por fim, repensar o uso de ferramentas como o Excel no contexto dos dados da empresa.

fonte: Web semântica pode transformar a forma de tomada de decisão nas empresas

O Matone teve um ganho de 37% no tempo da rotina de fechamento mensal, através do projeto de tuning do banco de dados SQLServer .

Especializada no desenvolvimento de sistemas e otimização de bancos de dados, a empresa identificou rotinas que consumiam mais tempo no fechamento mensal, a sugestão de melhorias na escrita dos códigos, a limpeza de dados nas tabelas, backups e testes, entre outras.

“Em alguns casos, quando o fechamento ocorria durante a semana, acabávamos entrando expediente adentro realizando o fechamento, chegando no limite do período para abertura do dia”, comenta Elton Peiter, gerente de Infraestrutura do Matone, que tem sede em Porto Alegre e está presente em 20 estados e no Distrito Federal.

Os principais resultados alcançados no projeto foram a redução do tempo de processamento na Rotina Mensal de Fechamento, de 12h para 7h30, o ganho de 60 GB de espaço em disco, a redução do tempo de extração de relatórios de acompanhamento, de 3h20; otimização do tempo de backup full, de 0h50 para 0h30.

Neste processo a etapa que obteve o maior ganho, em comparação com o mês anterior, foi a de “efetivação” que passou de 4h30 para 1h40 com uma redução de 61% no tempo de processo.

“Isto, para nós, é uma melhoria muito grande, pois estávamos em um ponto crítico do sistema de processamento e ganhamos uma folga importante”, continua Peiter.

fonte: Baguete

Mais informações