crichavin's questions

Quero encontrar registros maiores que o tempo fornecido em meu predicado, que vem de um aplicativo Web C# no qual existe apenas type DateTime. No entanto, o SQL Server está retornando uma linha igual ao valor do predicado fornecido. Por que está fazendo isso? A ShipDateTimeUTCcoluna é um datetimetipo de dados.

DECLARE @p__linq__1 datetime2(7) = '2024-08-07 00:14:11.3630000';

SELECT 
    [OrderHeaderId],
    Id,
    [ShipDateTimeUTC]
FROM  
    [dbo].[ShippingContainerHeader]
WHERE 
    [ShipDateTimeUTC] > @p__linq__1;

Aqui estão os resultados onde você pode ver que ShipDateTimeUTC corresponde ao valor do predicado. Eu não quero que isso seja incluído. Por que está sendo incluído nos resultados?

Eu tenho uma Settingsmesa e uma Tenantmesa. Existe uma hierarquia para que um Accountpode ter 1 ou muitos Companiese um Companypode ter 1 ou muitos 'Instalações'.

Account 1
   ---> Company 1
          ---> Facility 1   
          ---> Facility 2
   ---> Company 2
          ---> Facility 3   
          ---> Facility 4

Eles podem ter uma configuração padrão que se aplica a toda a conta....

| FacilityId | CompanyId | AccountId | SettingValue |
|------------|-----------|-----------|--------------|
|     (null) |    (null) |         1 |            5 |

...exceto que eles têm uma substituição para a Instalação 3 que se aplica apenas à Instalação 3, todas as outras instalações usarão o valor de configuração padrão no nível da conta.

| FacilityId | CompanyId | AccountId | SettingValue |
|------------|-----------|-----------|--------------|
|          3 |    (null) |         1 |            6 |
   

Quero criar uma junção entre eles para obter a configuração mais específica para cada locatário. Mais específico é definido como o Settingregistro que corresponde ao Tenant's FacilityIdé mais específico do que uma correspondência em CompanyIdque é mais específica do que uma correspondência em AccountIde, finalmente, se nenhuma correspondência for encontrada, use a configuração que tem NULLpara todos os 3 valores.

Não quero usar o PIVOTrecurso, pois o código usa Entity Framework e LINQ e não há LINQ to SQL para PIVOT. Basicamente, precisa de SQL simples para o qual você possa criar uma visão ... para que não haja tabelas temporárias, etc. Não procurando uma solução de proc armazenada, se possível.

SQLFiddle

Mesa:Settings

| FacilityId | CompanyId | AccountId | SettingValue |
|------------|-----------|-----------|--------------|
|          1 |         1 |         1 |            5 |
|     (null) |         2 |         2 |            7 |
|     (null) |         1 |         1 |            4 |
|     (null) |    (null) |         2 |            6 |
|     (null) |    (null) |         1 |            3 |
|     (null) |    (null) |    (null) |            2 |

Mesa:Tenants

| FacilityId | CompanyId | AccountId |
|------------|-----------|-----------|
|          1 |         1 |         1 |
|          2 |         2 |         2 |
|          3 |         3 |         3 |

Então junte-se a eles teria esta saída desejada:

| FacilityId | CompanyId | AccountId | SettingValue |
|------------|-----------|-----------|--------------|
|          1 |         1 |         1 |            5 |
|          2 |         2 |         2 |            7 | --> this account would match to a setting value of 6 or 7, but the 7 value matches more specifically
|          3 |         3 |         3 |            2 | --> there is no match on Facility, Company, or Account so match to all nulls.

No código, estou fazendo o seguinte para obter o mais específico Settingpara um determinado Tenant, mas agora preciso fazer isso para um grande conjunto de Tenantdados e, portanto, quero fazê-lo por um SQL Join. Para aqueles que não estão familiarizados com LINQ, o double pipe( ||) é equivalente a OR.

