none
Instalação do SQL SERVER 2005 - Algumas dúvidas RRS feed

  • Pergunta

  • Prezados,
    Boa tarde a todos ! Estou precisando instalar o SQL SERVER 2005 (minha versão é a Enterprise) no servidor da empresa e, em alguns pontos, estou em dúvida e gostaria, se possível, esclarecê-las junto a este Fórum.
    Seguem abaixo os pontos/dúvidas para esclerecimento :

    1) Em relação à "divisão" do SQL 2005 nos discos, qual seria a recomendação ideal, a fim de ganharmos performance em relação a paralelismo ? Andei lendo que uma boa prática seria possuir um disco para o Sistema Operacional (Windows), outro para guardar os arquivos de paginação e a própria instalação do SQL (coexistiriam no mesmo disco), um disco para os dados dos bancos (arquivos .MDF) e outro para os logs dos bancos (arquivos .LDF). Isso estaria correto ? Que boa prática vocês recomendariam ?

    2) Em relação aos Service Packs a serem executados após a instalação do SQL 2005, seria o SP3 e mais o último "Build" para o SP3. Soube que o SP3 apresentava um problema, pois não possuía os "Cumulative Update's" 10 e 11, que o SP2 possuía. Nesse caso, aplicando o SP3 e depois o último "Build", este último "build" já teria as correções pertinentes a ele e mais todas as correções anteriores acumuladas ? Em qual link poderia baixar o SP3 e mais este último "Build" ?

    3) Em relação ao uso da memória, seria recomendável utilizar o recurso de AWE para o SQL SERVER fazer uma maior alocação de memória, nos casos de servidores de 32 bits com memória acima de 4 GB, alterando o "Boot.ini", incluindo o /3GB e o /PAE ? Isso porque, caso se mantenha o "default", o Windows utilizaria 2 GB e o SQL 2005 utilizaria 2 GB, correto ? Uma vez utilizado esse recurso, o Windows não ficaria prejudicando, visto que ao invés de 2 GB ficaria com apenas 1 GB de memória para trabalhar ? Qual o parecer e a experiência de vocês ?

    4) Em relação às contas para "startar" os serviços do SQL SERVER e do SQL SERVER AGENT, pelo que li na Internet e manuais, creio que o melhor seja criar uma conta de domínio, com poucos privilégios, para "startar" o serviço do SQL SERVER (uma vez que este serviço não requer privilégio de administração) e uma outra conta de domínio para "startar" o SQL SERVER AGENT, apenas com permissão "logon as a service". Ou seja, nenhuma conta dessas teria privilégio de administrador do servidor. Isso seria correto ?

    Peço perdão pelo texto grande, mas procurei deixar bem claro quais são minhas dúvidas em relação aos pontos abordados.

    Fico no aguardo de qualquer retorno que possa me ajudar a prosseguir com este trabalho.

    Agradeço antecipadamente a todos. Muito obrigado,

    José Luiz

    • Movido Gustavo Maia Aguiar sexta-feira, 3 de setembro de 2010 20:02 (De:Programação avançada com o SQL Server)
    quinta-feira, 2 de setembro de 2010 18:25

