sql >> Database teknologi >  >> RDS >> Oracle

simpel tilfældig prøveudtagning, mens data trækkes fra lager (oracle-motor) ved hjælp af proc sql i sas

Brug DBMS_RANDOM-pakken til at sortere poster, og brug derefter en rækkebegrænsende klausul til at begrænse til den ønskede prøvestørrelse

Funktionen dbms_random.value opnår et tilfældigt tal mellem 0 og 1 for alle rækker i tabellen, og vi sorterer i stigende rækkefølge efter den tilfældige værdi.

Sådan fremstilles det prøvesæt, du har identificeret:

    SELECT
    *
FROM
    (
        SELECT
            *
        FROM
            tbl1
        ORDER BY dbms_random.value
    )
FETCH FIRST 1000000 ROWS ONLY;

For at demonstrere med eksempelskematabellen, emp , vi prøver 4 poster:

   [email protected]> SELECT
  2      empno,
  3      rnd_val
  4  FROM
  5      (
  6          SELECT
  7              empno,
  8              dbms_random.value rnd_val
  9          FROM
 10              emp
 11          ORDER BY rnd_val
 12      )
 13  FETCH FIRST 4 ROWS ONLY;
EMPNO  RND_VAL
7698   0.06857749035643605682648168347885993709
7934   0.07529612360785920635181751566833986766
7902   0.13618520865865754766175030040204331697
7654   0.14056380246495282237607922497308953768


[email protected]> SELECT
  2      empno,
  3      rnd_val
  4  FROM
  5      (
  6          SELECT
  7              empno,
  8              dbms_random.value rnd_val
  9          FROM
 10              emp
 11          ORDER BY rnd_val
 12      )
 13  FETCH FIRST 4 ROWS ONLY;
EMPNO  RND_VAL
7839   0.00430658806761508024693197916281775492
7499   0.02188116061148367312927392115186317884
7782   0.10606515700372416131060633064729870016
7788   0.27865276349549877512032787966777990909

Med eksemplet ovenfor skal du bemærke, at empno ændres væsentligt under udførelsen af ​​SQL*Plus-kommandoen.

Ydeevnen kan være et problem med det rækkeantal, du beskriver.

EDIT:

Med bordstørrelser i størrelsesordenen 150 gigs - 79 MM ville enhver sortering være smertefuld.

Hvis tabellen havde en surrogatnøgle baseret på en sekvens øget med 1, kunne vi vælge at vælge hver n'te post baseret på nøglen.

for eksempel.

    --scenario n = 3000

 FROM
    tbl1
WHERE
    mod(table_id, 3000) = 0;

Denne tilgang ville ikke bruge et indeks (medmindre der oprettes et funktionsbaseret indeks), men vi udfører i det mindste ikke en sortering på et datasæt af denne størrelse.

Jeg udførte en forklaringsplan med en tabel, der har tæt på 80 millioner poster, og den udfører en fuld tabelscanning (tilstanden fremtvinger dette uden et funktionsbaseret indeks), men det ser holdbart ud.



  1. MariaDB JSON_INSERT() Forklaret

  2. hvordan man opdager sql server timeout fra .NET applikation uden at bruge catch Exception

  3. TSQL Sammenligning af to sæt

  4. Microsoft Office-produktet, der nægter at dø