Jonesome Reinstate Monica's questions

SQL Server 2016 e 2017, Edição Standard

Preciso inserir dados brutos (de outra tabela) em uma tabela que tenha duas uniqueidentifiercolunas.

Isso requer que eu use SET IDENTITY_INSERT Carrier ON?

Aqui está a tabela:

SET ANSI_NULLS ON

SET QUOTED_IDENTIFIER ON

CREATE TABLE [dbo].[Parkingspace](
    [ParkingspaceId] [uniqueidentifier] NOT NULL,
    [AccountId] [uniqueidentifier] NULL,
    [ParkingspaceType] [smallint] NULL,
 CONSTRAINT [PK_ParkingspaceId] PRIMARY KEY CLUSTERED 
(
    [ParkingspaceId] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, 
ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
) ON [PRIMARY]

O seguinte funcionará sem a IDENTITY_INSERTopção? (Acho que deveria, mas o DBA aqui é muito casado com a IDENTITY_INSERTopção.)

INSERT INTO Parkingspace 
  (ParkingspaceID,AcountID,ParkingspaceType)
  SELECT * FROM PRODDBCopy.Parkingspace

SQL Server 2016 Padrão

Nosso banco de dados tem 1TB de MDF, mas há 500GB de espaço livre nesse MDF.

Quando fazemos uma restauração em um secundário (destino de envio de logs), o MDF terá 1 TB ou ~ 500 GB?

Usando a opção Salvar resultados como, mostrada abaixo. CSV parece bom!

Mas quando o Excel abre/importa:

• Strings longas são desfiguradas como números (se os dados forem em grande parte numéricos)
• As datas não são detectadas corretamente
• Meus usuários brigam com tudo isso

Como obtenho uma consulta a um arquivo excel limpo (um xls/xlsx real) sem dançar? (Nós gostamos de tudo no próprio arquivo SQL... Eu gostaria que pudéssemos fazer "SELECT INTO FILE:C:\SQLOUTPUT\DATA.XLS ...")

SQL Server 2016 Standard Ed no Windows 2016

Temos uma máquina de 8 núcleos e 128 GB (uma VM, na verdade). Nós maximizamos isso para o nosso prod db. (122 GB para a instância, 8 núcleos para a instância)

Estamos configurando um 2º db, para estar em seu próprio conjunto de eixos (discos mais lentos), e não queremos que isso afete o prod db. Isso será na mesma VM (como entendemos, podemos usar a licença SQL existente dessa maneira).

Este 2º db deve ser servido por sua própria instância SQL para:

• Restringir a RAM consumida (para muito pouco, apenas 4 ou 8 GB)
• Restringir a 2 núcleos de CPU

Ou podemos restringir esse banco de dados dentro da instância principal?

(Observação, Express Edition não é uma opção, nosso db terá mais de 10 GB)

De acordo com os documentos do SQL Server , parece que se eu tiver uma ou mais colunas varchar/nvarchar que fazem com que o comprimento da linha exceda 8 KB, o SQL Server irá lidar com isso magicamente.

Cenário:
- A tabela tem 100 colunas -
O comprimento máximo da linha atual é de 3,4 KB
- Mas se cada campo varchar/nvarchar fosse preenchido no máximo, o comprimento da linha atingiria 14 KB

Da forma como interpreto os detalhes do Books Online vinculados acima, esse cenário funcionará bem (por exemplo, nada quebrará e tudo funcionará).

Minha suposição é verdadeira?

Entendemos ao conectar-se ao servidor SQL que especifica:

• <endereço IP>
• <host ou ip>,<número da porta>

Que o cliente ADO ou ODBC normalmente usará tcpip para se conectar.

No entanto, observamos que quando um cliente pede para se conectar a:

< server>\< nome da instância> que parece que o cliente (ODBC neste caso) NÃO usa tcpip.

Acreditamos em alguns casos, conectando-se a:

• <nome do host>

Também pode resultar em uma conexão de pipes nomeados.

Perguntas:

• Como < server>\< instance name> não está se conectando pelo tcpip, isso significa que está usando pipes nomeados, certo?
• Como faço para forçar a conexão a usar tcpip?

E o comportamento (do driver ODBC do Windows de 32 bits para SQL Server) nesse sentido é o mesmo que o comportamento do antigo cliente dblib?

Se eu tiver um certificado no SQL Server, usado para backups:

1. Os backups ainda podem ser criados após a expiração do certificado?
2. A restauração ainda pode acontecer após a expiração do certificado?

Qual é o sentido de expirar esses certificados? (além de me expor a falhas de backup devido a um certificado expirado ...)

Eu tenho um aplicativo, um aplicativo comercial, que armazena sua string de conexão em claro no registro.

Quando usei uma conexão confiável com o SQL Server, tudo bem (o ID do usuário e a senha estão no aplicativo IIS e são armazenados criptografados no IIS).

Agora devo mudar para a autenticação do SQL e me afastar de uma conexão confiável (longa história).

Eu sonho com uma string conn assim:

Server=myServerAddress;Database=myDataBase;User Id=myUsername;
Password=@#$@#@%#$%#$<encrypted password>@#$@#$;encryptedpassword=yes;

E uma maneira que eu possa criptografar o pw (usando a chave da máquina ou algo assim).

Existe um caminho nessa direção?

SQL Server 2014 e 2016, todos Standard Edition.

Estamos migrando para um novo SQL Server. Normalmente fazemos isso via envio de log (isso nos permite ter uma pequena janela de transição, porque só precisamos restaurar os logs finais, tirar o novo banco de dados da recuperação, modificar as strings de conexão e pronto ...)

Gostaríamos de migrar para SQL 2016 neste processo.

Poss para log ship de 2014 a 2016?

SQL Server 2014 Standard Edition

Preciso encontrar o número de voos de e para cidades específicas em determinados meses. Por exemplo

select count(*) 
from flights 
where flightTo_AirportCode = 'aaaa' 
and flightFrom_Airportcode = 'bbbb' 
and flightdate < '2016-04-01' 
and flightdate > '2016-02-28' ;

O esquema da tabela está abaixo.

Estou tentando estimar se o modelo de índiceA ou o modelo de índiceB (abaixo) é preferível (leva muitas horas para construir o índice e o espaço em disco permite que apenas um exista por vez, então estou tentando olhar antes de saltar).

Pela minha experiência, qualquer um dos índices serve. Estou certo?

  create index [modelA] on flights (flightTo_AirportCode, flightFrom_AirportCode, flightDate)

  create index [modelB] on flights (flightDate, flightTo_AirportCode, flightFrom_AirportCode)

(Ou, melhor, existe um índice binário ou mecanismo avançado que posso usar para abordar isso?)

CREATE TABLE [dbo].[flights](
    [flightId] [uniqueidentifier] NOT NULL,
    [accountId] [uniqueidentifier] NULL,
    [flightDate] [datetime] NULL,
    [flightTo_AirportCode] [nvarchar](30) NULL,
    [flightFrom_AirportCode] [nvarchar](30) NULL,
    -- ... 45 more fields
    CONSTRAINT [PK_flight] PRIMARY KEY CLUSTERED 
(
    [flightId] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 70) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

SQL Server 2014, Ed Padrão

Eu li que percent_complete em dm_exec_requests não funciona para CREATE INDEX e, na prática, percent_complete fica em 0. Então isso não ajuda.

Atualmente uso o método abaixo, que pelo menos me mostra movimento (que a criação do índice não está bloqueada). Mas não faço ideia se estou %10 no processo ou %99.

Eu tentei o método descrito aqui: https://dba.stackexchange.com/a/102545/6229 , mas ele mostra um tempo de conclusão claramente errado (basicamente mostra 'agora' para um processo de mais de 60 minutos em que estou 10 minutos )

Como posso obter uma pista?

SELECT percent_complete, estimated_completion_time, reads, writes, logical_reads, text_size, *
FROM
sys.dm_exec_requests AS r
WHERE
r.session_id <> @@SPID
AND r.session_id = 58

SQL Server 2014, Standard Edition (executando em vmware, fwiw). Adicionando uma caixa Dell MD3420 DAS.

Na velha escola, você configuraria conjuntos de eixos discretos para MDF, LDF, TEMPDB, BACKUP.

Por exemplo

• MDF: Quantidade 6: 300 GB-15 K, RAID 10 // 900 GB de armazenamento
• LDF: Qtd. 4: 150 GB-15 K, RAID 10 // pegada de dados menor, eixos para aumentar IOPS
• TEMPDB: Qtd 4: 150 GB-15 K, RAID 10 // pegada de dados menor, eixos para aumentar IOPS
• BACKUP: Quantidade 2: 2TB, RAID 1

Caso de uso: Este sistema possui 5 bancos de dados e é OLTP.

Hoje em dia, estou sendo informado: Basta configurar unidades Qty 10: 600GB-15K e colocar MDF, LDF, TEMPDB e BACKUP, tudo lá. O desempenho geral mais alto do maior conjunto de eixos mais do que compensa a conexão de gravação em LDF e BACKUP simultaneamente durante os backups.

• a) Esse novo caminho é o caminho certo?
• b) O LDF deve ser discreto em relação ao MDF... Acho engraçado!
• c) Eu realmente sinto que os backups devem ser seu próprio conjunto de fusos (por vários motivos)