private SettingViewModel GetSettingBy(string strKey)
{
    var allSettings = GetAllSettings();
    var settingQuery = allSettings.Where(x => x.SettingKey == strKey);

    if (_accountCompanyFacilityViewModel.AccountId.HasValue)
    {
        settingQuery = settingQuery.Where(x => (x.AccountId == _accountCompanyFacilityViewModel.AccountId || x.AccountId == null));
    }

    if (_accountCompanyFacilityViewModel.CompanyId.HasValue)
    {
        settingQuery = settingQuery.Where(x => (x.CompanyId == _accountCompanyFacilityViewModel.CompanyId || x.CompanyId == null));
    }

    if (_accountCompanyFacilityViewModel.FacilityId.HasValue)
    {
        settingQuery = settingQuery.Where(x => (x.FacilityId == _accountCompanyFacilityViewModel.FacilityId || x.FacilityId == null));
    }

    var setting = settingQuery
            .OrderByDescending(x => x.FacilityId)
            .ThenByDescending(x => x.CompanyId)
            .ThenByDescending(x => x.AccountId)
            .FirstOrDefault();
            
    return setting;
}

Aqui está o SQL Fiddle para a resposta

Estou tentando criar uma consulta para calcular a quantidade "Disponível para Venda" de todos os itens no inventário. Nesse caso, um item pode ter estoque atual disponível, mas também pode ser um kit, que é composto de matérias-primas que podem ser montadas para formar esse bem acabado. Portanto, a quantidade disponível para venda é a quantidade atual disponível de Bens Acabados (FG) mais o mínimo dos componentes que podem ser feitos no FG.

Exemplo:

Digamos que estamos vendendo um kit de laptop composto por um laptop e uma bolsa de transporte. Se tivermos 2 kits já feitos e 6 laptops e 3 bolsas de transporte, nossa disponibilidade para venda desses kits é de 2 + 3 = 5 no total. As bolsas de transporte são o fator limitante neste caso. Apesar de termos 6 laptops, só podemos fazer mais 3 kits por causa das malas que nos limitam.

Cheguei até aqui e os cálculos funcionam do nível 2 mais baixo até o nível 1, mas o nível 0 não está correto. Então, neste caso, o cálculo para o kit de laptop está correto (11 em mãos + podemos fazer mais 4 = 15 disponíveis para vender). Mas o kit de laptop e bolsa de nível superior não está correto. O menor Avail to Sell dos filhos diretos do nível superior (Laptop & Bag Kit) é 15 + 3 desse kit está disponível = 18, não 14.

Estou pensando que talvez precise adicionar um segundo CTE recursivo em vez da junção esquerda que tenho na seleção final?

SQL Fiddle

CREATE TABLE Item (
  Id INT,
  ParentId INT,
  DisplaySeq INT,  
  DisplayText VARCHAR(30),
  OnHandQty INT
  );

INSERT INTO Item (Id, ParentId, DisplaySeq, DisplayText, OnHandQty) VALUES
(9, NULL, 0, 'Laptop & Bag Kit', 3),
(8, 9, 5, 'Laptop Kit', 11),
(7, 8, 10, 'Laptop', 5),
(6, 8, 15, 'Power Supply', 4),
(26, 9, 20, 'Bag', 23)
;

;WITH items AS (
  SELECT 
    Id 
    , 0 as ParentId
    , Id as RootId
    , 0 AS Level
    , CAST(DisplaySeq AS VARCHAR(255)) AS Path
    , CAST('---' AS varchar(100)) AS LVL
    , CAST(DisplayText as VARCHAR(255)) as DisplayText
    , OnHandQty
  FROM Item 
  WHERE ParentId IS NULL

  UNION ALL

  SELECT 
    child.Id
    , child.ParentId
    , parent.RootId
    , Level + 1
    , CAST(parent.Path + '.' + CAST(child.DisplaySeq AS VARCHAR(255)) AS VARCHAR(255)) AS Path
    , CAST('---' + parent.LVL AS varchar(100)) AS LVL
    , CAST(parent.LVL + child.DisplayText as VARCHAR(255)) as DisplayText
    , child.OnHandQty
  FROM 
    Item child
      INNER JOIN items parent 
      ON parent.Id = child.ParentId
  )

SELECT 
  t.Path
  , t.RootId
  , t.Id
  , t.ParentId
  , t.Level
  , t.DisplayText
  , t.OnHandQty
  , COALESCE(s.MaxCanMake, t.OnHandQty) as MaxCanMake
  , t.OnHandQty + COALESCE(s.MaxCanMake, 0) as AvailToSell
FROM 
  items t
    left join (
        Select 
          ParentId,
          MIN(OnHandQty) as MaxCanMake
        FROM items
        GROUP BY ParentId
      ) as s
      ON t.Id = s.ParentId

ORDER BY t.Path

