Connaissez-vous un moyen simple de générer un enregistrement pour chaque heure des 12 dernières heures?

J'ai un rapport qui montre le nombre d'événements pour les 12 dernières heures, regroupés par heure. Cela semble assez facile, mais ce avec quoi je me bats, c'est comment inclure des enregistrements qui comblent les lacunes.

Voici un exemple de tableau:

Event
(
  EventTime datetime,
  EventType int
)

Les données ressemblent à ceci:

  '2012-03-08 08:00:04', 1
  '2012-03-08 09:10:00', 2
  '2012-03-08 09:11:04', 2
  '2012-03-08 09:10:09', 1
  '2012-03-08 10:00:17', 4
  '2012-03-08 11:00:04', 1

Je dois créer un jeu de résultats qui a un enregistrement pour chaque heure des 12 dernières heures, qu'il y ait ou non des événements pendant cette heure.

En supposant que l'heure actuelle est '2012-03-08 11:00:00', le rapport montrerait (grosso modo):

Hour  EventCount
----  ----------
23    0
0     0
1     0
2     0
3     0
4     0
5     0
6     0
7     0
8     1
9     3
10    1

J'ai trouvé une solution qui utilise une table qui a un enregistrement pour chaque heure de la journée. J'ai réussi à obtenir les résultats que je cherchais en utilisant un UNION et une logique de casse alambiquée dans la clause where, mais j'espérais que quelqu'un aurait une solution plus élégante.

Pour SQL Server 2005+, vous pouvez générer ces 12 enregistrements très facilement avec une boucle et un CTE récursif. Voici un exemple de CTE récursif:

DECLARE @Date DATETIME
SELECT @Date = '20120308 11:00:00'

;WITH Dates AS
(
    SELECT DATEPART(HOUR,DATEADD(HOUR,-1,@Date)) [Hour], 
      DATEADD(HOUR,-1,@Date) [Date], 1 Num
    UNION ALL
    SELECT DATEPART(HOUR,DATEADD(HOUR,-1,[Date])), 
      DATEADD(HOUR,-1,[Date]), Num+1
    FROM Dates
    WHERE Num <= 11
)
SELECT [Hour], [Date]
FROM Dates

Ensuite, vous venez de le joindre à votre table d'événements.

Les tableaux de pointage peuvent être utilisés pour des choses comme celle-ci. Ils peuvent être très efficaces. Créez le tableau de pointage ci-dessous. J'ai créé la table de pointage avec seulement 24 lignes pour votre exemple, mais vous pouvez la créer avec autant de fois que vous le souhaitez à d'autres fins.

SELECT TOP 24 
        IDENTITY(INT,1,1) AS N
   INTO dbo.Tally
   FROM Master.dbo.SysColumns sc1,
        Master.dbo.SysColumns sc2

--===== Add a Primary Key to maximize performance
  ALTER TABLE dbo.Tally
    ADD CONSTRAINT PK_Tally_N 
        PRIMARY KEY CLUSTERED (N) WITH FILLFACTOR = 100

J'ai supposé que votre table s'appelait dbo.tblEvents, exécutez la requête ci-dessous. Je pense que c'est ce que vous recherchez:

SELECT t.n, count(e.EventTime)
FROM dbo.Tally t
LEFT JOIN dbo.tblEvent e  on t.n = datepart(hh, e.EventTime)
GROUP BY t.n
ORDER BY t.n

Je crois que le mérite revient aux liens suivants, je crois que c'est là que j'ai rencontré cela pour la première fois:

http://www.sqlservercentral.com/articles/T-SQL/62867/

http://www.sqlservercentral.com/articles/T-SQL/74118/

Tout d'abord, mes excuses pour le retard dans ma réponse depuis mes derniers commentaires.

Le sujet a été soulevé dans les commentaires selon lesquels l'utilisation d'un CTE récursif (rCTE à partir de maintenant) s'exécute assez rapidement en raison du faible nombre de lignes. Bien que cela puisse paraître ainsi, rien ne pourrait être plus éloigné de la vérité.