O vencedor é ? Tradição SQL? Ou o arquiteto de armazenamento da Dell?

SQL Server 2014, edição padrão

Vimos e usamos, ao longo dos anos, uma variedade de sprocs e ferramentas não MS para exportar o esquema de banco de dados.

A maneira como realmente gostamos de fazer isso é o utilitário integrado, no SSMS, conforme descrito aqui no SO: https://stackoverflow.com/a/12036513/147637

Preferimos fortemente a ferramenta MS, porque é mais completa do que as ferramentas enroladas à mão e fornece uma saída super limpa, organizada e estruturada.

No entanto, queremos automatizar isso.

Como o mecanismo MS pode ser acionado programaticamente?

SQL Server 2014 Standard Edition.

Temos um trabalho que dura de 20 a 40 min. Queremos apenas uma instância desse trabalho em execução, mas não queremos grandes intervalos entre as execuções.

Portanto, agendá-lo a cada 60 minutos não é o ideal, porque pode haver 30 a 40 minutos mortos. Idealmente, agendaríamos a cada 30 minutos, porque isso nos daria o ideal de correr a cada 10 minutos ou correr de costas.

Em uma tarefa agendada do sistema operacional Windows, há configurações para controlar como lidar com a instanciação do trabalho quando o trabalho ainda está em execução.

