none
URGENTE!! auto_increment Ficou Louco de 100 pulou para 1001 RRS feed

  • Pergunta

  • Bom dia

    Percebi de que uns dias pra ca meu Sql Server 2014 ficou doido o auto_increment, de 10 ele pulou para 1001 e de 1100 ele pulou para 2101 alguem sabe o que ta acontecendo? ja tentei colocar -t272 e nada adiantou, alguem tem alguma solucao pois necessito dele para dar codigos aos meus produtos..

    segunda-feira, 19 de outubro de 2015 09:55

Respostas

  • Dionathan,

    Bom, isso é by design... Vai continuar assim.

    A treceflag funciona, acabei de testar no meu SQL 2012 que eu tenho aqui. Porém, fazer um restart da instância não basta, você deve dar um stop e um start nela para fazer valer (não sei o porque disso).

    E você estava certo... fiz com o 't' minusculo e funciona.

    []'s!


    /* Logan Destefani Merazzi - DBA | @LoganMerazzi | http://www.merazzi.eti.br
    Se a resposta for útil, vote nela. Se resolveu, marque-a como resposta. */

    segunda-feira, 19 de outubro de 2015 12:24

Todas as Respostas

  • Bom dia,

    Dionathan, selecione o nome da tabela e pressione Alt+F1, ele vai listar as características da tabela, no 3º select vai estar as configurações de identity e auto incremento da tabela, olhe para confirmar se está correto...se não estiver, nos dois links a seguir tem a solução para resolver o problema. 

    veja:

    http://www.devmedia.com.br/trabalhando-com-campos-auto-incremento-identity-no-sql-server/17974

    http://stackoverflow.com/questions/1049210/adding-an-identity-to-an-existing-column

    depois se preferir, delete as linhas inseridas e para setar o identity para 10 novamente...execute o comando abaixo

    DBCC CHECKIDENT('Nome da Tabela', RESEED, 10)


    segunda-feira, 19 de outubro de 2015 10:33
  • Olá Diego, ja verifiquei e esta tudo normal mas ainda continua pulando.

    Percebi que ele pula depois do computador reiniciado, pesquisei em foruns e achei em um deles que o comando -t272 acabaria com o problema mas nao acabou ja nao sei mais o que fazer a sequencia do cliente baguncou demais, sera que tem alguma solucao para esse erro?

    segunda-feira, 19 de outubro de 2015 11:02
  • Dionathan Batista Donizetti, bom dia.

    Enfrentei este mesmo problema a uns tempos atrás, e minha solução foi deixar de utilizar o AutoIncrement do SQL Server e controlar pela minha aplicação.

    Isto ocorre exatamente após o reinicio do pc, e se da início a partir de uma queda de energia ou desligamento inesperado.

    Nos sites da MS ainda não há uma solução útil.

    Segue o método que utilizo:

    private int ProxNumero() { using (var db = new DB_Entities()) { var sql = 0;

    if (db.Vendas.Count() > 0) sql = db.Vendas.Max(m => (int)(m.Numero_Venda == null ? 0 : m.Numero_Venda)); return (sql == 0 ? 1 : sql + 1); } }

    Espero ter ajudado.


    segunda-feira, 19 de outubro de 2015 11:16
  • Bom Dia Renan,

    Ja que são muitos clientes deixar de utilizar o auto_increment será muito trabalhoso mas é uma solução a curto prazo a se pensar.

    segunda-feira, 19 de outubro de 2015 11:21
  • Dionathan,

    Isso começou a ocorrer a partir do SQL Server 2012. O SQL Server agora usa um cache de aproximadamente 1000 registros (pré-alocando eles). Se eles não são utilizados e o servidor é reiniciado, você acaba por perder eles. 

    Existe um connect item comentando sobre isso, mas foi fechado como "By design", ou seja, é assim e pronto, ehehe

    https://connect.microsoft.com/SQLServer/feedback/details/739013/failover-or-restart-results-in-reseed-of-identity

    O trace flag resolve, porém, se não estou enganado, o T deve ser em maiúsculo: -T272, faça um teste e nos retorne.

    Mas a minha pergunta principal é: Você realmente precisa controlar a sequência? Na minha opinião, isso não deveria ser levado em conta... É apenas uma chave... Até porque mesmo que você consiga contornar a situação agora, nada impede que futuros inserts quebrem a tua sequencia novamente (qualquer rollback vai te fazer perder o identity) e novos gaps passarão a existir.

    Se você quiser voltar a ocupar os gaps criados, você vai precisar quebrar as FKs e a pk, remover o identity, criar uma nova coluna como identity, atualizar todas as FKs e então recriar a PK e a FKs. Não vejo como deixar isso mais fácil, até porque se vc fizer um reseed, uma hora você vai chegar na PK já criada e vai te dar erro na inserção.

    Espero que te ajude.

    []'s!


    /* Logan Destefani Merazzi - DBA | @LoganMerazzi | http://www.merazzi.eti.br
    Se a resposta for útil, vote nela. Se resolveu, marque-a como resposta. */

    segunda-feira, 19 de outubro de 2015 11:29
  • Pessoal,

    Muito cuidado com esse tipo de solução...

    Se você tiver duas transações ao mesmo tempo tentando realizar um insert na mesma tabela, você terá um erro de inserção de registros com códigos duplicados.

    Você deve conhecer muito bem o seu ambiente e garantir que esse tipo de situação não ocorra.

    Nesse tipo de caso, recomenda-se o uso do nível de isolamento serializable, mas com isso você passa a ter outras situações, como a perda do uso de transações concorrentes, tendo que aguardar o término de uma transação para o início de outra.

    []'s!


    /* Logan Destefani Merazzi - DBA | @LoganMerazzi | http://www.merazzi.eti.br
    Se a resposta for útil, vote nela. Se resolveu, marque-a como resposta. */

    segunda-feira, 19 de outubro de 2015 11:40
  • Dionathan,

    Isso começou a ocorrer a partir do SQL Server 2012. O SQL Server agora usa um cache de aproximadamente 1000 registros (pré-alocando eles). Se eles não são utilizados e o servidor é reiniciado, você acaba por perder eles. 

    Existe um connect item comentando sobre isso, mas foi fechado como "By design", ou seja, é assim e pronto, ehehe

    https://connect.microsoft.com/SQLServer/feedback/details/739013/failover-or-restart-results-in-reseed-of-identity

    O trace flag resolve, porém, se não estou enganado, o T deve ser em maiúsculo: -T272, faça um teste e nos retorne.

    Mas a minha pergunta principal é: Você realmente precisa controlar a sequência? Na minha opinião, isso não deveria ser levado em conta... É apenas uma chave... Até porque mesmo que você consiga contornar a situação agora, nada impede que futuros inserts quebrem a tua sequencia novamente (qualquer rollback vai te fazer perder o identity) e novos gaps passarão a existir.

    Se você quiser voltar a ocupar os gaps criados, você vai precisar quebrar as FKs e a pk, remover o identity, criar uma nova coluna como identity, atualizar todas as FKs e então recriar a PK e a FKs. Não vejo como deixar isso mais fácil, até porque se vc fizer um reseed, uma hora você vai chegar na PK já criada e vai te dar erro na inserção.

    Espero que te ajude.

    []'s!


    /* Logan Destefani Merazzi - DBA | @LoganMerazzi | http://www.merazzi.eti.br
    Se a resposta for útil, vote nela. Se resolveu, marque-a como resposta. */

    Bom dia Logan,
    Pra mim essa sequencia não seria tao importante, porem estou tendo muita reclamação de clientes que são exigentes se é que me entende ficam incomodados com essa quebra de sequencia, no sql 2008 funcionava perfeitamente porem quando migramos começou essa quebra.

    Em relacao ao t272 ou T272 nenhum funcionou.

    Será que a microsoft não vai corrigir isto?

    será que tem alguma solução?

    ou vamos ter que voltar para o 2008?

    Estou perdido rsrs

    segunda-feira, 19 de outubro de 2015 11:53
  • Bom dia,

    Eu já tive esse problema, verifique as respostas que tive, no meu caso foi bem esclarecedor Como evitar que minha coluna IDENTITY quebre a sequencia de valores. Caso queira ler todo contexto Fórum.


    Atenciosamente, Ruberlei. www.t-sql.com.br


    • Editado Ruberlei segunda-feira, 19 de outubro de 2015 12:09 Melhoria
    segunda-feira, 19 de outubro de 2015 12:06
  • Olá Diego, ja verifiquei e esta tudo normal mas ainda continua pulando.

    Percebi que ele pula depois do computador reiniciado, pesquisei em foruns e achei em um deles que o comando -t272 acabaria com o problema mas nao acabou ja nao sei mais o que fazer a sequencia do cliente baguncou demais, sera que tem alguma solucao para esse erro?

    Dionathan,

    O "salto" no auto incremento da propriedade IDENTITY é uma configuração para evitar erros na inclusão de novos registros, principalmente em ações como o que ocorre com você (reiniciar o servidor ou o serviço da Instância SQL).

    A equipe de desenvolvimento do SQL Server respondeu uma questão sobre este "problema" através do Microsoft Connect: 
    "Este comportamento é, na verdade, desenhado para tentarmos garantir a unicidade da identificação ao invés de ter certeza que não temos lacunas. Como resultado, nós fazemos pular alguns valores apenas em determinados cenários de modo que não temos quaisquer problemas em torno de números repetidos acidentalmente."

    Procure verificar o porque da necessidade de reiniciar tantas vezes um servidor de Produção (isso não é normal) para assim evitar que algo semelhante ocorra novamente e, principalmente, que novos problemas possam aparecer.

    Você poderá ver este comentário no link deste chamado:

    https://connect.microsoft.com/SQLServer/feedback/details/743300/identity-column-jumps-by-seed-value

    Tenha certeza que você configurou corretamente o "trace" 272, porque ele funciona (eu já apliquei em algumas instâncias SQL, em versões diferentes). É importante saber que esta alteração somente entra em vigor após reiniciar o "serviço" da instãncia SQL e então às próximas ocorrências (reiniciando o servidor) não devem ter mais "saltos".

    Para maiores informações veja:

    http://social.technet.microsoft.com/wiki/pt-br/contents/articles/26286.como-evitar-que-minha-coluna-identity-quebre-a-sequencia-de-valores.aspx


    Se ajudou na sua solução, não esqueça de marcar como resposta !


    Abraços,

    Durval Ramos
    Microsoft Partner | MTA | MCSA - SQL Server 2012 | MCSE - Data Platform
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"



    segunda-feira, 19 de outubro de 2015 12:12
  • Dionathan,

    Bom, isso é by design... Vai continuar assim.

    A treceflag funciona, acabei de testar no meu SQL 2012 que eu tenho aqui. Porém, fazer um restart da instância não basta, você deve dar um stop e um start nela para fazer valer (não sei o porque disso).

    E você estava certo... fiz com o 't' minusculo e funciona.

    []'s!


    /* Logan Destefani Merazzi - DBA | @LoganMerazzi | http://www.merazzi.eti.br
    Se a resposta for útil, vote nela. Se resolveu, marque-a como resposta. */

    segunda-feira, 19 de outubro de 2015 12:24
  • Dionathan,

    Conseguiu resolver o problema? Colocando o trace flag, parando a instância e iniciando ela, fez o identity voltar 'ao normal'?

    []'s!


    /* Logan Destefani Merazzi - DBA | @LoganMerazzi | http://www.merazzi.eti.br
    Se a resposta for útil, vote nela. Se resolveu, marque-a como resposta. */

    terça-feira, 20 de outubro de 2015 12:25
  • Dionathan,

    Conseguiu resolver o problema? Colocando o trace flag, parando a instância e iniciando ela, fez o identity voltar 'ao normal'?

    []'s!


    /* Logan Destefani Merazzi - DBA | @LoganMerazzi | http://www.merazzi.eti.br
    Se a resposta for útil, vote nela. Se resolveu, marque-a como resposta. */

    Boa tarde Logan.

    Passei ontem e hoje de manha fazendo uns teste e varios de meus clientes, em alguns funcionou ja em outros não funcionou.

    terça-feira, 20 de outubro de 2015 18:31