CONSTRUIRE UNE TABLE ET UNE FONCTION TALLY

Avant de commencer les tests, nous devons créer une table de pointage physique avec l'index cluster approprié et une fonction de pointage de style Itzik Ben-Gan. Nous ferons également tout cela dans TempDB afin de ne laisser tomber accidentellement les goodies de personne.

Voici le code pour construire la table Tally et ma version de production actuelle du merveilleux code d'Itzik.

--===== Do this in a nice, safe place that everyone has
    USE tempdb
;
--===== Create/Recreate a Physical Tally Table
     IF OBJECT_ID('dbo.Tally','U') IS NOT NULL
        DROP TABLE dbo.Tally
;
     -- Note that the ISNULL makes a NOT NULL column
 SELECT TOP 1000001
        N = ISNULL(ROW_NUMBER() OVER (ORDER BY (SELECT NULL))-1,0)
   INTO dbo.Tally
   FROM      sys.all_columns ac1
  CROSS JOIN sys.all_columns ac2
;
  ALTER TABLE dbo.Tally
    ADD CONSTRAINT PK_Tally PRIMARY KEY CLUSTERED (N)
;
--===== Create/Recreate a Tally Function
     IF OBJECT_ID('dbo.fnTally','IF') IS NOT NULL
        DROP FUNCTION dbo.fnTally
;
GO
 CREATE FUNCTION [dbo].[fnTally]
/**********************************************************************************************************************
 Purpose:
 Return a column of BIGINTs from @ZeroOrOne up to and including @MaxN with a max value of 1 Trillion.

 As a performance note, it takes about 00:02:10 (hh:mm:ss) to generate 1 Billion numbers to a throw-away variable.

 Usage:
--===== Syntax example (Returns BIGINT)
 SELECT t.N
   FROM dbo.fnTally(@ZeroOrOne,@MaxN) t
;

 Notes:
 1. Based on Itzik Ben-Gan's cascading CTE (cCTE) method for creating a "readless" Tally Table source of BIGINTs.
    Refer to the following URLs for how it works and introduction for how it replaces certain loops. 
    http://www.sqlservercentral.com/articles/T-SQL/62867/
    http://sqlmag.com/sql-server/virtual-auxiliary-table-numbers
 2. To start a sequence at 0, @ZeroOrOne must be 0 or NULL. Any other value that's convertable to the BIT data-type
    will cause the sequence to start at 1.
 3. If @ZeroOrOne = 1 and @MaxN = 0, no rows will be returned.
 5. If @MaxN is negative or NULL, a "TOP" error will be returned.
 6. @MaxN must be a positive number from >= the value of @ZeroOrOne up to and including 1 Billion. If a larger
    number is used, the function will silently truncate after 1 Billion. If you actually need a sequence with
    that many values, you should consider using a different tool. ;-)
 7. There will be a substantial reduction in performance if "N" is sorted in descending order.  If a descending 
    sort is required, use code similar to the following. Performance will decrease by about 27% but it's still
    very fast especially compared with just doing a simple descending sort on "N", which is about 20 times slower.
    If @ZeroOrOne is a 0, in this case, remove the "+1" from the code.

    DECLARE @MaxN BIGINT; 
     SELECT @MaxN = 1000;
     SELECT DescendingN = @MaxN-N+1 
       FROM dbo.fnTally(1,@MaxN);

 8. There is no performance penalty for sorting "N" in ascending order because the output is explicity sorted by
    ROW_NUMBER() OVER (ORDER BY (SELECT NULL))

 Revision History:
 Rev 00 - Unknown     - Jeff Moden 
        - Initial creation with error handling for @MaxN.
 Rev 01 - 09 Feb 2013 - Jeff Moden 
        - Modified to start at 0 or 1.
 Rev 02 - 16 May 2013 - Jeff Moden 
        - Removed error handling for @MaxN because of exceptional cases.
 Rev 03 - 22 Apr 2015 - Jeff Moden
        - Modify to handle 1 Trillion rows for experimental purposes.
**********************************************************************************************************************/
        (@ZeroOrOne BIT, @MaxN BIGINT)
RETURNS TABLE WITH SCHEMABINDING AS 
 RETURN WITH
  E1(N) AS (SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL 
            SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL 
            SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL 
            SELECT 1)                                  --10E1 or 10 rows
, E4(N) AS (SELECT 1 FROM E1 a, E1 b, E1 c, E1 d)      --10E4 or 10 Thousand rows
,E12(N) AS (SELECT 1 FROM E4 a, E4 b, E4 c)            --10E12 or 1 Trillion rows                 
            SELECT N = 0 WHERE ISNULL(@ZeroOrOne,0)= 0 --Conditionally start at 0.
             UNION ALL 
            SELECT TOP(@MaxN) N = ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) FROM E12 -- Values from 1 to @MaxN
;
GO

Au fait ... remarquez que vous avez construit un million et une table de pointage et ajouté un index clusterisé dans environ une seconde. Essayez cela avec un rCTE et voyez combien de temps cela prend! ;-)

CONSTRUIRE QUELQUES DONNÉES DE TEST

Nous avons également besoin de données de test. Oui, je suis d'accord que toutes les fonctions que nous allons tester, y compris le rCTE, s'exécutent en une milliseconde ou moins pour seulement 12 lignes, mais c'est le piège dans lequel beaucoup de gens tombent. Nous parlerons plus en détail de ce piège plus tard, mais pour l'instant, permet de simuler l'appel de chaque fonction 40 000 fois, ce qui correspond au nombre de fois où certaines fonctions de ma boutique sont appelées dans une journée de 8 heures. Imaginez combien de fois ces fonctions pourraient être appelées dans une grande entreprise de vente au détail en ligne.

Donc, voici le code pour construire 40000 lignes avec des dates aléatoires, chacune ayant un numéro de ligne uniquement à des fins de suivi. Je n'ai pas pris le temps de faire des heures entières car cela n'a pas d'importance ici.

--===== Do this in a nice, safe place that everyone has
    USE tempdb
;
--===== Create/Recreate a Test Date table
     IF OBJECT_ID('dbo.TestDate','U') IS NOT NULL
        DROP TABLE dbo.TestDate
;
DECLARE  @StartDate DATETIME
        ,@EndDate   DATETIME
        ,@Rows      INT
;
 SELECT  @StartDate = '2010' --Inclusive
        ,@EndDate   = '2020' --Exclusive
        ,@Rows      = 40000  --Enough to simulate an 8 hour day where I work
;
 SELECT  RowNum       = IDENTITY(INT,1,1)
        ,SomeDateTime = RAND(CHECKSUM(NEWID()))*DATEDIFF(dd,@StartDate,@EndDate)+@StartDate
   INTO dbo.TestDate
   FROM dbo.fnTally(1,@Rows)
;

CONSTRUIRE QUELQUES FONCTIONS POUR FAIRE LA CHOSE DES 12 HEURES

Ensuite, j'ai converti le code rCTE en fonction et créé 3 autres fonctions. Ils ont tous été créés en tant que iTVF hautes performances (Inline Table Valued Functions). Vous pouvez toujours le dire car les iTVF n'ont jamais de BEGIN comme Scalar ou mTVF (Multi-Statement Table Valued Functions).

Voici le code pour construire ces 4 fonctions ... Je les ai nommées d'après la méthode qu'elles utilisent et pas ce qu'elles font juste pour faciliter leur identification.

--=====  CREATE THE iTVFs
--===== Do this in a nice, safe place that everyone has
    USE tempdb
;
-----------------------------------------------------------------------------------------
     IF OBJECT_ID('dbo.OriginalrCTE','IF') IS NOT NULL
        DROP FUNCTION dbo.OriginalrCTE
;
GO
 CREATE FUNCTION dbo.OriginalrCTE
        (@Date DATETIME)
RETURNS TABLE WITH SCHEMABINDING AS
 RETURN
WITH Dates AS
(
    SELECT DATEPART(HOUR,DATEADD(HOUR,-1,@Date)) [Hour], 
      DATEADD(HOUR,-1,@Date) [Date], 1 Num
    UNION ALL
    SELECT DATEPART(HOUR,DATEADD(HOUR,-1,[Date])), 
      DATEADD(HOUR,-1,[Date]), Num+1
    FROM Dates
    WHERE Num <= 11
)
SELECT [Hour], [Date]
FROM Dates
GO
-----------------------------------------------------------------------------------------
     IF OBJECT_ID('dbo.MicroTally','IF') IS NOT NULL
        DROP FUNCTION dbo.MicroTally
;
GO
 CREATE FUNCTION dbo.MicroTally
        (@Date DATETIME)
RETURNS TABLE WITH SCHEMABINDING AS
 RETURN
 SELECT  [Hour] = DATEPART(HOUR,DATEADD(HOUR,t.N,@Date))
        ,[DATE] = DATEADD(HOUR,t.N,@Date)
   FROM (VALUES (-1),(-2),(-3),(-4),(-5),(-6),(-7),(-8),(-9),(-10),(-11),(-12))t(N)
;
GO
-----------------------------------------------------------------------------------------
     IF OBJECT_ID('dbo.PhysicalTally','IF') IS NOT NULL
        DROP FUNCTION dbo.PhysicalTally
;
GO
 CREATE FUNCTION dbo.PhysicalTally
        (@Date DATETIME)
RETURNS TABLE WITH SCHEMABINDING AS
 RETURN
 SELECT  [Hour] = DATEPART(HOUR,DATEADD(HOUR,-t.N,@Date))
        ,[DATE] = DATEADD(HOUR,-t.N,@Date)
   FROM dbo.Tally t
  WHERE N BETWEEN 1 AND 12
;
GO
-----------------------------------------------------------------------------------------
     IF OBJECT_ID('dbo.TallyFunction','IF') IS NOT NULL
        DROP FUNCTION dbo.TallyFunction
;
GO
 CREATE FUNCTION dbo.TallyFunction
        (@Date DATETIME)
RETURNS TABLE WITH SCHEMABINDING AS
 RETURN
 SELECT  [Hour] = DATEPART(HOUR,DATEADD(HOUR,-t.N,@Date))
        ,[DATE] = DATEADD(HOUR,-t.N,@Date)
   FROM dbo.fnTally(1,12) t
;
GO

CONSTRUISEZ LE HARNAIS D'ESSAI POUR TESTER LES FONCTIONS

Enfin, nous avons besoin d'un harnais de test. Je fais une vérification de base et teste ensuite chaque fonction de manière identique.

Voici le code du harnais de test ...

PRINT '--========== Baseline Select =================================';
DECLARE @Hour INT, @Date DATETIME
;
    SET STATISTICS TIME,IO ON;
 SELECT  @Hour = RowNum
        ,@Date = SomeDateTime
   FROM dbo.TestDate
  CROSS APPLY dbo.fnTally(1,12);
    SET STATISTICS TIME,IO OFF;
GO
PRINT '--========== Orginal Recursive CTE ===========================';
DECLARE @Hour INT, @Date DATETIME
;

    SET STATISTICS TIME,IO ON;
 SELECT  @Hour = fn.[Hour]
        ,@Date = fn.[Date]
   FROM dbo.TestDate td
  CROSS APPLY dbo.OriginalrCTE(td.SomeDateTime) fn;
    SET STATISTICS TIME,IO OFF;
GO
PRINT '--========== Dedicated Micro-Tally Table =====================';
DECLARE @Hour INT, @Date DATETIME
;

    SET STATISTICS TIME,IO ON;
 SELECT  @Hour = fn.[Hour]
        ,@Date = fn.[Date]
   FROM dbo.TestDate td
  CROSS APPLY dbo.MicroTally(td.SomeDateTime) fn;
    SET STATISTICS TIME,IO OFF;