Como obtenho algum controle no SQL Server? Como chego ao meu ideal (ou próximo dele)?

SQL Server 2014 Standard Edition

Temos uma tabela com mais de 100 milhões de linhas.

Precisamos atualizar os valores em algumas colunas.

Fizemos o abaixo, e ele está em execução há 18 horas e fez apenas 17 milhões de linhas. Está ficando cada vez mais lento.

É um servidor razoavelmente quente e sistema de disco (EMC RAID10 e tudo isso). O CREATE INDEX levou cerca de 20 minutos (uma interrupção infeliz que tivemos que tolerar).

Que abordagem podemos usar para passar por isso mais rápido? (on-line fortemente preferido)

CREATE NONCLUSTERED INDEX RECORD_DELETED_INDEX ON [dbo].[huge-table] ( [deleted] ASC, [deletedDate] ASC );
GO


DECLARE @CHUNK_SIZE int
SET @CHUNK_SIZE = 4000  -- to stay under lock escalation threshhold

UPDATE TOP(@CHUNK_SIZE) [huge-table] set deleted = 0, deletedDate = '2000-01-01'
where deleted is null or deletedDate is null

WHILE @@ROWCOUNT > 0
BEGIN
    UPDATE TOP(@CHUNK_SIZE) [huge-table] set deleted = 0, deletedDate = '2000-01-01'
    where deleted is null or deletedDate is null
