Kwestia wersji

tele_img_08

Zmiany zachowania bazy danych ORACLE przy migracji z 9.2 do 11.2
W sieci można znaleźć wiele artykułów opisujących sposoby migracji bazy do nowszej wersji oraz najlepsze praktyki dotyczące rozwiązywania problemów występujących podczas tego procesu. Przeprowadzając jedną z migracji, zetknąłem się z dwoma przypadkami świadczącymi o bardziej rygorystycznym podejściu nowszej wersji do kodu PL/SQL, który nie do końca był poprawny. Ciekawostką jest, że ten kod działał w wersji 9.2 bez najmniejszych problemów, zaś w przypadku wersji 11.2 powodował trudne do namierzenia błędy.

XML – namespace

Przy pobraniu wartości elementu, jeżeli XML zawierał namespace – w wersji 9.2 wystarczyło, gdy w funkcji extract w parametrze xpath podaliśmy prefiks namespace zgodny z XML. Oczywiście takie podejście do obsługi XML jest błędne, bo w przypadku otrzymania dokumentu XML, który nadal jest poprawny, ale zmienił prefiks nasz kod przestanie działać. Wersja 11.2 wymaga od programisty poprawnej obsługi XML przez podanie drugiego parametru z prefixem namespace’a. W poniższym przykładzie 12 linia kodu w wersji 11.2 spowoduje w następnej linii błąd „ORA-31011 Niepowodzenie analizy składniowej XML”:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
DECLARE
src_xml VARCHAR2(4000);
src_xmlType xmltype;
extract_xmlType xmltype;
extract_value VARCHAR2(10);
BEGIN
src_xml :=
'
123
'
;
src_xmlType := xmltype(src_xml);
extract_xmlType := src_xmlType.EXTRACT('/dp:service/ID/text()');
extract_value := extract_xmlType.getstringval();
DBMS_OUTPUT.put_line(extract_value);
END;

Po dodaniu drugiego parametru o wartości ‚xmlns:dp=”http://test.pl/SU/xmlschemas/test1″‚ nasz blok PL/SQL wykonuje się poprawnie. Możemy także obsłużyć dokument XML na zmienionym prefiksie – np. xx:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
DECLARE
src_xml VARCHAR2(4000);
src_xmlType xmltype;
extract_xmlType xmltype;
extract_value VARCHAR2(10);
BEGIN
src_xml :=
'
123
'
;
src_xmlType := xmltype(src_xml);
extract_xmlType := src_xmlType.EXTRACT('/dp:service/ID/text()',
'xmlns:dp="http://test.pl/SU/xmlschemas/test1"');
extract_value := extract_xmlType.getstringval();
DBMS_OUTPUT.put_line(extract_value);
END;

Kursor referencyjny ze zbyt dużą liczbą kolumn

W przypadku użycia kursora referencyjnego zwracającego większą liczbę kolumn, niż odbieramy za pomocą instrukcji FETCH, baza ORACLE 9.2 ignorowała nadmiarowe kolumny, poprawnie zwracając te, dla których przewidzieliśmy miejsce. Poniższy przypadek zostanie poprawnie wykonany i zmienne l_n1, l_n2 i l_n3 będą miały poprawne wartości a wartości 4 i 5 zostaną pominięte:

1
2
3
4
5
6
7
8
9
10
DECLARE
kur_ref SYS_REFCURSOR;
l_n1 NUMBER;
l_n2 NUMBER;
l_n3 NUMBER;
BEGIN
OPEN kur_ref FOR 'select 1,2,3,4,5 from dual';
FETCH kur_ref INTO l_n1, l_n2, l_n3;
CLOSE kur_ref;
END;

Baza w wersji 11.2 nie jest już tak spolegliwa i o jakości kodu poinformuje nas niezbyt adekwatnym komunikatem błędu „ORA-00932 niespójne typy danych: oczekiwano -, uzyskano –„. Być może bardziej odpowiednim byłoby użycie komunikatu podobnego do tego, jaki stosuje się w przypadku użycia zwykłego kursora „PLS-00394: wrong number of values in the INTO list of a FETCH statement”. W mojej sytuacji prawdopodobnie pozwoliłoby to na zaoszczędzenie kilku godzin debugowania kodu.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *