Houve uma época neste pais que a palavra já bastava como garantia. As pessoas tinham como regra serem conhecidas uma pelas outras e, assim sendo, era importante 'ser bem vista'.
Nesta época a gente brincava na rua que já era asfaltada com 4 chinelos para serem as traves e uma bola que muitas vezes era feita de meias velhas. E o futebol rolava até o sol se esconder. Se um carro passasse a gente reclamava...'usa a outra rua...paralela a esta...' e a interrupção no 'clássico' era de poucos segundos.
Hoje em dia eu mal consigo atravessar a mesma rua de tanto carro que tem. Deveriam colocar um semáforo para dar uma chance pro pedestre.
Sendo assim, com o crescimento da população foi ficando cada vez mais dificil de se lembrar de todos ou de
conhecer todos. Assim alguns clientes, contando com a sorte e a ocasião, davam um chapéu no português da
esquina pedindo algo fiado pois a situação era difícil, apertada. O português inicialmente confiava na
palavra da pessoa e, como eram poucas, ele se lembraria.
Mais tarde, mais pela desconfiança que pelo esquecimento, anotava numa 'caderneta' para depois cobrar da
pessoa. Fique certo que sempre existiram os espertinhos neste pais.
Com o tempo a 'cardeneta' tinha que ser trocada e algumas páginas estavam sujas ou o lápis borrado demais para entender o que foi escrito muitas das anotações eram perdidas.
Contudo eu ví um roolback incrivel numa empresa. A anotação nova quando era feita com um lápis bem levemente e, se necessário, era possível ler o que estava escrito anteriormente no campo e restaurar seu conteúdo original. Isso por volta de 1996.
Mas chegou uma época que surgiram os computadores e com isso essa nova ferramenta podia armazenar muita coisa como as vendas realizadas num dia, o fluxo de caixa, por exemplo.
A maioria das empresas pequenas começaram o controle de vendas com uma planilha ou algo bem simples, um registro da venda efetuada...data, produto, quantidade, valor total e mais alguma coisa.
Como o gerenciamento de uma empresa é sinônimo do controle da empresa que é sinônimo de saber o que a empresa está fazendo, começaram a expandir esse controle para possibilitar novas e mais rentáveis atividades na empresa, como expandir os negócios.
Agora seria útil cadastrar os clientes porque poderiam classificar entre ótimos, bons e mal clientes. Quem já não foi cliente preferencial de uma loja ?
O volume de informações armazenadas foi aumentando. Antes era só vendas, depois somou-se clientes. Agora temos o controle de estoque que está sendo feito numa planilha mas tem um erro grave : quando um produto sai do estoque para onde ele foi ? Vendido, roubado ?
No começo esses controles eram feitos em planilhas, bases de dados locais que causavam muitas vezes muita bagunça. Por exemplo, cada vendedor anotava numa planilha suas vendas. No final do mês passava ao coordenador que repassava as vendas para a empresa. A empresa batia vendas com as saídas de estoque e os dados não batiam, alguém esqueceu de anotar algo. O mesmo acontecia quando se batia estoque com vendas. Uma confusão, onde foi parar 10 peças x ?
Numa reunião cada um vinha com um dado diferente e era uma briga pra ver quem tinha razão. Isto acontecia porque cada um tinha sua visão dos dados feitas por controles não confiáveis.
Os bancos de dados publicam uma realidade que todos podem enxergar ao mesmo tempo. Se no seu controle o vendedor vendeu 100 peças e no servidor informa que tem 80 provavelmente esqueceu de registrar uma venda e os dados do servidor irão ajudar a rastrear o que foi lançado e o que não foi.
Se você trabalha com ferramentas como o office já deve ter deparado com suas limitações. A principal é que esta dentro de um arquivo dentro de uma máquina. Para resolver isso criamos o servidor de arquivos onde todo mundo colocar lá seu trabalho e se quiser, quando quiser, pode ir lá ver.
O segundo é o multi-usuário. Se uma pessoa esta alterando uma planilha, por exemplo, outro não pode alterar, vai ter que esperar o outro terminar, salvar aí poderá fazer o serviço. Isso é muito ruim porque um trabalha e todos demais são obrigados a aguardar.
Outra coisa péssima é que o banco de dados está salvo longe do mecanismo de banco de dados. Por exemplo, você está rodando o Excel ( então o mecanismo de banco de dados está na sua máquina ) e vai salvar no servidor corporativo de arquivos (outra máquina). Nesse interim pode ser que sua máquina trave, a máquina servidora de arquivos trave, que a rede caia, que alguém intercepte os pacotes de rede e os troque por outros fraudulentos, etc. Por isso todo banco de dados decente o serviço de banco de dados roda dentro da máquina onde o banco de dados está armazenado. É lógico que existe os discos de rede (SAS) mas o hardware é muito robuto e bem feito para suportar alta-confiabilidade. Mas se você nunca viu uma placa de um servidor SAS pifar você é um cara privilegiado porque um disco pifar o raid5 corrige mas uma placa controladora de disco pifar acaba provocando erros até na placa redundante.
Se numa empresa pequena a coisa era complicada para um empresa grande era impossível. Nessa época eles tinham alguns controles em servidores de grande porte que custavam uma fortuna, tanto para comprar como para manter. E assim girou o mundo por um bom tempo.
Uma revolução foi feita quando inventaram o banco de dados em servidores de grande porte. Nele podiamos armazenar todas as informações da empresa e, se fossem necessário, todos da empresa poderiam ter esses dados. É uma revolução porque imagine sem este controle como seria controlar uma equipe de vendedores cada um com seu número de vendas e isso determinava a comissão dos mesmos...uma briga.
Quando surgiram os computadores pessoais surgiu a oportunidade de melhorar os processos de gerenciamento de todas as empresas. Agora podemos colocar um computador na linha de produção para cadastrar um produto manufaturado e rastrear ele até a venda o que era feito, muitas vezes, ainda por computadores de grande porte.
Com a melhoria dos computadores pessoais foi possível transferir os bancos de dados do grande porte para a 'plataforma baixa' e com isto reduzir os custos de compra e manutenção das bases de dados a uma fração do que eram no grande porte.
Foi, literalmente, uma revolução. O SQL Server na plataforma baixa era incrível sobre todos aspectos. A performance era excelente, comparável com a do grande porte em tempo de resposta. A facilidade de implantação e gerenciamento das bases de dados foi outro fato determinante. Um sonho para a empresa e um pesadelo para os analistas.
Como você deve saber a Microsoft não fez o DOS 1.0, ela apenas comprou os direitos de comercialização do DOS da Ashton-Tate e adaptou para os processadores de 16 bits da IBM.
Se você não conheceu a Ashton-Tate é porque você conhece computação apenas pós Microsoft. Antes a Ashton-Tate fabricou seu próprio sistema operacional que rodavam em máquinas com o Z80 como os da Radio-Shack. Ou você acha que a Apple foi original ?
Para esse 'sistema operacional' havia um pacote tipo office que era composto pelas planilhas Visicalc (feito pela VisiCorp) e o famoso Lotus 123 (feito Lotus Company), o processador texto WordStar (feito pela MicroPro). Foram estas ferramentas que definiram o futuro do computador pessoal no mundo.
O mesmo foi com banco de dados. Ela não sabia fazer e resolveu se associar a quem sabia fazer. Inicialmente a empresa foi ...isso mesmo a Ashton-Tate novamente.
Contudo tenho a dizer que o primeiro curso que fiz do Oracle ( versão 8 ) foi feito num servidor windows NT. O windows era muito ruim mas muito mais barato que os seus concorrentes, na época.
| Versão | Descrição |
|---|---|
| MS SQL Server 1.0 |
Foi lançado em 1989 com a união de três empresas, Microsoft, Sysbase e Ashton-Tate. O produto foi baseado no SyBase SQL Server 3.0 para Unix e VMS (plataforma alta) |
| MS SQL Server 4.2.1 | Foi lançado em 1993 e era uma adapatação do produto para windows NT sendo que a Microsoft fez algumas alterações para adaptar a sua plataforma. |
| SQL Server 6.0 ou SQL95 | Foi lançado em 1995 e foi mais uma adpatação ao windows NT. Em 1996 foi lançado o MS SQL 6.5 (Hydra) que incluiu a primeira versão do Enterprise Manager e do SQL Server Agent. |
| SQL Server 7 ou Sphinx | Foi lançado em 1999 e foi a primeira versão do SQL Server totalmente feita pela Microsoft. Foi incorporado ao servidor o 'English Querie', Olap Services, a replicação, Database Desing e Query tools, Full Text Search, Data Transformation services. Só não teve grande repercussão porque 1 ano mais tarde a Microsoft lançaria o MS SQL Server 2000 agregando o XML ao banco de dados. |
| MS SQL Server 2000 ou Shiloh ou versão 8 |
Lançado em 2000 ainda era em 32 bits introduziu no SQL Server Enterprise o conceito de cluster,
OLAP, XML. Em 2003 lançou a versão 64 bits para o Intel Itanium e nesta versão incorporou o Report Services e o Data Mining Tools. O DTS ganhou poder e popularidade nesta plataforma. |
| MS SQL Server 2005 ou Yukon ou versão 9 | Novamente o mecanismo de banco de dados foi totalmente reescrito melhorando em muito sua performance. Foi adicionado ao banco de dados os serviços Service Broker, Notification Services, CLR, XQuery e XML e o SQLOS. O T-SQL ganhou o mecanismo de captura de erros try-cath. O sistema ganhou o System Tables que substituiram o Dinamic Management Views(DMV). O Management Studio foi substituído pelo Entreprise Manager e Query Analyzer. O DTS foi substituído pelo Integration Services. Foi o primeiro SQL a ser desenvolvido tanto nas plataformas de 32 como de 64 bits. |
| MS SQL Server 2008 ou Katmai ou versão 10 | Foi adicionado o Policy-Based Management, Data Compression, Resource Governor. O Notification services foi retirado. O TSQL finalmente ganha campos tipo DateTime e os tipos de dados ganharam o tipo table. |
| SQL Server 2008 R2 |
Foi a primeira versão do SQL Server feita apenas em 64 bits. Melhorias para virtualização de máquinas (Live Migration), em conjunto com Hyper-V o Live Migration possibilita migrar o serviço de uma máquina virtual para outra sem parar o serviço prestado facilitando a manutenção do serviço bem como a disponibilidade do serviço. Com ele os administradores puderam monitorar e gerenciar seus servidores seja qual for o hardware. |
| SQL Server 2012 |
Implementação dos Availability Groups que melhoram em muito os serviços de clustering failover e mesmo
em bancos de dados individuais (log shipping, replicação, espelhamento).
Novos recursos como o SQL Server AlwaysOn Availability Groups aumenta significativamente a
capacidade de Database Mirroring e ajuda a garantir a disponibilidade dos bancos de dados de
aplicativos. Possuem um conjunto integrado de opções, incluindo failover automático e manual
de um grupo de bancos de dados, suporte para até quatro secundários, failover rápido de
aplicativos e reparo automático de página. Outro recurso, o SQL Server AlwaysOn Failover Cluster Instances melhora o Clustering Failover do SQL Server, traz suporte nativo para configuração de cluster entre sites utilizando subnets e oferece um melhor controle sobre as condições para failover automático. Finalmente o recurso SQL Server AlwaysOn Secondaries habilita instâncias secundárias a serem utilizadas para a execução de relatórios e operações de backup. |
| SQL Server 2014 | Adição do recurso In-Memory no TSQL que permite criar tabelas diretamente na memória ganhando uma performance superior a 10 vezes a criação no disco. O recurso Alwys On que melhora a Alta disponibilidade foi melhorado e a recuperação de desastres e backup na Nuvem também, um failover mais rápido, uma maior capacidade de gerenciar e um melhor uso dos recursos de hardware com o AlwaysOn. Integração com o Windows Azure em nuvens hibridas, Azure HDInsight, serviço que permite o processamento de dados não estruturados na Nuvem e que agora suporta Hadoop 2.2. MS Intelligent System Service que traz a possibilidade de analisar dados provenientes de máquinas e sensores conectados à internet, conhecido popularmente como "internet das coisas". |
| SQL Server 2016 | 1. Query Store O query optimizer agora permite que o DBA ou Desenvolvedores identificar as consultas que estão gastando muito tempo para serem executadas. O PolyBase permite o acesso e combina dados relacionais e não relacionais no SQL Server, além de permitir execução de consultas em dados externos no Hadoop ou no blobs do Azure. Stretch Database é uma novidade voltada a nuvem híbrida que visa reduzir os custos de armazenamento e processamento. Trabalha com o conceito de mover ou migrar seus dados de forma segura e transparente para a nuvem do Azure. A vantagem deste processo é que você continua a ter acesso direto aos dados locais e remotos, mesmo durante a migração dos dados. Você pode ainda, no meio da migração, pausar em caso de problemas no servidor local ou para aumentar a banda de rede. Finalmente foi incorporado suporte a JSON no sql server. Agora podemos definir uma coluna de uma tabela como Always Encrypted que esconde seu conteúdo até mesmo para os dbas. Melhorias no In-Memory. |
| SQL Server 2017 | São muitas. É melhor você visitar : a Microsoft |
Primeiramente para ter certeza do melhor custo-beneficio a
máquina servidora tinha que ser certificada pela
Microsoft
. Eram os servidores da Dell, Digital Research e eram certificados o que garantiam melhor
desempenho e confiabilidade.
Hoje se você for procurar 'servidores certificados Microsoft' vai encontrar como instalar os certificados
em servidores microsoft ou como obter certificações e cursos da Microsoft.
Aí você pensa..aí sim...coisa boa...devia durar pra sempre. Ledo engano.
Um servidor UNIX com uma base de dados Oracle podia ficar trabalhando 8 anos seguidos sem ter qualquer
manutenção.
Uma máquina com o windows NT 4 e uma base de dados Microsoft SQL Server 6.5 num servidor da Digital Research
Risc de última geração e certificado pela Microsoft sendo
utilizado por menos de 50 pessoas não passava de um ano sem dar problemas tipo, tem que formatar do zero.
Falo isso de experiência própria num pool de servidores de 20 máquinas todas em rede local sem acesso
a Interent - na época.
Só pra dar uma idéia como era o pesadelo dos analistas se você tivesse que restaurar um backup e o banco de dados não tivessem o mesmo 'Service Pack' instalado dava erro na restauração.
Caso você não saiba Bill Gates durante muitos anos não acreditou que a Internet iria dar certo.
E quando a Internet começou a crescer 1000% ao ano e ele percebeu que estava ficando para traz ( como sempre) e começou a brigar por um espaço que já havia perdido. Como para ele (BILL) sempre o que importou foi a Microsoft e não os clientes tomou as piores decisões possíveis.
Uma das piores decisões que Microsoft fez na sua vida foi obrigar a usar o browser Internet Explorer para instalar atualizações em seus sitemas sendo que eles não tinham NENHUMA proteção contra os ataques da Internet.
Inicialmente para evitar ameças e melhorar a segurança os servidores ainda eram isolados na Internet. Ninguém estava autorizado a sentar e utilizar o servidor seja para qual fosse o fim, só os administradores tinham acesso a eles. Muitas vezes a gente instalava o servidor em salas especiais e as chaves ficavam com a segurança do prédio.
Ainda na fase inicial gente baixava as atualizações de sites oficiais da Microsoft em máquinas que não eram os servidores e faziamos testes com anti-virus, instalavamos em servidores de teste e só depois colocavamos em produção.
Inicialmente sem conhecimento suficiente pensamos inocentemente que o processo de baixar o software direto do site da Microsoft era seguro. Depois a gente descobriu que o processo não era nada seguro - Nem pense em HTTPS...na época ainda era ficção.
Com a politica da Microsoft de precisar instalar o Internet Explorer no servidor para baixar as atualizações diretamente no servidor foi desastroso em todos os aspectos, pior que briga de foice no escuro com tempestade de trovões. Um pesadelo...horas e horas perdidas tentando restaurar os servidores atacados.
Se você acha que desgraça pouca é besteira, acertou em cheio. A segunda geração de ataques foram as
malditas 'Macros do Office'. Que imbecilidade, deixar componentes tão poderosos sem proteção. Foi uma
desgracera geral, qualquer um que abrisse uma planilha do Excel no servidor poderia disparar um VBA que
simplesmente apagaria o disco do servidor (melhor dizendo, a tabela de partição do disco), simples assim.
No próximo boot do servidor, já Elvis.
Sempre foi politica da Microsoft colocar uma coisa no ar ( como o VBA do Office ) e depois correr atrás do
prejuizo que realizou para os clientes pois eles nunca pagaram o prejuizo causado.
Hoje a Microsoft está bem melhor, um pouco mais responsável mas não durma tranquilo não, ainda não
corrigiram todos os erros do DOS 1.0 quanto mais do Windows 10.
Sempre o sql server teve os seguintes objetivos:
1-Confiabilidade (Reability) : Quando ele armazena um dado fique certo que fez da maneira correta,
sem possibilidade de enganos. Este fato eu endosso porque mesmo quando o DBCC encontra erros na estrutura
física das tabelas ( erros de gravação ou defeito nos discos ) a gente consegue recuperar senão tudo, quase
tudo sem praticamente perder nada mesmo com a tabela corrompida.
Outro ponto importante é a disponibilidade do servidor - a informação deverá sempre estar disponível quando
o usuário precisar.
2-Integridade (Integrity) : Não é possível violar as regras estabelecidas. Por exemplo, você nunca vai encontrar um texto num campo que é numérico ou uma chave estrageira inválida (existe o filho, não existe o pai).
3-Segurança (Security) : A informação sempre deverá ser entregue na mão dos destinatários autorizados e unicamente a eles. Logins, senhas, criptografia garantes este quesito.
4-Performance : Não importa o tamanho do banco de dados, tabela, etc. a informação deverá estar disponível ao usuário no tempo tido como aceitável. Hoje este tempo é da ordem de 3 a 5 segundos mas alguns processos mais pesados podem ter esse tempo aumentado.
5-Tráfego de rede reduzido : É por este motivo que JSON, XML e outros formatos não são o padrão
de comunicação do SQL Server, pelo fato de agregar nome dos campos ou a estrutura aos dados trocados o que
aumenta, e muito, o tamanho da informação trocada.
Parece que não mas numa configuração Cliente-servidor o tráfego de rede é importante pois o SQL
server 'aguarda' o envio do resultado das informações antes de prosseguir numa nova pesquisa para o mesmo
destino.
Você pode achar que o SQL Server é apenas um banco de dados mas posso lhe garantir que o SQL Server como banco de dados é a estrelinha que você vê sobre um iceberg. O SQL Server como banco de dados não é 30% do SQL Server total.
1-O conversor de SQL para dentro do servidor SQL (Algebrizer) : Quando você digita uma pequisa SQL esta é convertida dentro do servidor sql para uma série de atividades que os componentes internos do SQL Server utilizarão para realizar a tarefa.
2-Otimizador de Querie (Querie Optimizer) : Este componente calcula qual é o melhor processo para alcançar o resultado desejado basedo no 'custo' para chegar a este resultado. Utilize o 'SQL Profiler' para visualizar melhor este recurso.
Importante : Se a tabela tem um índice com os campos A e B e na pesquisa você faz com Where B=x e A=y o índice será utilizado mas se utilizar um order by B,A o índice não poderá ser utilizado pois a ordenação estaria invertida.
3-Procesador de Pesquisas (Querie Engine ou Querie Processor): Executa a querie como o Query Optimizer definiu.
4-Mecanismo de armazenamento (Storage Engine) : É o mecanismo que busca ou armazena as informações no disco.
5-Buffer de armazenamento (The buffer Manager) : todos sabemos que para o processador processar a informação esta deve estar na memória. Os dados trazidos do disco são colocados na memória, mais precisamente, no buffer de dados que o buffer manager controla. Por exemplo, cabe ao buffer manager acionar o mecanismo de armazenamento para gravar a informação quando a atualização terminar ou chamar o 'garbage collector' do SQL quando os dados do buffer não forem mais necessários.
6-CheckPoint : Para possibilitar o acompanhamento do que está sendo feito o SQL Server tem o mecanismo Log que grava tudo o que o MS SQL Server está fazendo e, em conjunto coom o checkpoint, conseguem manter a integridade do banco de dados e possibilitar a recuperação de desastres.
Se lembra que citei logo acima que o SQL Server deve começar com um estado consistente e terminar com um estado consistente em sua base de dados ? Ou seja, se algo foi feito e encontrou um erro, o processo deverá ser revertido (lembre-se do princípio ATOM do ACID) e com isto não haverá dano ao banco de dados do servidor. Por exemplo, se você tenta inserir um dado em uma tabela filha que não tem o pai este quesito garante que isto nunca ocorra desapercebidamente.
O CheckPoint é o que possibilita esse retorno ao estado consistente sabendo o que foi feito e retornando o que foi feito.
7-Monitor de recursos (Resource Monitor) : Este monitor de recursos é muito útil para encontrar os gargalos nos processos. Por exemplo, o monitor de recursos do windows podem informar que seu disco esta completamente ocupado. O monitor de recursos do SQL pode te informar que foi dado um lock na tabela x porque um processo B tentou acessar os mesmos dados que o processo A está atualizando.
8-Gerenciador de travas (Lock Manager) : Lock Manager é o processo que diz que os dados estão sendo usados atualmente pelo processo A e o processo B deve aguardar porque eles estão sendo atualizados. Note que se o processo A esta atualizando os dados e o processo B esta lendo os dados não existe o lock de tabela mas se o processo B tentar atualizar os dados aí sim porque terá que aguardar o processo A terminar.
9 - SQLOS : O SQL Server consome muitos recursos do servidor porque tenta fazer esse serviço da melhor maneira possível.
Por esse motivo se você tiver um servidor IIS e um servidor de banco de dados no mesmo servidor fique certo que um serviço literalmente pára o outro porque rodam com a mesma prioridade que, no caso, são máxima e quem entrar primeiro ganha e o outro irá esperar.
O SQL OS são os recursos do sistema operacional feitos exclusivamente para que o servidor SQL funciona melhor. Isto envolve o acesso privilegiadoa recurso de memória, threads, requisições de IO feitas pelo próprio sistema operacional.
Se você comprou o SQL Server comprou também os seguintes componentes que ampliam, e muito, sua utilidade :
1-DataBase Engine : É o serviço de gerencimento de banco de dados do SQL em sí.
2-Analysis Services : São os serviços destinados a transformar a base de dados de OLTP para OLAP. Permitem obter as métricas para gereciar qualquer negócio da empresa que possa ser feito com as informações armazenadas no SQL Server.
3-Integrations Services ou ferramentas de integração : Permitem transferir informações de bases de dados heterogêneas como Oracle, Teradata, DB2, etc.
4-Reporting Services ou serviços de relatórios : Permitem criar relatórios gereciais sobre qualquer informação armazenada no SQL server num nível que dispensaria um Excel para a tarefa.
5-SQL Server Compact Edition : Este componente permite que você instale um servidor SQL em um servidor com poucos recursos de hardware como um celular.
Não importa por quem, qual ou aonde o banco de dados esteja ele deverá ter os seguintes objetivos:
1-Usabilidade : Neste quesito o banco de dados deve armazenar as informações que são necessárias ao negócio, nada mais, nada menos. Digamos que este quesito garante a efetividade da informação armazenada porque sabemos que ela é útil.
2-Extensibilidade : Neste quesito garantimos que podemos agregar mais informações sem que o sistema pare de funcionar. Garante que suporta variações na carga de informações como, por exemplo, tenho um mês de dados de vendas no servidor e ao agregar mais um mês tenho certeza que ele irá suportar sem problemas. Note que integridade, performance e disponibilidade podem ser afetados por este quesito.
3-Integridade de dados : Este quesito garante que os dados que lá foram depositados estejam confiáveis e integros, ou seja, se eu salvei no banco de dados que tenho 2 laranjas e fizer uma pesquisa de quantas laranjas eu tenho no banco de dados deverei receber a resposta 2 obrigatóriamente. Não pode ser nenhuma, uma, tres ou mais...só pode ser 2.
4-Performance : Este quesito garante que a resposta seja entregue em tempo hábil. Se eu faço uma pesquisa ela tem um 'prazo' para ser respondida, digamos 5 segundos no máximo. Se demorar 6 segundos é melhor pesquisar, otimizar a pesquisa criando um indice, coisa assism.
5-Escalabilidade : Este quesito garante que as coisas continuarão como estão mesmo que o tamanho do banco de dados seja aumentado. Por exemplo, quero saber as vendas do produto x no mês de Janeiro desse ano. O servidor demorou 5 segundos para responder. Ao acrescentar os meses de Fevereiro, Março, Abril, etc...e eu fizer uma pesquisa tanto no mês de Janeiro como em qualquer outro mês o tempo de resposta do servidor não deve ser substancialmente diferente da pesquisa inicial feita anteriormente no mês de Janeiro. A base de dados pode ter aumentado mas o banco de dados tem recursos para não deixar isso impactar tanto no tempo de resposta.
6-Disponibilidade : Um servidor de banco de dados parado muitas vezes podem significar que os negócios de uma empresa estão parados e isto, com certeza, é um prejuizo. Sendo assim quando mais disponível melhor. Tem empresas que Sábado e Domingo realizam poucos negócios ou de madrugada tem pouca coisa rolando e aproveitam esses dias para dar manutenção nos seus servidores. Nesta manutenção ele sai fora do ar alguns segundos e voltam logo a seguir.
Mas se for uma grande empresa jamais um servidor pode parar de funcionar. E para isso temos ferramentas e técnicas para aumentar o número de noves. O número de noves é quantos por cento o servidor fica fora do ar em um ano. A seguir exibo a tabela que contém esse cálculo :
| % tempo parado | tempo em segundos | tempo em horas | tempo em dias |
|---|---|---|---|
| 99 | 315.360 | 5.256 | 88 |
| 99,9 | 31.536 | 526 | 9 |
| 99,99 | 3.154 | 53 | 1 |
| 99,999 | 32 | 1 | 0 |
| 99,9999 | 3 | 0 | 0 |
Podemos dizer que qualquer empresa consegue obter 99% ou 99,9% mas é muito tempo para grande maioria delas.
Ficar um dia fora do ar já é muito, ou seja, seria bom que fosse melhor que 99,99%. Mas como lhe disse, tudo tem seu custo. Este período é o que a maioria das empresas que operam com baixa confiabilidade aceitam. Quando o banco de dados não é crítico aos negócios da empresa. Impactam mas não são críticos.
Já tive esse problema com servidores locais ( falhas em disco ) e em servidores na nuvem ( sem rede externa a empresa ). Como eu lhe disse, o importante é explicar as pessoas envolvidas o que está seguro e o que poderá ocasionar problemas para quando acontecerem todos saberem que foram informados.
A partir de 99,999% e 99,9999% a coisa já deve ser feita por um pool de servidores, raids, servidores especiais de datacenter. Aí o custo vai lá em cima mas isso é a empresa que determina.
7-Segurança : Tão importante quanto ter a informação correta é entregar ela nas mãos corretas. Segurança é fundamento de qualquer empresa. Você deve ter visto notícias que bases de dados do Facebook, Vivo entre outras estavam a venda na Internet para quem se interessasse. Isto normalmente ocorre porque as empresas terceirizam setores estratégicos da empresa e ao fazer isso precisam passar o acesso a empresas terceirizadas das informações estratégicas da empresa. Isso é pura burrice mas se sua empresa visa apenas o lucro, boa sorte, melhor dizendo, bom vexame...Mas capriche na cara de pau.
Não dá para comparar o SQL server das versões antigas com as novas. Uma simples melhoria faz muita diferença. Por exemplo, me lembro que quando saiu o SQL Server 2008 o fato de conseguir tirar um backup compactado economizou um espaço absurdo porque minhas bases de dados eram de Tera-Bytes e mesmo só sendo incremental era um inferno. Lembre-se que um backup sem compactação de dados fica praticamente do tamanho do banco de dados original.