END

SQL Server 2014 Standard Edition

Na minha situação, tenho uma tabela enorme (mais de 100 milhões de linhas) e preciso:

• adicionar coluna a ele
• definir valor padrão nessa coluna

Vejo em https://technet.microsoft.com/en-us/library/ms190273(v=sql.110).aspx que há uma nova opção lock_escalation.

Isso me permite, por exemplo, fazer o seguinte sem um bloqueio de tabela:

por exemplo

ALTER TABLE Protocols set (LOCK_ESCALATION = DISABLE);
go

ALTER TABLE Protocols
ADD ProtocolTypeID int NOT NULL DEFAULT(1)
GO

No entanto, as preocupações são:

a) LOCK_ESCALATION = DISABLE -- para que serve exatamente, aplica-se aqui? (Os documentos do SQL Server são um pouco finos... talvez se aplique apenas a tabelas particionadas?)

b) LOCK_ESCALATION = DISABLE afeta o tamanho da transação? (Parece que ainda criará uma grande transação?)

c) LOCK_ESCALATION = DISABLE será aplicado e evitará um bloqueio de tabela?

d) Existe uma maneira de cortá-lo? (Não consigo imaginar, mas há tanta mágica nova nas versões mais recentes do SQL... devo perguntar!)

SQLServer 2014:

Temos uma tabela muito grande (100 milhões de linhas) e precisamos atualizar alguns campos nela.

Para envio de logs, etc., também, obviamente, queremos mantê-lo em transações pequenas.

Se deixarmos o seguinte executar um pouco e, em seguida, cancelar/encerrar a consulta, todo o trabalho feito até agora será confirmado ou precisamos adicionar instruções BEGIN TRANSACTION / END TRANSACTION explícitas para que possamos cancelar a qualquer momento?

DECLARE @CHUNK_SIZE int
SET @CHUNK_SIZE = 10000

UPDATE TOP(@CHUNK_SIZE) [huge-table] set deleted = 0, deletedDate = '2000-01-01'
where deleted is null or deletedDate is null

WHILE @@ROWCOUNT > 0
BEGIN
    UPDATE TOP(@CHUNK_SIZE) [huge-table] set deleted = 0, deletedDate = '2000-01-01'
    where deleted is null or deletedDate is null
END

Temos uma tabela muito grande (100 milhões de linhas) e precisamos atualizar alguns campos nela.

Para envio de logs, etc., também, obviamente, queremos mantê-lo em transações pequenas.

• O abaixo fará o truque?
• E como podemos fazer com que imprima alguma saída, para que possamos ver o progresso? (tentamos adicionar uma instrução PRINT lá, mas nada foi exibido durante o loop while)

O código é:

DECLARE @CHUNK_SIZE int
SET @CHUNK_SIZE = 10000

UPDATE TOP(@CHUNK_SIZE) [huge-table] set deleted = 0, deletedDate = '2000-01-01'
where deleted is null or deletedDate is null

WHILE @@ROWCOUNT > 0
BEGIN
    UPDATE TOP(@CHUNK_SIZE) [huge-table] set deleted = 0, deletedDate = '2000-01-01'
    where deleted is null or deletedDate is null
END

Temos um trabalho do SQL Agent executando algum PowerShell, que cria uma saída bastante longa (tem saída robocopy, entre outras coisas).

No SQL Agent Job History, vemos apenas os primeiros 1.000 caracteres desta saída.

1. Existe outro lugar onde podemos olhar que terá toda a saída?
2. Existe outra abordagem que deve ser usada para ver a saída completa?

Espero ver a fila de disco se mover nos volumes de dados, tempdb, log e backup.

Não espero ver a unidade do sistema operacional (C :) que não possui nenhum arquivo SQL presente, mostre o impacto da fila do disco.

Suponha que seja para o arquivo de paginação do sistema operacional ou ?

Sugestões sobre como perseguir?

Este é SQL 2014 em Win2012-R2/