Gabe's questions

Tenho uma tabela de transações que contém compras e reembolsos. Eu gostaria de criar uma ligação entre compra e reembolso na mesma tabela (decidi não usar uma tabela separada). Não tenho certeza em qual direção a ligação deve ir. (Uma compra só pode ter um reembolso - isso é garantido)

• Opção 1 - O reembolso está vinculado à compra

• Opção 2 - A compra está vinculada ao Reembolso. (fácil ver se um trx tem reembolso e qual é)

Existe uma maneira padrão de modelar isso? Ou não importa, pois é basicamente a mesma junção?

SQL Server, mas aplicável a RDBMs

Este é o meu cenário:

• O usuário do Windows Gabe tem db_owneracesso ao banco de dados DB1.
• O usuário do Windows Gabe tem db_readerno banco de dados DB2.
• Quando o usuário executa UPDATE DB2.dbo.Tbl1 SET X = 1, ele obtém "A permissão UPDATE foi negada.." conforme o esperado.
• quando o usuário executa um proc DB1.dbo.uspUpdateTablecontendo a mesma UPDATEinstrução acima, ele é bem-sucedido.

Eu pensei que isso poderia ser devido ao encadeamento de banco de dados ou configurações confiáveis, mas eles não estão habilitados.

Este é o comportamento esperado para db_ownerprivilégio? E existe uma maneira de evitar isso?

SQL Server 2017

Encontramos esse erro estranho três vezes nos últimos dias, depois de estar livre de erros por 8 semanas, e estou perplexo.

Esta é a mensagem de erro:

Executing the query "EXEC dbo.MergeTransactions" failed with the following error:
"Cannot insert duplicate key row in object 'sales.Transactions' with unique index
'NCI_Transactions_ClientID_TransactionDate'.
The duplicate key value is (1001, 2018-12-14 19:16:29.00, 304050920).".

O índice que temos não é único. Se você notar, o valor da chave duplicada na mensagem de erro nem sequer se alinha com o índice. O estranho é que se eu reexecutar o proc, ele é bem-sucedido.

Este é o link mais recente que encontrei com meus problemas, mas não vejo uma solução.

https://www.sqlservercentral.com/forums/topic/error-cannot-insert-duplicate-key-row-in-a-non-unique-index

Algumas coisas sobre o meu cenário:

• O proc está atualizando o TransactionID (parte da chave primária) - acho que é isso que está causando o erro, mas não sei por quê? Nós estaremos removendo essa lógica.
• O rastreamento de alterações está ativado na tabela
• Fazendo a leitura da transação não confirmada

São 45 campos para cada tabela, listei principalmente os usados ​​nos índices. Estou atualizando o TransactionID (chave clusterizada) na instrução de atualização (desnecessariamente). Estranho que não tivemos nenhum problema por meses até a semana passada. E isso só está acontecendo esporadicamente via SSIS.

Mesa

USE [DB]
GO

/****** Object:  Table [sales].[Transactions]    Script Date: 5/29/2019 1:37:49 PM ******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[sales].[Transactions]') AND type in (N'U'))
BEGIN
CREATE TABLE [sales].[Transactions]
(
    [TransactionID] [bigint] NOT NULL,
    [ClientID] [int] NOT NULL,
    [TransactionDate] [datetime2](2) NOT NULL,
    /* snip*/
    [BusinessUserID] [varchar](150) NOT NULL,
    [BusinessTransactionID] [varchar](150) NOT NULL,
    [InsertDate] [datetime2](2) NOT NULL,
    [UpdateDate] [datetime2](2) NOT NULL,
 CONSTRAINT [PK_Transactions_TransactionID] PRIMARY KEY CLUSTERED 
(
    [TransactionID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, DATA_COMPRESSION=PAGE) ON [DB_Data]
) ON [DB_Data]
END
GO
USE [DB]

