Gebruik het DBMS_RANDOM-pakket om records te sorteren en gebruik vervolgens een rijbeperkingsclausule om de gewenste steekproefomvang te beperken
De functie dbms_random.value verkrijgt een willekeurig getal tussen 0 en 1 voor alle rijen in de tabel en we sorteren in oplopende volgorde van de willekeurige waarde.
Hier ziet u hoe u de door u geïdentificeerde sampleset kunt maken:
SELECT
*
FROM
(
SELECT
*
FROM
tbl1
ORDER BY dbms_random.value
)
FETCH FIRST 1000000 ROWS ONLY;
Om te demonstreren met de voorbeeldschematabel, emp
, we samplen 4 records:
[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
Merk in het bovenstaande voorbeeld op dat de empno
verandert aanzienlijk tijdens de uitvoering van het SQL*Plus-commando.
De prestaties kunnen een probleem zijn met het aantal rijen dat u beschrijft.
BEWERKEN:
Met tafelgroottes in de orde van grootte van 150 optredens - 79 MM, zou elke sortering pijnlijk zijn.
Als de tabel een surrogaatsleutel had op basis van een reeks die met 1 werd verhoogd, zouden we de benadering kunnen nemen om elk n-de record op basis van de sleutel te selecteren.
bijv.
--scenario n = 3000
FROM
tbl1
WHERE
mod(table_id, 3000) = 0;
Deze benadering zou geen index gebruiken (tenzij er een op functie gebaseerde index wordt gemaakt), maar we voeren in ieder geval geen sortering uit op een gegevensset van deze omvang.
Ik heb een uitlegplan uitgevoerd met een tabel die bijna 80 miljoen records heeft en het voert een volledige tabelscan uit (de voorwaarde dwingt dit zonder een op functie gebaseerde index), maar dit lijkt houdbaar.