GO
PRINT'--========== Physical Tally Table =============================';
DECLARE @Hour INT, @Date DATETIME
;
    SET STATISTICS TIME,IO ON;
 SELECT  @Hour = fn.[Hour]
        ,@Date = fn.[Date]
   FROM dbo.TestDate td
  CROSS APPLY dbo.PhysicalTally(td.SomeDateTime) fn;
    SET STATISTICS TIME,IO OFF;
GO
PRINT'--========== Tally Function ===================================';
DECLARE @Hour INT, @Date DATETIME
;
    SET STATISTICS TIME,IO ON;
 SELECT  @Hour = fn.[Hour]
        ,@Date = fn.[Date]
   FROM dbo.TestDate td
  CROSS APPLY dbo.TallyFunction(td.SomeDateTime) fn;
    SET STATISTICS TIME,IO OFF;
GO

Une chose à noter dans le faisceau de test ci-dessus est que je shunte toutes les sorties dans des variables "jetables". C'est pour essayer de garder les mesures de performances aussi pures que possible sans aucun résultat sur le disque ou l'écran.

UN MOT D'ATTENTION SUR LES STATISTIQUES FIXÉES

Aussi, un mot d'avertissement pour les testeurs potentiels ... Vous NE DEVEZ PAS utiliser SET STATISTICS lors du test des fonctions Scalar ou mTVF. Il ne peut être utilisé en toute sécurité que sur des fonctions iTVF comme celles de ce test. Il a été prouvé que SET STATISTICS rend les fonctions SCALAR exécutées des centaines de fois plus lentement qu'elles ne le font réellement sans lui. Oui, j'essaie d'incliner un autre moulin à vent, mais ce serait un article complet de plus long et je n'ai pas le temps pour ça. J'ai un article sur SQLServerCentral.com qui parle de tout cela, mais cela n'a aucun sens de publier le lien ici parce que quelqu'un sera complètement déformé à ce sujet.

LES RÉSULTATS DU TEST

Donc, voici les résultats du test lorsque j'exécute le faisceau de test sur mon petit ordinateur portable i5 avec 6 Go de RAM.

--========== Baseline Select =================================
Table 'Worktable'. Scan count 1, logical reads 82309, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'TestDate'. Scan count 1, logical reads 105, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

 SQL Server Execution Times:
   CPU time = 203 ms,  elapsed time = 206 ms.
--========== Orginal Recursive CTE ===========================
Table 'Worktable'. Scan count 40001, logical reads 2960000, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'TestDate'. Scan count 1, logical reads 105, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

 SQL Server Execution Times:
   CPU time = 4258 ms,  elapsed time = 4415 ms.
--========== Dedicated Micro-Tally Table =====================
Table 'Worktable'. Scan count 1, logical reads 81989, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'TestDate'. Scan count 1, logical reads 105, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

 SQL Server Execution Times:
   CPU time = 234 ms,  elapsed time = 235 ms.
--========== Physical Tally Table =============================
Table 'Worktable'. Scan count 1, logical reads 81989, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'TestDate'. Scan count 1, logical reads 105, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Tally'. Scan count 1, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

 SQL Server Execution Times:
   CPU time = 250 ms,  elapsed time = 252 ms.
--========== Tally Function ===================================
Table 'Worktable'. Scan count 1, logical reads 81989, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'TestDate'. Scan count 1, logical reads 105, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

 SQL Server Execution Times:
   CPU time = 250 ms,  elapsed time = 253 ms.

Le "BASELINE SELECT", qui ne sélectionne que les données (chaque ligne créée 12 fois pour simuler le même volume de retour), est arrivé à droite environ 1 / 5ème de seconde. Tout le reste est arrivé à environ un quart de seconde. Eh bien, tout sauf cette fonction rCTE sanglante. Cela a pris 4 et 1/4 secondes ou 16 fois plus longtemps (1600% plus lent).

Et regardez les lectures logiques (mémoire IO) ... Le rCTE a consommé 2 960 000 (presque 3 MILLIONS de lectures) alors que les autres fonctions n'en ont consommé qu'environ 82 100. Cela signifie que le rCTE a consommé plus de 34,3 fois plus d'E / S de mémoire que n'importe quelle autre fonction.

