sql >> Databáze >  >> RDS >> Oracle

Pochopení chování ORA_ROWSCN v Oracle

Ve výchozím nastavení ORA_ROWSCN je uložen na úrovni bloku, nikoli na úrovni řádku. Ukládá se pouze na úrovni řádku, pokud byla tabulka původně vytvořena pomocí ROWDEPENDENCIES povoleno. Za předpokladu, že se do jednoho bloku vejde mnoho řádků tabulky a že nepoužíváte APPEND Pokud chcete vložit nová data nad stávající horní hranici tabulky, pravděpodobně vkládáte nová data do bloků, které již obsahují nějaká existující data. Ve výchozím nastavení se tím změní ORA_ROWSCN z každého řádku v bloku, což způsobí, že váš dotaz bude počítat více řádků, než bylo skutečně vloženo.

Od ORA_ROWSCN je zaručeno, že je pouze horní hranicí při posledním použití DML na řádku, bylo by mnohem běžnější určit, kolik řádků bylo dnes vloženo přidáním CREATE_DATE sloupec do tabulky, která má výchozí hodnotu SYSDATE nebo se spolehnout na SQL%ROWCOUNT za INSERT běžel (samozřejmě za předpokladu, že používáte jeden INSERT příkaz pro vložení všech řádků).

Obecně pomocí ORA_ROWSCN a SCN_TO_TIMESTAMP funkce bude problematický způsob, jak identifikovat, kdy byl vložen řádek, i když je tabulka vytvořena pomocí ROWDEPENDENCIES . ORA_ROWSCN vrátí Oracle SCN, což je číslo systémové změny. Jedná se o jedinečný identifikátor pro konkrétní změnu (tj. transakci). Jako takové neexistuje žádné přímé spojení mezi SCN a časem – moje databáze může generovat SCN milionkrát rychleji než vaše a moje SCN 1 se může roky lišit od vašeho SCN 1. Proces Oracle na pozadí SMON udržuje tabulku, která mapuje hodnoty SCN na přibližná časová razítka, ale udržuje tato data pouze po omezenou dobu – jinak by vaše databáze skončila s tabulkou řádků s mnoha miliardami, která právě ukládala mapování SCN na časové značky. Pokud byl řádek vložen více než například před týdnem (a přesný limit závisí na databázi a verzi databáze), SCN_TO_TIMESTAMP nebude moci převést SCN na časové razítko a vrátí chybu.




  1. MySQLi připravilo prohlášení s dynamickým aktualizačním dotazem

  2. Pochopení 3 klíčových charakteristik velkých dat

  3. Problém s datovým typem Laravel 4.2 BIT

  4. sql server vyberte sloupec podle čísla