Todas as Respostas

  • José,

    Realmente o texto é um pouco grande, mas sem problemas, vamos por partes.

    Em relação a primeira dúvida:

    1) Em relação à "divisão" do SQL 2005 nos discos, qual seria a recomendação ideal, a fim de ganharmos performance em relação a paralelismo ? Andei lendo que uma boa prática seria possuir um disco para o Sistema Operacional (Windows), outro para guardar os arquivos de paginação e a própria instalação do SQL (coexistiriam no mesmo disco), um disco para os dados dos bancos (arquivos .MDF) e outro para os logs dos bancos (arquivos .LDF). Isso estaria correto ? Que boa prática vocês recomendariam ?

    --Esta afirmação é verdadeira, é recomendável, fazer esta separação, deixando os arquivos do SQL Server instalados no disco do sistema, mas os arquivos dos seus respectivos bancos de dados .mdf armazenados em um disco e os arquivos de log .ldf armazenados em outro, além disso, o banco TEMPDB também poderá ser armazenado em uma unidade de disco diferente dos demais por se tratar de um banco de trabalha com processos temporários.

    2) Em relação aos Service Packs a serem executados após a instalação do SQL 2005, seria o SP3 e mais o último "Build" para o SP3. Soube que o SP3 apresentava um problema, pois não possuía os "Cumulative Update's" 10 e 11, que o SP2 possuía. Nesse caso, aplicando o SP3 e depois o último "Build", este último "build" já teria as correções pertinentes a ele e mais todas as correções anteriores acumuladas ? Em qual link poderia baixar o SP3 e mais este último "Build" ?

    --Existem algumas considerações a fazer, o importante é instalar e aplicar o mais recente dos services packs e seus respectivos cumulative packs ou hot fixs. No meu blog você poderá encontrar o link para estes downloads, mas todos podem ser baixados diretamente no website da Microsoft.

    3) Em relação ao uso da memória, seria recomendável utilizar o recurso de AWE para o SQL SERVER fazer uma maior alocação de memória, nos casos de servidores de 32 bits com memória acima de 4 GB, alterando o "Boot.ini", incluindo o /3GB e o /PAE ?

    --Se você esta trabalhando com ambientes 32 bits não é necessário incluir o /PAE.

    Isso porque, caso se mantenha o "default", o Windows utilizaria 2 GB e o SQL 2005 utilizaria 2 GB, correto ?

    --Você deverá levar em consideração qual a edição do Windows Server você estará utilizando.

    Uma vez utilizado esse recurso, o Windows não ficaria prejudicando, visto que ao invés de 2 GB ficaria com apenas 1 GB de memória para trabalhar ? Qual o parecer e a experiência de vocês ?

    --Isso é complicado de afirmar pois vai depender dos recursos que este Windows Server irá trabalhar, mas 1GB de memória é muito pouco para o Sistema Operacional, no mínimo 1.5 GBs.


    4) Em relação às contas para "startar" os serviços do SQL SERVER e do SQL SERVER AGENT, pelo que li na Internet e manuais, creio que o melhor seja criar uma conta de domínio, com poucos privilégios, para "startar" o serviço do SQL SERVER (uma vez que este serviço não requer privilégio de administração) e uma outra conta de domínio para "startar" o SQL SERVER AGENT, apenas com permissão "logon as a service". Ou seja, nenhuma conta dessas teria privilégio de administrador do servidor. Isso seria correto ?

    --Isso mesmo, o melhor é criar uma conta de usuário no domínio com poderes restritos e permissões necessárias para rodar o serviço. Eu normalmente tenho o hábito de criar uma conta denominada SQLServices e definir esta conta para trabalhar com estes serviços. Por questões de boas práticas e segurança não é recomendável utilizar a conta Administrador.

     


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário]
    quinta-feira, 2 de setembro de 2010 18:56
    Moderador
  • Prezado Júnior,
    Primeiramente, muito obrigado pela pronta resposta, mas permita-me perguntar mais alguma coisa, em cima das respostas que você me deu :

    1) Pela sua resposta, percebo que o sistema operacional (Windows) e o SQL 2005 podem coexistir no mesmo disco, para efeito de performance, não precisando separá-los em discos diferentes, certo ? E os arquivos de paginação do Windows podem ser configurados para este mesmo disco ?
    Quanto ao banco TEMPDB, normalmente já é instalado, por default, no caminho da instalação do SQL, e isto por si só já o separaria dos demais. Ainda assim é necessário isolá-lo em um disco só pra ele ?

    2) Bem, creio que o mais recente dos services packs seja o SP3 (arquivo "SQLServer2005SP3-KB955706-x86-ENU.exe") e, pelo que vi no link "http://support.microsoft.com/kb/960598/en-us", o último "cumulative Update" é o "Build 9.00.4309", que data de 16/08/2010, correto ?

    3) Em relação ao meu ambiente, temos o Windows Server 2003 Enterprise Edition, com Service Pack 2, com 8 GB de RAM,  e totalmente dedicado ao SQL SERVER 2005. Nesse caso, gostaria que o SQL trabalhasse com mais de 2 GB de memória, mas sem prejudicar os processos normais do Windows. Posso habilitar o AWE e incluir o /3GB no Boot.ini para isso ? E o Windows como ficaria ?

    4) NO meu caso aqui, criei duas contas de domínio, uma para "startar' o SQL SERVER e outra para "startar" o SQL SERVER AGENT. Para a conta do SQL SERVER está padrão e para a do SQL SERVER AGENT está apenas com a permissão Windows de "log on as a service" (conforme vi no Books online). Seriam mesmo somente estas permissões, para numa configuração padrão, o SQL 2005 "startar" sem problemas ?

    Mais uma vez obrigado pela atenção e colaboração.

    José Luiz

     

    quinta-feira, 2 de setembro de 2010 21:48
  • José,

    Obrigado, vamos lá:

    1) Pela sua resposta, percebo que o sistema operacional (Windows) e o SQL 2005 podem coexistir no mesmo disco, para efeito de performance, não precisando separá-los em discos diferentes, certo ?

    --Sim.

    E os arquivos de paginação do Windows podem ser configurados para este mesmo disco ?

    --Sim.


    Quanto ao banco TEMPDB, normalmente já é instalado, por default, no caminho da instalação do SQL, e isto por si só já o separaria dos demais. Ainda assim é necessário isolá-lo em um disco só pra ele ?

    --Realmente é instalado no mesmo local e caminho dos demais, mas se o seu volume de transações ou objetos temporários for relativamente alto, é recomendável instalar em outro disco.

    2) Bem, creio que o mais recente dos services packs seja o SP3 (arquivo "SQLServer2005SP3-KB955706-x86-ENU.exe") e, pelo que vi no link "http://support.microsoft.com/kb/960598/en-us", o último "cumulative Update" é o "Build 9.00.4309", que data de 16/08/2010, correto ?

    --Sim isso mesmo, instale o SP3 e depois todos os cumulative packs, vou recomendar este link para você obter mais informações sobre estes updates: http://www.sqlsecurity.com/FAQs/SQLServerVersionDatabase/tabid/63/Default.aspx

    3) Em relação ao meu ambiente, temos o Windows Server 2003 Enterprise Edition, com Service Pack 2, com 8 GB de RAM,  e totalmente dedicado ao SQL SERVER 2005. Nesse caso, gostaria que o SQL trabalhasse com mais de 2 GB de memória, mas sem prejudicar os processos normais do Windows. Posso habilitar o AWE e incluir o /3GB no Boot.ini para isso ?

    --Sim isso mesmo, vai definir para que seu Windows recomeça e aloca mais de 3GBs de memória RAM, neste caso, o quanto de memória você configurar para o SQL Server, o restante será consumido para o Windows.

    E o Windows como ficaria ?

    --O próprio Windows vai reconhecer o quanto de memória esta configurado para que ele possa trabalhar.


    4) NO meu caso aqui, criei duas contas de domínio, uma para "startar' o SQL SERVER e outra para "startar" o SQL SERVER AGENT. Para a conta do SQL SERVER está padrão e para a do SQL SERVER AGENT está apenas com a permissão Windows de "log on as a service" (conforme vi no Books online). Seriam mesmo somente estas permissões, para numa configuração padrão, o SQL 2005 "startar" sem problemas ?

    --Esta são o mínimo necessária, as recomendações apresentadas no Books On-Line são suficiente para o funcionamento normal sem qualquer tipo de problemas.
     


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário]
    domingo, 5 de setembro de 2010 02:01
    Moderador
  • Prezado Júnior,
    Mais uma vez, muito obrigado pela sua atenção e colaboração. Então, resumindo, para não ser cansativo e não abusar da sua boa vontade :

    1) Entao OK. Na minha instalação do SQL SERVER 2005, o Sistema Operacional (Windows), os arquivos de paginação e o SQL propriamente dito, coexistirão no mesmo disco (disco de sistema).
    Quanto ao banco TEMPDB não tenho como mensurar agora se necessitará residir em outro disco. Precisarei analisar isso, de alguma forma, para poder definir essa questão.

     

    2) Acessei o link que você me informou e foi de grande valia. Pude perceber que neste link não existem alguns "builds" que existem no link que eu havia citado anteriormente (http://support.microsoft.com/kb/960598/en-us). No link informado por você o último "build" é o 9.00.4285 e no link que informei acima é o 9.00.4309 (mais recente).

    Só fiquei com uma dúvida em relação a sua afirmação que é preciso instalar o SP3 e depois "TODOS" os Cumulative Packs. Os Cumulatives Updates não acumulam nele as correções necessárias e mais todas as anteriores contidas nos Cumulative Updates anteriores ? Se isso for verdade, basta instalar o SP3 mais o último Cumulative Update (no caso o Cumulative Update 11 - build 9.00.4309), correto ?

     

    3) Então para habilitar o recurso AWE é necessário o uso conjunto de /3GB no Boot.ini ou não ? Ou precisa apenas habilitar o AWE e depois setar o "min server memory" e o "max server memory", restartando em seguida o SQL ?

    Um exemplo prático, tomando por base a minha realidade :

    Windows Entreprise Edition SP 2 com 8 GB de RAM :

    Para habilitar o SQL para usar 5 GB de memória, deixando o restante (3 GB) para o Windows, eu habilitaria da seguinte forma (sem colocar /3GB no Boot.ini)  :

    sp_configure 'show advanced options', 1
    RECONFIGURE
    GO
    sp_configure 'awe enabled', 1
    RECONFIGURE
    GO
    sp_configure 'min server memory', 1024
    RECONFIGURE
    GO
    sp_configure 'max server memory', 5120
    RECONFIGURE
    GO

    Isso estaria correto ?

     

    4) OK, deixarei as contas para startar os serviços SQL com o mínimo de permissões (conforme orientado) pelo Books Online, a menos que alguma permissão especial se faça necessário.

     

    Desde já, agradeço antecipadamente e peço perdão pelo extenso debate.

    José Luiz

    segunda-feira, 6 de setembro de 2010 01:14
  • Olá,

    Segue complemento:

    1) Entao OK. Na minha instalação do SQL SERVER 2005, o Sistema Operacional (Windows), os arquivos de paginação e o SQL propriamente dito, coexistirão no mesmo disco (disco de sistema).
    Quanto ao banco TEMPDB não tenho como mensurar agora se necessitará residir em outro disco. Precisarei analisar isso, de alguma forma, para poder definir essa questão.

    Q) Existe um artigo bem interessante para te ajudar em relação sobre onde armazenar os arquivos do SQL http://technet.microsoft.com/en-us/library/cc966534.aspx

    2) Acessei o link que você me informou e foi de grande valia. Pude perceber que neste link não existem alguns "builds" que existem no link que eu havia citado anteriormente (http://support.microsoft.com/kb/960598/en-us). No link informado por você o último "build" é o 9.00.4285 e no link que informei acima é o 9.00.4309 (mais recente).

    Só fiquei com uma dúvida em relação a sua afirmação que é preciso instalar o SP3 e depois "TODOS" os Cumulative Packs. Os Cumulatives Updates não acumulam nele as correções necessárias e mais todas as anteriores contidas nos Cumulative Updates anteriores ? Se isso for verdade, basta instalar o SP3 mais o último Cumulative Update (no caso o Cumulative Update 11 - build 9.00.4309), correto ?

    Q) Sim você está correto como o nome já diz são cumulativos :) Recomendo que você atualize seu ambiente diretamente para o SP4 CU1 http://support.microsoft.com/kb/2464079

    3) Então para habilitar o recurso AWE é necessário o uso conjunto de /3GB no Boot.ini ou não ? Ou precisa apenas habilitar o AWE e depois setar o "min server memory" e o "max server memory", restartando em seguida o SQL ?

    Um exemplo prático, tomando por base a minha realidade :

    Windows Entreprise Edition SP 2 com 8 GB de RAM :

    Para habilitar o SQL para usar 5 GB de memória, deixando o restante (3 GB) para o Windows, eu habilitaria da seguinte forma (sem colocar /3GB no Boot.ini)  :

    sp_configure 'show advanced options', 1
    RECONFIGURE
    GO
    sp_configure 'awe enabled', 1
    RECONFIGURE
    GO
    sp_configure 'min server memory', 1024
    RECONFIGURE
    GO
    sp_configure 'max server memory', 5120
    RECONFIGURE
    GO

    Isso estaria correto ?

    Q) Não é necessário habilitar /3GB para utilizar AWE e os T-SQL que você mencionou acima estão corretos. Existe uma limitação na arquitetura 32bits que o mesmo não reconheçe mais que 4GB de RAM e para que seu OS utilize este recurso é necessário utilizar PAE veja maiores informações abaixo:

    PAE and /3GB and AWE oh my...
    http://blogs.msdn.com/chadboyd/archive/2007/03/24/pae-and-3gb-and-awe-oh-my.aspx
    By default, the 32bit OS can only 'see' and use up to 4gb of memory, as it uses a 32bit range to map physical memory space (with a valid range of 0x00000000 up to 0xFFFFFFFF, or 0 thru 4,294,967,295 in decimal format, which correlates to a maximum high range pointer of 4GB  (divide 4294967296 slots (don't forget the 0 slot counts) by 1073741824 (the # of bytes per GB)).  Yes, this means  that on a default 32bit system no matter how much physical memory you install on the system, the system would only  ever use at most 4gb of it
     
    A processes' VAS in 32bit windows is 4GB  in size, and a VAS in 32bit Windows is typically divided into 2 primary sections: 1 section that is available to the process, and 1 section reserved for the system/kernel.  In Windows, this range of memory is split up into the 2 following ranges by default:
          Low 2GB Range (0x00000000 through 0x7FFFFFFF) - available to the user-mode process
          High 2GB Range (0x80000000 through 0xFFFFFFFF) - reserved for the kernel/system
     
    ...
    the PAE switch has NO effect whatsoever on the VAS size in a 32bit system - it remains at 4GB in total, and the sizes of the 2 portions of the VAS remain exactly the same also (2GB each by default...)
    ....
    AWE is simply a mechanism to access/map memory from outside a processes' VAS into it's VAS and vice versa - it is not a type of memory, it is not an extension of memory, and it doesn't change any memory structures
    ....
    they provide an interface by which a process can reserve memory outside it's VAS for storage, however to actually 'touch' the data stored in these memory locations, the process has to map that data into it's VAS to read it.


    Effects of min and max server memory
    http://msdn.microsoft.com/en-us/library/ms180797(SQL.90).aspx
    "The buffer pool does not free any of the acquired memory until it reaches the amount specified in min server memory. Once min server memory is reached, the buffer pool then uses the standard algorithm to acquire and free memory as needed. The only difference is that the buffer pool never drops its memory allocation below the level specified in min server memory, and never acquires more memory than the level specified in max server memory."


    4) OK, deixarei as contas para startar os serviços SQL com o mínimo de permissões (conforme orientado) pelo Books Online, a menos que alguma permissão especial se faça necessário.

    Q) Segue o script Books online (BOL) is your best friend forever =) --> somente em casos muito específico é necessário alterar as permissões recomendadas pelos artigos descritos no BOL

     

    Ufa!!! Acho que é isso

    qualquer duvida nos procure!


    Fábio Oliveira Support Engieer | Microsoft Enterprise and Developer Support
    quarta-feira, 9 de fevereiro de 2011 20:20