Jest 2012 2017. Skrypty to niezgrabny i kruchy kac z ostatniego tysiąclecia. Oracle ma fantastyczny zakres funkcji, które możemy wykonać w PL/SQL, a także procedury składowane w języku Java i harmonogram uruchamiania zadań. Poza uruchamianiem DDL w celu tworzenia lub modyfikowania schematów prawie nie ma potrzeby stosowania skryptów w środowisku bazy danych Oracle; nawet skrypty DDL powinny być uruchamiane z zewnętrznego klienta, prawdopodobnie z narzędzia do budowania, takiego jak TeamCity.
W szczególności uznałbym próbę uruchomienia skryptu SQL z programu PL/SQL za błąd architektury. Co robisz ze skryptem, czego nie możesz zrobić za pomocą procedury składowanej?
Jeśli chodzi o przekazywanie danych wejściowych do procedury składowanej, do tego służą parametry. PL/SQL nie jest interaktywny, potrzebujemy klienta do wprowadzenia wartości. W zależności od scenariusza można to zrobić asynchronicznie (wartości w pliku lub tabeli) lub synchronicznie (wywołując procedurę składowaną z SQL*Plus, SQL Developer lub dostosowany interfejs).
Powiedziawszy to wszystko, w prawdziwym świecie pracujemy z niechlujnymi architekturami z wzajemnymi zależnościami między bazą danych a zewnętrznym systemem operacyjnym. Co więc możemy zrobić?
- Możemy napisać procedurę składowaną Java do wykonywania poleceń powłoki. To czcigodne rozwiązanie, które istnieje od Oracle 8i. Dowiedz się więcej.
- W 10g Oracle zamień DBMS_JOB na DBMS_SCHEDULER. Jednym z ulepszeń tego narzędzia jest możliwość uruchamiania zadań zewnętrznych, tj. skryptów powłoki. Dowiedz się więcej.
- Ponieważ tabele zewnętrzne Oracle 11g R1 obsługują skrypty preprocesora, które uruchamiają polecenia powłoki przed wysłaniem zapytania do tabeli. Dowiedz się więcej.
Zauważ, że wszystkie te opcje wymagają podwyższonego dostępu (udzielenia dostępu do obiektów KATALOGU, poświadczeń bezpieczeństwa itp.). Mogą one być przyznawane tylko przez uprzywilejowanych użytkowników (tj. administratorów baz danych). O ile nasza baza danych nie ma zaskakująco luźnej konfiguracji zabezpieczeń, nie ma możliwości uruchomienia dowolnego skryptu powłoki z PL/SQL.
Wreszcie, nie jest jasne, jakich korzyści oczekujesz od uruchomienia skryptu SQL w PL/SQL. Pamiętaj, że PL/SQL działa na serwerze bazy danych, więc nie widzi skryptów na komputerze klienta . Wydaje się to istotne w świetle wymogu akceptacji danych wprowadzanych przez użytkownika.
Być może najprostszym rozwiązaniem jest rekonfiguracja oryginalnego skryptu. Podziel niezbędne wywołanie PL/SQL na blok, a następnie wywołaj nazwany skrypt:
begin
proc(para1,para2);
end;
/
@prompt1.sql