Eu entendo que há muitas variáveis ​​nisso e não estou procurando um número exato de min:seg :) Eu li muitos recursos que afirmam que a TRUNCATEusa muito menos recursos do que a DELETEe, portanto, terá um desempenho mais rápido. Mas não há ordem de grandezas mencionada. Como a TRUNCATEé uma operação DDL (Data Definition Language) e não uma operação DML (Data Manipulation Language) e apenas as tabelas do sistema fazem parte da transação, estou presumindo que não deve demorar muito.

Alguém com experiência em fazer isso com uma mesa próxima desse tamanho que possa dar alguma dica? Estamos falando até um minuto, até uma hora, dias, semanas?

Duas tabelas em nosso banco de dados SQL Server equivalem a 500 milhões de linhas e 350 GB de dados. O espaço em disco é um problema em que mantemos backups e o tempo para executar backups também. Planejamos truncar essas 2 tabelas.

Eu entendo que para recuperar o espaço em disco, precisaremos reduzir o banco de dados após o truncamento e, em seguida, fazer uma reconstrução de índice para corrigir índices fragmentados posteriormente. Mas como não temos certeza de quanto tempo as reconstruções levarão (estamos criando uma VM de servidor de teste no Azure agora para testar), enquanto isso estamos procurando ganhos incrementais. Depois de apenas truncar (antes de reduzir e reconstruir), os tempos de backup e o tamanho do arquivo de backup resultante (após a compactação 7z) serão reduzidos drasticamente como resultado?

Eu não sou um dba... vamos começar com isso :) Eu sou um desenvolvedor de aplicativos. Mas nosso banco de dados tem uma tabela de arquivamento com 252 milhões de linhas e 170 GB, e recebi a tarefa de corrigi-la (na verdade, existem várias tabelas nesta categoria que preciso limpar). Mas decidimos que não precisamos manter nenhum desses dados. Como essa tabela é uma tabela de arquivamento, quero dizer que há uma tabela de transações primária para esses dados, mas o aplicativo tem uma maneira de manter a tabela de transações menor arquivando ou movendo registros mais antigos para essa tabela de arquivamento.

Sendo uma tabela de arquivo, ela não possui dependências por SSMS (sem índices ou chaves estrangeiras). Este banco de dados está definido para o modo de recuperação completa.

Temos janelas de manutenção curtas, por isso precisamos de um processo rápido e temos espaço em disco limitado, por isso precisamos recuperar o espaço em disco dessa tabela.

Podemos truncar a tabela, mas como recuperar o espaço? Não queremos fazer uma redução de banco de dados, pois ela reduz todas as tabelas e, portanto, precisaríamos executar recompilações de índice... pelo menos esse é o meu entendimento, o que pode estar incorreto.

Eu poderia salvar um script do SSMS (Script Table as Create To...). Então largue a mesa e recrie-a... Isso é arriscado? Será que vai recuperar o espaço?

Outras ideias?

Não consigo entender por que essa junção não está funcionando para retornar o nome da tabela ao consultar o arquivo de log de transações.

SELECT [Transaction ID], 
    [Current LSN], 
    PartitionId, 
    sp.object_id,   
    so.[name], 
    [Operation],  
    [Context],
    [AllocUnitName],
    [Begin Time],
    [End Time],
    [Transaction SID],
    [Num Elements] ,
    [RowLog Contents 0],
    [RowLog Contents 1],
    [RowLog Contents 2],
    [RowLog Contents 3]
 FROM fn_dump_dblog(NULL,NULL,'DISK',1
    ,'D:\Users\Chad\SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Backup\OTIS_LogBackup_2016-02-02_13-36-21.bak'
    ,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL
    ,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL
    ,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL
    ,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL
    ,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL
    ,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL
    ,NULL,NULL,NULL,NULL) as logF
    LEFT OUTER JOIN sys.partitions sp ON sp.partition_id = logF.PartitionId 
    LEFT OUTER JOIN sys.objects so on so.object_id = sp.object_id
WHERE
    [Transaction ID] = '0000:00d15747';

E aqui estão os resultados. Você pode ver que o ID da partição está preenchido:

E quando executo esta consulta para obter o nome da tabela, ela funciona usando esse ID de partição encontrado nos resultados anteriores:

SELECT so.* 
FROM sys.objects so
INNER JOIN sys.partitions sp on so.object_id = sp.object_id
WHERE sp.partition_id = 72057594059489280

Então, por que ele não consegue encontrar o nome da tabela quando eu entro na instrução original acima?