Eu tenho um grande banco de dados com várias publicações de replicação transacional. Cada publicação tem 15-20 artigos. Algumas assinaturas são push, portanto, cada vez que um novo artigo é adicionado à publicação, um novo instantâneo grande deve ser criado. Para evitar isso, estou pensando em criar uma única publicação por artigo (não adicionando o artigo a um já existente), reduzindo assim a necessidade de um grande snapshot. Eu estou querendo saber se esta abordagem tem algum downsize.
Estou criando um script para recriar um banco de dados para fins de teste, e o banco de dados possui algumas publicações. Para criar ou não o agente logreader preciso saber se o banco de dados atual já possui um, ou destruir o agente existente antes de recriar o banco de dados. Sei que existe alguma classe no SMO que pode fazer isso, mas preciso conseguir o mesmo com o T-SQL. Alguém pode ajudar?
Estou trabalhando no seguinte cenário: Estou criando um script que recria um banco de dados inteiro. O script envolve a destruição e recriação do banco de dados e todos os seus objetos, bem como um grande número de inserções de servidores vinculados. A ideia é poder recriar o banco de dados à vontade até que a fase de desenvolvimento termine. Meu problema é que o script gera alta atividade de log, e logo ocorre um CHECKPOINT. Estou eliminando todas as conexões em meu script antes de descartar o banco de dados, mas como CHECKPOINT é um processo do sistema, não consigo eliminá-lo e meu script falha. Não preciso de recuperação para este banco de dados nesta fase, minha dúvida é se posso desabilitar os logs para este banco de dados para evitar o CHECKPOINT.
Tenho o seguinte cenário: um banco de dados no SQL Server 2012 que deve replicar as alterações de forma transacional para um banco de dados SQL Server 2000. Como os esquemas de dois bancos de dados diferem, uma transformação deve ser feita para o destino. Ambos os bancos de dados estão na mesma rede. Qual é a melhor abordagem?
- Use gatilhos no banco de dados de origem para fazer as transformações e realizar as alterações no destino.
Use a replicação transacional do SQL Server (mas as transformações parecem impossíveis, como eu sei).
Alguma alternativa?
Dada a seguinte estrutura
Existe uma maneira de impor que Table1.id3 só pode ser definido como valores em Table4.id3 onde Table4.id2 = Table1.id2? Inicialmente pensei em uma restrição CHECK, mas subconsultas não são permitidas.
Dada uma tabela com apenas uma coluna IDENTITY, como você insere uma nova linha? Eu tentei o seguinte:
INSERT INTO TABLE
(Syntax error)
INSERT INTO TABLE VALUES()
(Syntax error)
INSERT INTO TABLE (Id) VALUES()
(Syntax error)
Estou testando algo e só preciso da coluna IDENTITY. Não é para produção. Caso contrário, tal tabela pode ser usada como um gerador de sequência, onde nenhuma outra coluna é necessária.
Eu tenho uma relação entre duas tabelas. A tabela de chave estrangeira pode ter uma linha relacionada na tabela primária. Existe uma maneira de impor o valor da coluna FK para ser NULL ou um dos valores da coluna PK na tabela primária?
Tenho uma tabela com muitos atributos que podem ser agrupados em grupos lógicos, e assim a ideia de colocar esses atributos em tabelas separadas me parece atraente. Os grupos lógicos não representam as próprias entidades. Quando um atributo no grupo é definido, a maioria dos demais atributos desse grupo também deve ser definida (mas não todos). O tipo dos campos dos grupos geralmente são VARCHAR(15-20). Não há BLOBou TEXTcampos também.
Os grupos lógicos não representam subtipos, pois não são mutuamente exclusivos.
A entidade é solicitada mais para leitura do que para escrita. Portanto, uma mesa grande parece apropriada. Além disso, desta forma as junções são evitadas nas consultas. A parte dessa abordagem que eu não gosto é o grande número de campos anuláveis.
Procurando conselhos de especialistas.