IF NOT EXISTS (SELECT * FROM sys.indexes WHERE object_id = OBJECT_ID(N'[sales].[Transactions]') AND name = N'NCI_Transactions_ClientID_TransactionDate')
begin
CREATE NONCLUSTERED INDEX [NCI_Transactions_ClientID_TransactionDate] ON [sales].[Transactions]
(
    [ClientID] ASC,
    [TransactionDate] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, DATA_COMPRESSION = PAGE) ON [DB_Data]
END

IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[sales].[DF_Transactions_Units]') AND type = 'D')
BEGIN
ALTER TABLE [sales].[Transactions] ADD  CONSTRAINT [DF_Transactions_Units]  DEFAULT ((0)) FOR [Units]
END
GO

IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[sales].[DF_Transactions_ISOCurrencyCode]') AND type = 'D')
BEGIN
ALTER TABLE [sales].[Transactions] ADD  CONSTRAINT [DF_Transactions_ISOCurrencyCode]  DEFAULT ('USD') FOR [ISOCurrencyCode]
END
GO

IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[sales].[DF_Transactions_InsertDate]') AND type = 'D')
BEGIN
ALTER TABLE [sales].[Transactions] ADD  CONSTRAINT [DF_Transactions_InsertDate]  DEFAULT (sysdatetime()) FOR [InsertDate]
END
GO

IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[sales].[DF_Transactions_UpdateDate]') AND type = 'D')
BEGIN
ALTER TABLE [sales].[Transactions] ADD  CONSTRAINT [DF_Transactions_UpdateDate]  DEFAULT (sysdatetime()) FOR [UpdateDate]
END
GO

mesa temporária

same columns as the mgdata. including the relevant fields. Also has a non-unique clustered index
(
    [BusinessTransactionID] [varchar](150) NULL,
    [BusinessUserID] [varchar](150) NULL,
    [PostalCode] [varchar](25) NULL,
    [TransactionDate] [datetime2](2) NULL,

    [Units] [int] NOT NULL,
    [StartDate] [datetime2](2) NULL,
    [EndDate] [datetime2](2) NULL,
    [TransactionID] [bigint] NULL,
    [ClientID] [int] NULL,

) 

CREATE CLUSTERED INDEX ##workingTransactionsMG_idx ON #workingTransactions (TransactionID)

It is populated in batches (500k rows at a time), something like this
IF OBJECT_ID(N'tempdb.dbo.#workingTransactions') IS NOT NULL DROP TABLE #workingTransactions;
select fields 
into #workingTransactions
from import.Transactions
where importrowid between two number ranges -- pseudocode

Chave primária

 CONSTRAINT [PK_Transactions_TransactionID] PRIMARY KEY CLUSTERED 
(
    [TransactionID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, DATA_COMPRESSION=PAGE) ON [Data]
) ON [Data]

Índice não agrupado

CREATE NONCLUSTERED INDEX [NCI_Transactions_ClientID_TransactionDate] ON [sales].[Transactions]
(
    [ClientID] ASC,
    [TransactionDate] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, DATA_COMPRESSION = PAGE)

declaração de atualização de exemplo