PENSÉES DE CLÔTURE

Résumons. La méthode rCTE pour faire cette "petite" chose à 12 lignes a utilisé 16 fois (1 600%) plus de CPU (et durée) et 34,3 fois (3 430%) plus d'E / S de mémoire que n'importe quelle autre fonction.

Hé ... je sais à quoi tu penses. "Big Deal! Ce n'est qu'une fonction."

Oui, d'accord, mais combien d'autres fonctions avez-vous? Combien d'autres endroits en dehors des fonctions avez-vous? Et en avez-vous qui fonctionnent avec plus de 12 lignes à chaque exécution? Et, y a-t-il une chance que quelqu'un dans le pétrin pour une méthode copie ce code rCTE pour quelque chose de beaucoup plus gros?

Ok, il faut être franc. Cela n'a absolument aucun sens pour les gens de justifier un code à performances réduites simplement en raison d'un nombre ou d'une utilisation de lignes supposés limités. Sauf lorsque vous achetez une boîte MPP pour peut-être des millions de dollars (sans parler des frais de réécriture du code pour le faire fonctionner sur une telle machine), vous ne pouvez pas acheter une machine qui exécute votre code 16 fois plus rapidement (SSD a gagné ne le fais pas non plus ... tout ce truc était dans la mémoire à haute vitesse quand nous l'avons testé). La performance est dans le code. De bonnes performances sont dans un bon code.

Pouvez-vous imaginer si tout votre code s'exécutait "seulement" 16 fois plus rapidement?

Ne justifiez jamais un code défectueux ou compromis par les performances sur de faibles nombres de lignes ou même sur une faible utilisation. Si vous le faites, vous devrez peut-être emprunter l'un des moulins à vent que j'ai été accusé d'incliner pour garder vos processeurs et vos disques suffisamment frais. ;-)

UN MOT SUR LE MOT "TALLY"

Oui je suis d'accord. Sémantiquement parlant, la table de pointage contient des nombres, pas des "décomptes". Dans mon article original sur le sujet (ce n'était pas l'article original sur la technique mais c'était mon premier dessus), je l'ai appelé "Tally" non pas à cause de ce qu'il contient, mais à cause de ce qu'il fait ... c'est utilisé pour "compter" au lieu de boucler et "Tally" quelque chose est de "Count" quelque chose. ;-) Appelez ça comme vous voulez ... Tableau des nombres, tableau de pointage, tableau des séquences, peu importe. Je m'en fiche. Pour moi, "Tally" signifie plus complet et, étant un bon DBA paresseux, ne contient que 5 lettres (2 sont identiques) au lieu de 7 et c'est plus facile à dire pour la plupart des gens. C'est aussi "singulier", qui suit ma convention de dénomination pour les tables. ;-) Il' s aussi comment l'appelait l'article qui contenait une page d'un livre des années 60. Je vais toujours y faire référence en tant que «tableau de pointage» et vous saurez toujours ce que moi ou quelqu'un d'autre veut dire. J'évite également la notation hongroise comme la peste, mais j'appelle la fonction "fnTally" pour que je puisse dire "Eh bien, si vous utilisiez la fonction d'eff-en Tally que je vous ai montrée, vous n'auriez pas de problème de performance" sans que ce soit réellement un Violation des RH. ;-) sans qu'il s'agisse en fait d'une violation des RH. ;-) sans qu'il s'agisse en fait d'une violation des RH. ;-)

Ce qui m'inquiète le plus, c'est que les gens apprennent à l'utiliser correctement au lieu de recourir à des choses comme les rCTE à performances réduites et d'autres formes de RBAR caché.

Vous aurez besoin de RIGHT JOINvos données avec une requête renvoyant un enregistrement pour chaque heure dont vous avez besoin.

Voir ceci pour quelques façons d'obtenir un numéro de ligne que vous pouvez ensuite soustraire en heures de l'heure actuelle.

Dans Oracle, une requête hiérarchique sur dual générera des lignes:

SELECT to_char(sysdate-level/24,'HH24') FROM dual CONNECT BY Level <=24;