Als ik de voorbeeldtabel van Jonearles leen, zie ik precies hetzelfde (in 11gR2 op een OEL-ontwikkelaarsimage), meestal krijg ik waarden voor a sterk scheef naar 1; met kleine steekproefomvang kan ik er soms helemaal geen zien. Met de extra randomisatie/beperkingsstap die ik in een opmerking noemde:
select a, count(*) from (
select * from test1 sample (1)
order by dbms_random.value
)
where rownum < 101
group by a;
... met drie runs kreeg ik:
A COUNT(*)
---------- ----------
1 71
2 29
A COUNT(*)
---------- ----------
1 100
A COUNT(*)
---------- ----------
1 64
2 36
Ja, 100% kwam echt terug als 1 op de tweede run. Het scheeftrekken zelf lijkt nogal willekeurig te zijn. Ik heb het geprobeerd met het block modifier die weinig verschil leek te maken, misschien verrassend - ik had misschien gedacht dat het in deze situatie erger zou worden.
Dit is waarschijnlijk langzamer, zeker voor kleine steekproefomvang, omdat het de hele tafel moet raken; maar geeft me redelijk gelijkmatige splitsingen, redelijk consistent:
select a, count(*) from (
select a, b from (
select a, b, row_number() over (order by dbms_random.value) as rn
from test1
)
where rn < 101
)
group by a;
Met drie runs kreeg ik:
A COUNT(*)
---------- ----------
1 48
2 52
A COUNT(*)
---------- ----------
1 57
2 43
A COUNT(*)
---------- ----------
1 49
2 51
... wat er wat gezonder uitziet. YMMV natuurlijk.
Dit Oracle-artikel
behandelt enkele bemonsteringstechnieken, en misschien wilt u de ora_hash . evalueren aanpak ook, en de gestratificeerde versie als uw gegevensspreiding en uw vereisten voor 'representatie' daarom vragen.