-- updates every field
update t 
set 
    t.transactionid = s.transactionid,
    t.[CityCode]=s.[CityCode],
      t.TransactionDate=s.[TransactionDate],
     t.[ClientID]=s.[ClientID],
                t.[PackageMonths] = s.[PackageMonths],
                t.UpdateDate = @UpdateDate
              FROM #workingTransactions s
              JOIN [DB].[sales].[Transactions] t 
              ON s.[TransactionID] = t.[TransactionID]
             WHERE CAST(HASHBYTES('SHA2_256 ',CONCAT( S.[BusinessTransactionID],'|',S.[BusinessUserID],'|', etc)
                <> CAST(HASHBYTES('SHA2_256 ',CONCAT( T.[BusinessTransactionID],'|',T.[BusinessUserID],'|', etc)

Minha pergunta é, o que está acontecendo sob o capô? E qual é a solução? Para referência, o link acima menciona isso:

Neste ponto, tenho algumas teorias:

• Bug relacionado à pressão de memória ou grande plano de atualização paralela, mas eu esperaria um tipo diferente de erro e até agora não consigo correlacionar os baixos recursos ao prazo desses erros isolados e esporádicos.
• Um bug na instrução UPDATE ou nos dados está causando uma violação duplicada real na chave primária, mas algum bug obscuro do SQL Server está resultando em uma mensagem de erro que cita o nome do índice incorreto.
• Leituras sujas resultantes do isolamento de leitura não confirmada, causando uma grande atualização paralela para inserção dupla. Mas os desenvolvedores de ETL afirmam que a leitura padrão confirmada é usada e é difícil determinar exatamente em qual nível de isolamento o processo é realmente usado em tempo de execução.

Suspeito que, se eu ajustar o plano de execução como uma solução alternativa, talvez a dica MAXDOP (1) ou usando o sinalizador de rastreamento de sessão para desabilitar a operação de spool, o erro simplesmente desaparecerá, mas não está claro como isso afetaria o desempenho

Versão

Microsoft SQL Server 2017 (RTM-CU13) (KB4466404) - 14.0.3048.4 (X64) 30 de novembro de 2018 12:57:58 Copyright (C) 2017 Microsoft Corporation Enterprise Edition (64 bits) no Windows Server 2016 Standard 10.0 (Build 14393) : )

Estou procurando uma função com valor de tabela embutida que decodifique caracteres codificados em URL (como %20 para espaço). referência

Eu vejo outras funções , mas não vi uma que seja uma função com valor de tabela embutida. Estou tentado a escrever um monte de instruções REPLACE em uma função, mas estou querendo saber se há uma maneira melhor.

CREATE FUNCTION dbo.itvfURLDecode
(
    @StringValue VARCHAR(MAX)
)
RETURNS TABLE

AS
RETURN ( 
    SELECT REPLACE(REPLACE(@StringValue,'%2B','+'),'%20',' ') /* etc..*/ AS DecodedValue
)

;WITH cteData AS 
(
    SELECT 'This%2Bis%20a%20test%3C%3E%20ok%3F%20100%25' AS example
)
SELECT 
    example, q.DecodedValue  /* returns: This+is a test<> ok? 100% */
FROM cteData c
CROSS APPLY dbo.itvfURLDecode(example) q

Gostaríamos de usar MD5 para nossa função de hash em vez de SHA_256, mas a partir do SQL Server 2016, o MD5 foi preterido. Estamos usando isso para hash (comparando quais registros foram alterados). Agora temos esse dilema de usar ou arriscar usando essa função ou incorrer em armazenamento e sobrecarga de desempenho usando SHA_256. É frustrante que a Microsoft tenha decidido descontinuar essas funções, embora ainda sejam úteis em determinados cenários.

Este projeto não é um componente crítico do negócio. Provavelmente usaremos SHA_256, mas essa é a escolha certa? O novo desenvolvimento deve sempre evitar funções obsoletas?

Por contexto - diariamente haverá cerca de 1-2 milhões de upserting em uma tabela de 400 milhões de linhas comparando hashbytes em tempo real. cerca de 30 colunas de largura

https://learn.microsoft.com/en-us/sql/t-sql/functions/hashbytes-transact-sql?view=sql-server-2017

Escolhendo o algoritmo certo na função HashBytes

Eu tenho uma visão que faz referência a uma tabela de fatos Cost com 300 milhões de registros. Essa visão também tem algumas junções. A tabela de fatos tem um índice clusterizado em Data e a definição da visualização é algo assim:

select * 
from FactCost f
INNER JOIN SomeOtherTable b on a.id = f.id
where f.Date < getdate()-7

Se eu consultar a exibição como abaixo, o otimizador primeiro processará o predicado na exibição e, em seguida, a data na minha consulta. Então, na verdade, ele lê 300 milhões de registros e retorna apenas 1 milhão. Não consigo descobrir que tipo de solução alternativa posso tentar otimizar isso.

SELECT
              *
    FROM [dbo].vwFactCost
    WHERE Date >= '2011-07-01'
        AND Date <= '2011-07-31'

Veja abaixo

EDITAR

:

Encontrei esse outro cenário em que a solução não era intuitiva.

tabela: FactRegistrationcom 300m registros, 30 colunas, RegDateé coluna de data

abaixo está a definição de visualização:

SELECT <columns>
FROM FactRegistration fr
WHERE FR.RegDate < CAST(DATEADD(DAY,-7,GETDATE()) AS DATE)

consulta:

SELECT <columns>
INTO #tmp
FROM edw.dbo.vwDemo_slow fr
WHERE fr.RegDate >= CAST('20140501' AS DATE)
    AND fr.RegDate <= CAST('20140531' AS DATE)

Resultados neste plano ( https://gist.github.com/gflores1023/f0f0089315841d21ab072837cf12145d ):

Se eu alterar a definição de exibição para usar esta cláusula WHERE:

WHERE FR.RegDate < CAST(CAST(DATEADD(DAY,-7,GETDATE()) AS DATE) AS DATETIME)

Eu recebo um plano muito melhor ( https://gist.github.com/gflores1023/e3904609c98babbbbc646eaec76ebba4 ):

Executando o SQL Server 2016 SP1

Existe uma maneira de ocultar a barra de status mais inferior? Ele não possui muitas informações úteis (número da linha, número da coluna, etc.) e ocupa uma quantidade razoável de espaço na tela. Não acho que seja escondível, mas pensei em perguntar.

Veja imagem abaixo

SSMS 17.6

O Plan Explorer mostra o Modo de Execução (estimado/real) no diagrama do plano ao passar o mouse sobre um operador? Não estou conseguindo encontrar. Eu o vejo na árvore de planos e no painel Operações principais.

Abaixo está o SSMS onde é mostrado vs Plan Explorer onde não é.

Atualmente, o banco de dados estendido no SQL Server 2016 move toda a tabela para o Azure. No entanto, este artigo do InfoQ menciona um modo de "linha de arquivo" para o banco de dados Stretch que permitirá filtrar quais linhas em uma tabela mover para a nuvem (ex. registros anteriores a 2010). Não consegui encontrar nenhuma documentação oficial da Microsoft sobre esse recurso não lançado.

Alguém pode me indicar uma fonte oficial que diz que isso está vindo para o RTM? Eu encontrei uma entrada de blog francês no MSDN mencionando isso, mas nada mais.

Eu tenho uma tabela de registros de 9 milhões com cerca de 452 MB de tamanho (desconsiderando os índices NC). Abaixo estão as estatísticas físicas e as colunas

Como um exemplo simples, se eu despejar a tabela em uma tabela temporária, o plano real mostra um tamanho de dados real e estimado de 42 GB . Veja a imagem abaixo.

Suspeito que isso se deva às duas colunas varchar(4000) que estão fazendo com que o tamanho estimado da linha seja maior do que são. No entanto, eu realmente não acho que 42 GB estão sendo transferidos - não tenho certeza de como isso seria possível. Não sei se estou vendo problemas de desempenho por causa disso, mas o plano de consulta parece assustador por causa dessas estimativas erradas. Por que o plano de consulta está tão errado nas varreduras de tabela estimadas e reais?

Para rastreamentos antigos, posso procurar em sys.traces ou no log do SQL Server para descobrir quando um rastreamento foi iniciado. Existe algo semelhante para Eventos Estendidos? Me deparei com esta entrada de blog sobre o uso de um gatilho DDL, mas estou me perguntando se há algo melhor.

SQLServer 2012-2014

Estamos debatendo se devemos usar a opção SORT_IN_TEMPDB para nossas tabelas DW. Meu entendimento é que há mais gravações ao usar essa opção, embora sejam mais sequenciais. Temos uma SAN (que tem sido notoriamente lenta às vezes), portanto, em nosso caso, queremos limitar o número de gravações o máximo possível. Acredito que o tempdb esteja em um LUN separado (conjunto de discos).

Temos bastante espaço em disco em nosso arquivo de dados e em nosso arquivo tempdb. Nesse caso, nos beneficiaríamos do uso de SORT_IN_TEMPDB?

Uma coisa que me impressionou foi este comentário sobre esta resposta

Ao reconstruir um índice, você precisaria do dobro do espaço do índice + 20% para a classificação. Portanto, em geral, para reconstruir todos os índices em seu banco de dados, você precisa apenas de 120% do seu maior índice em seu banco de dados. Se você usar SORT_IN_TEMPDB, você ganha apenas 20%, ainda precisa de 100% adicionais em seu arquivo de dados. Além disso, usar sort em tempdb aumenta drasticamente sua carga de E/S, pois em vez de gravar o índice uma vez no arquivo de dados, agora você o grava uma vez no tempdb e depois o grava no arquivo de dados. Então isso nem sempre é o ideal.

Definitivamente, não queremos aumentar nossa carga de E/S com nossa SAN lenta/possivelmente mal configurada.

Qual seria a melhor maneira de testar isso? Simplesmente reconstruindo a tabela com e sem a opção e logando os tempos?

Edit : Temos 8 arquivos tempdb, cada um com 15 GB. Temos os sinalizadores TF 1117/1118 definidos e o IFI está ativado. Atualmente fazemos uma mistura de reconstrução com a opção sort_in_tempdb e sem ela.

Obrigado!

SQL Server 2012 Corporativo

Eu tenho este XQuery para minha sessão de evento estendida que funciona bem, mas quando tento ingressar no plan_handle para dm_exec_query_plan para obter o plano de consulta, ele diz

Msg 257, Nível 16, Estado 3, Linha 1 A conversão implícita do tipo de dados varchar para varbinary não é permitida. Use a função CONVERT para executar esta consulta.

Se eu converter para varbinary, este é o erro que recebo.

"Msg 569, Nível 16, Estado 5, Linha 1 O identificador passado para dm_exec_query_plan era inválido."

Se eu passar manualmente o identificador para o DMF, ele funcionará bem. É assim que fica no formato varchar (depois de adicionar o 0x)

0x06000700f9971028f01033ae030000000100000000000000000000000000000000000000000000000000000000

SELECT
        q.Time
        ,q.[CPU (ms)]
        ,q.[Duration (s)]
        ,q.[SQL Statement]
        ,q.plan_handle
FROM (
SELECT
        data.value(     '(/event[@name="sql_statement_completed"]/@timestamp)[1]', 'DATETIME') AS [Time]
        ,data.value(        '(/event/data[@name=''cpu'']/value)[1]', 'INT') AS [CPU (ms)]
        ,CONVERT(float, data.value('(/event/data[@name="duration"]/value)[1]', 'BIGINT')) / 1000000
        AS [Duration (s)]
        ,data.value(
        '(/event/action[@name=''sql_text'']/value)[1]', 'VARCHAR(MAX)') AS [SQL Statement]
        --,data.value('(/event/action[@name=''plan_handle'']/value)[1]', 'varchar(4000)')       AS [PlanHandle]
        ,'0x' + CAST(data.value('(/event/action[@name="plan_handle"]/value)[1]', 'varchar(4000)') AS varchar(4000)) AS plan_handle
    FROM (
        SELECT
            CONVERT(xml, event_data) AS data
        FROM sys.fn_xe_file_target_read_file
        ('H:\SQLskills\EE_ExpensiveQueries*.xel', 'H:\SQLskills\EE_ExpensiveQueries*.xem', NULL, NULL)
    ) entries
    )q
    CROSS APPLY sys.dm_exec_query_plan(plan_handle)

Temos um banco de dados DW no modelo de recuperação simples. Todas as noites, carregamos dados de diferentes fontes e executamos alguns procedimentos. Eu gostaria de ver quanto o log de transações é realmente usado durante esse carregamento noturno que leva horas para ser executado.

Atualmente, o log aumentou para mais de 50 GB devido a uma consulta de limpeza única que executamos recentemente. O espaço usado no log está próximo de 0% devido ao Modelo de Recuperação Simples. Gostaríamos de reduzir o arquivo de log para um tamanho mais razoável. Suspeito que o carregamento noturno use apenas 5 GB, mas existe uma maneira de descobrir isso? Pensei em pesquisar o banco de dados a cada minuto ou cinco e capturar o espaço usado e não utilizado em uma tabela de registro por algumas noites. Existe uma maneira melhor?

Temos a atualização cumulativa nº 10 instalada no SQL Server 2012 SP1 que precisamos devido a uma correção específica para o DQS.

Como o SQL Server 2012 SP2 lançado recentemente contém apenas correções de CU1 a CU nº 9 , se decidirmos atualizar para o SP2, isso substituirá e removerá as correções de CU nº 10? E se sim, poderíamos reaplicar o CU#10 a ele? Ou teríamos que esperar até que outro CU fosse feito para o SQL Server 2012 SP2?

• http://support.microsoft.com/KB/2958429
• http://support.microsoft.com/kb/2954099

Eu tenho uma consulta como esta:

select dbo.fn_complexFunction(t.id)
from mytable t

No SQL Sentry Plan Explorer , notei que tenho que executar Get Estimated Plan para fazer o Query Plan incluir o UDF.

Ao executar 'Get Actual Plan', não parece que as leituras lógicas e outras métricas incluam as operações que ocorrem na UDF. Em casos como esse, a única solução alternativa é usar o Profiler?

Temos um servidor cliente contendo SQL Server 2008R2 com cerca de 50 bancos de dados. O problema é que o uso da CPU chega a 100% (ou próximo disso) e dura algumas horas. Isso geralmente acontece pela manhã (geralmente entre 6h e 9h). O uso médio da CPU é de 30%

Examinamos os relatórios agendados e não encontramos nada - decidimos agendá-los no início da manhã e isso não adiantou.

Amanhã estarei no remoto para investigar o problema. Reconstruímos os índices e isso não ajudou. Eu tenho um conjunto de DMVs para verificar as consultas com maior tempo de trabalho e maior tempo de execução.

O SQL Server rastreia todas as consultas executadas para que os Detran possam acessar as informações? Que outros trechos de código SQL seriam úteis para diagnosticar o problema?

editar: O uso de memória também é muito alto - cerca de 80-90%. Na verdade, outro servidor está enfrentando o mesmo problema ao mesmo tempo, acredito que ambos estejam hospedados em um servidor citrix.

Também fizemos uma reconstrução de índice.

Tenho usado a nova função de pesquisa no Reporting Services 2008 R2 ao usar diferentes servidores onde não tenho a opção de um servidor vinculado. No entanto, o DBA acabou de criar um link para esse servidor e gostaria de saber se posso obter melhor desempenho alterando minha consulta/relatório para usá-lo em vez da função de pesquisa.

Definitivamente, tenho muito mais flexibilidade na rota do servidor vinculado, mas não tenho certeza sobre o desempenho.

Estarei preenchendo uma tabela de milhas por galão (MPG). Está vindo de uma fonte de hodômetro.

Atualmente está configurado da seguinte forma:

  id               (primary_key)
, truck_num
, start_date
, end_date
, start_miles
, end_miles
, start_fuel
, end_fuel
, miles
, gals
, mpg

Parece haver alguma redundância. O milesé (end_miles - start_miles), idem para gals.

Devemos ter essas colunas pré-calculadas e armazenadas no banco de dados miles? galsIsso definitivamente tornaria a consulta mais fácil, mas à custa de espaço. Mesma pergunta para ter o mpgcalculado. Uma coluna computada tornaria as coisas mais lentas, não?

Quais índices funcionariam melhor? São cerca de 3.000 caminhões (registros) inseridos em um lote toda semana.

Estou usando o SQL Server 2008 R2.

Editar: uma consulta de amostra que eu usaria

-- find average mpg for since ytd
select m.truck_num, avg(mpg)
from mpg m
join truck t on t.truck_num = m.truck_num
where start_date >= @begin_of_year and end_date <= @today
group by truck_num