Pana de curand cea mai folosita cale de a realiza diferite operatiuni cu ajutorul calculatorului era conectarea la un sistem de operare de la un terminal conectat direct la sistem. Totul era stocat in server.
Pe masura ce calculatoarele au evoluat, au aparut si alte modalitati de a interactiona cu calculatorul si de asemenea au evoluat si RDBMS. In prezent exista trei moduri de abordare:
Initial, softul Oracle, bazele de date, codul aplicatiilor, tot ceea ce era necesar pentru a realiza sarcinile dorite erau localizate pe o masina. Se lucra de la un terminal conectat direct la calculator pentru a se realiza ceea ce se cerea. Aceasta presupunea o distanta mica fata de calculatorul pe care era instalat Oracle, o distanta care sa permita functionarea retelei.
Cateva probleme apareau in cazul acesta:
distanta fata de calculatorul cu care se interactiona trebuia sa fie mica
daca distanta fata de calculatorul central era prea mare, puteau apare interferente.
nu se puteau primi sau trimite informatii catre alte locatii usor.
In cadrul arhitecturii client/server softul Oracle si bazele de date erau plasate pe o platforma iar codul aplicatiilor clientului pe un PC. Produsul Oracle, Net8 a fost folosit pentru transmiterea interogarilor catre server si a datelor inapoi catre PC. Erau necesare resurse substantiale pentru PC, si asigurarea ca toate calculatoarele client sunt sigure.
Arhitectura client/server are avantajul impartirii procesarii in retea a aceleiasi aplicatii. O parte a procesarii aplicatiei se realizeaza pe server iar alta parte pe statia de lucru. Pe aceasta se realizeaza managementul placii video, interfata cu utilizatorul si procese ale aplicatiei care sunt independente de baza de date. Nu numai ca este o impartire egala a procesarii intre calculatorul client si server, dar se pot realiza diverse aplicatii independente de server. Activitatea PC client se poate desfasura la distante mai mari de locatia fizica a serverului.
Urmatorul tip de arhitectura foloseste statii de lucru de capacitate mica, cateodata fara hard disk, ca prim tier.
Exista mai multe abordari in ceea ce priveste securizarea sistemului de operare si bazei de date si un numar egal de variante in ceea ce indeplineste definitia de "sistem de operare sigur". Un sistem cu adevarat sigur este acela care nu permite nimanui sa interactioneze cu interiorul calculatorului. Aceasta nu este o solutie care sa poata fi aplicata in realitate dar conduce la concluzia ca atata tip cat exista oameni care interactioneaza cu sistemul, exista intotdeauna pericolul unor incalcari ale securitatii. Unul dintre cele mai importante pericole pentru securitatea oricarui sistem sunt utilizatorii care nu se deconecteaza la terminarea programului sau care nu au parola pe terminalele lor sau pe PC.
Din perspectiva sistemului de operare, masurile de securitate sunt luate pentru a proteja accesul la fisiere. In majoritatea sistemelor, asigurarea securitatii se realizeaza creand grupuri specifice de utilizatori fiecare cu drepturile de acces specifice. Fiecarui fisier dintr-un director ii pot fi acordate diferite restrictii de acces. Se poate asigna dreptul de a citi si de a scrie intr-un fisier in timp ce un alt fisier poate fi doar citit. De exemplu pentru un angajat e la informatii care nu putea decat sa citeasca informatii din fisier se acorda privilegiul reed only in timp ce pentru administrator, care are dreptul sa si modifice inregistrarile se acorda si privilegiul write.
Nici un utilizator nu ar trebui sa aiba acces direct la fisierele de date ale sistemului Oracle si nici la softul Oracle (codul sursa). Accesul la fisierele bazei de date este responsabilitate si functia sistemului de management al bazei de date. Accesul la aceste fisiere ar trebui sa fie intotdeauna sever restrictionat.
In continuare se vor urmari cateva consideratii privind instalarea softului Oracle si crearea unei baze de date Oracle. Deoarece pentru fiecare sistem de operare instalarea poate fi diferita, aceasta discutie nu se raporteaza la platforma. Corporatia Oracle pune la dispozitia utilizatorilor ghide de instalare specifice sistemelor de operare.
Mecanismul standard pentru controlul accesului pentru Oracle este o combinatie de nume si parola pentru baza de date. Aceasta permite accesul de la orice statie de lucru care se poate conecta la calculatorul pe care ruleaza sistemul de management al bazei de date. In unele cazuri, insa, identificarea si autentificare in punctul de acces sunt mult mai sever controlate.
In Oracle exista cateva optiuni pentru a realiza un control mai sever al accesului. De la varianta Oracle 7 in continuare, DBA a avut la dispozitie doua cai de a realiza autentificarea pentru RDBMS Oracle.
Pentru a realiza sarcini administrative in calitate de DBA, daca se doreste administrarea uneia sau mai multor baze de date direct pe masina pe care acestea rezida, se va alege cel mai probabil autentificarea la nivel de sistem de operare. Daca se doreste administrarea uneia sau mai multor baze de date de la un calculator client si legatura nu poate fi considerata sigura, se va apela la cea dea doua varianta: parola.
In functie de sistemul de operare folosit, la instalarea softului Oracle se pot crea doua grupuri pentru a pune la dispozitia administratorii bazei de date si operatorilor autentificarea la nivel de sistem de operare. Aceste grupuri (in documentatia Oracle se vor numi roluri), care sunt acordate la nivel de sistem de operare se numesc OSDBS (pentru administratori) si OSOPER (pentru operatori). Pot avea diferite nume si diferite functionalitati in functie de sistemul de operare cu care se lucreaza.
OSDBA este, evident, folosit in combinatie cu functiile DBA.
Pe o platforma UNIX , realizarea unui cont de utilizator in grupul DBA da posibilitatea acelui utilizator sa interactioneze cu baza de date, sa realizeze orice functie pe care rolul OSDBA o permite. De asemenea plasarea unui utilizator in grupul sistem OPERATOR permite utilizatorului sa realizeze sarcini permise de rolul OSOPER.
Prin comparatie, intr-un sistem OpenVMS, identificatorul la nivelul sistemului de operare ORA_DBA or ORA <SID> DBA este creat si acordat oricarui cont care realizeaza functii DBA cu rolul OSDBA. In sistemul OpenVMS nu exista un grup similar pentru operatori. Orice utilizator care este plasat intr-un grup al sistemului de operare, DBA, are posibilitatea sa se conecteze la baza de date folosind Server Manager Utility (svrmgr).
Cand se incearca comanda CONNECT INTERNAL folosind svrmgrl (sau svrmgrm pe un system UNIX), se realizeaza conectarea la nucleul RDBMS ca sys si se pot realiza actiuni ce sunt potential periculoase pentru baza de date. Deci asignarea unui utilizator la grupul DBA ar trebui facuta cu grija, evitand acordarea de privilegii persoanelor care ar putea pune in pericol sistemul.
Daca se doreste limitarea numarului de privilegii date unui utilizator care indeplineste sarcini de DBA, se pot crea propriile roluri. Nu trebuie luate decizii privind crearea acestor roluri in momentul instalarii, si se pot dezactiva aceste roluri dupa instalare.
De obicei, rolul OSOPER are posibilitatea sa realizeze urmatoarele comenzi:
STARTUP
SHUTDOWN
ALTER DATABASE OPEN/MOUNT
ALTER DATABASE BACKUP
ARCHIVE LOG
RECOVER
Acest rol permite utilizatorilor sa activeze RESTRICTED SESSION. Abilitatea de a realiza oricare din aceste operatii cere ca utilizatorul sa posede privilegii mai inalte decat utilizatorii obijnuiti.
Rolul OSDBA cuprinde toate privilegiile de sistem ale rolului DBA si posibilitatea pentru utilizator de a crea baze de date CREATE DATABASE si posibilitatea pentru utilizator de a efectua recuperari.
Grupurile OSDBA si OSOPER pot fi acordate unui utilizator prin intermediul sistemului de operare si nu pot fi acordate, revocate sau sterse prin baza de date. Metoda folosita pentru a acorda aceste grupuri este specifica sistemului de operare. Daca un utilizator incearca sa se conecteze la baza de date din sistemul de operare si parametrul REMOTE_LOGIN_PASSWORD din fisierul bazei de date este setat pe "NONE", Oracle va incerca mai intai sa se conecteze folosind rolul OSDBA. Daca aceasta incercare esueaza, Oracle va incerca sa foloseasca rolul OSOPER, pentru conectare. Daca nu se reuseste in nici-una din cele doua incercari, conectarea esueaza.
Exista cateva tipuri de conturi care pot fi cerute de sistem. In continuare se vor examina tipurile de accesare a sistemului de operare cerute de un DBA sau operator pentru a realiza anumite actiuni referitoare la baza de date.
In primele versiuni ale Oracle RDBMS, pentru a porni sau a opri baza de date se lansa o comanda de la nivelul command al sistemului de operare. In Windows NT, inca se mai poate porni sau opri baza de date lansand urmatoarea comanda:
Net Start OracleStart<db name>
Net Stop OracleStart<db name>
Incepand cu Oracle versiunea 6.0. a fost introdusa o noua conventie pentru conectarea la baza de date si pentru lansarea de comenzi interactive pentru a realiza actiuni in baza de date. In versiunile mai vechi ale RDBMS Oracle (versiunea 6 si versiunea 7.1.x) metoda de conectare la baza de date pentru a indeplini sarcini ca STARTUP, SHUTDOWN si CREATE DATABASE se realiza printr-un utilitar numit SQLDBA. Se introducea comanda CONNECT INTERNAL pentru conectarea la baza de date la unu nivel cat mai privilegiat. Folosind mecanismul CONNECT INTERNAL, se conecta la baza de date ca sys putand fi indeplinite acele sarcini cu succes. Aceste sarcini, de oprire, pornire, sau crearea unei baze de date nu pot fi realizate direct din SQL*Plus, nici chiar ca utilizator sys.
Incepand cu versiunea 7 utilitarul Oracle folosit pentru a realiza aceste actiuni s-a schimbat. Noul utilitar folosit este Server Manager line mode (svrmgrl) si una din urmatoarele variante
CONNECT INTERNAL AS SYSDBA
CONNECT / AS SYSDBA
CONNECT INTENAL AS SYSOPER
CONNECT / AS SYSOPER
in functie de grupul sistemului de operare caruia ii apartine contul .
Incepand cu versiunea 7.2., pentru a porni o baza de date, se lanseaza urmatoarea comanda:
svrmgr1
CONNECT / AS SYSDBA
STARTUP OPEN <db name>
EXIT
Pentru majoritatea sistemelor de operare, acest set de comenzi nu poate fi indeplinit cu succes daca nu se au OSOPER sau OSDBA sau privilegii de sistem echivalente.
Pentru ca un utilizator sa se poata conecta la o baza de date fara a tasta explicit o parola are la dispozitie trei variante folosite frecvent. Toate cele trei abordari se folosesc de contul OPS$.
Pentru prima abordare contul este creat cu prefixul "OPS$" folosit in numele contului, si o parola este asignata acelui utilizator. Utilizatorul se poate conecta de la nivelul sistemului de operare la o baza de date folosind doar "/" in loc de username/pasword. Nu este necesar ca utilizatorul sa tasteze numele lui si parola ca sa dobandeasca accesul la baza de date. Daca, totusi, utilizatorul doreste sa se conecteze la baza de date de la un client indepartat isi poate folosi numele si parola pentru a se conecta cu succes. Avantajul acestei abordari este ca utilizatorul isi poate ascunde atat numele cat si parola cand foloseste conectarea la nivel de linie de comanda si totusi sa pastreze posibilitatea de a folosi SQL*Net pentru a se conecta le baza de date de pe o masina client.
In cazul celei de-a doua variante, se seteaza parametrul INIT.ORA ca OS AUTHENT PREFIX="", si numele actual al utilizatorului fara prefixul "OPS$" este folosit pentru a crea contul utilizatorului. Nici-o parola nu este asignata contului utilizator. In schimb, contul este creat cu optiunea IDENTIFIED EXTERNALLY. Utilizatorul se poate conecta la baza de date de la nivelul sistemului de operare dar nu are parola pentru a activa accesul de la o masina client.
Singura diferenta intre a doua si a treia abordare este folosirea parametrului REMOTE OS AUTHENT din INIT.ORA setat la "true" pentru a activa o "identificare externa" pentru cont pentru conectarea la baza de date de la o masina client. Dezavantajul in cazul acestei forme de acces este acela ca securitate bazei de date poate fi compromisa de altcineva de cat utilizatorii indreptatiti, cineva care se poate conecta la baza de date fara sa cunoasca nici un nume de utilizator nici parola.
Oracle pune la dispozitia utilizatorilor posibilitatea de a accesa baza de date de la nivelul sistemului de operare fara sa foloseasca unu nume-utilizator si parola. Cand acest mecanism, setat cu optiunea IDENTIFIED EXTERNALLY, este folosit, sistemul Oracle considera autentificarea la nivel de sistem suficienta si permite accesul la baza de date pe baza contului din sistemul de operare. Avantajul folosirii unui cont ce se bazeaza pe autentificarea la nivel de sistem este urmatorul: nu mai este nevoie sa se tasteze o parola la linia de comanda a sistemului de operare. Acesta este un mare avantaj pentru un dezvoltator de baze de date care testeaza codul de la nivelul prompterului sistemului de operare si nu doreste ca parola lui sa fie expusa. Aceasta abordare este indicata si pentru rularea unei proceduri pentru o aplicatie fara sa se introduce o parola in procedura si astfel sa se faca posibila o bresa in securitate.
Dezavantajul acestei abordari este urmatorul: daca dezvoltatorul are un cont cu "identified externally" si nu isi blocheaza terminalul cand pleaca de la masina oricine poate avea acces la baza sa de date fara sa fie nevoie sa cunoasca o parola. Conectarea cu identificare externa ar trebui folosita numai pe baze de date de test sau in curs de dezvoltare.
Singura modalitate ca abordarea "identified externally" sa poata fi folosita in mod sigur intr-un "productio sistem" este crearea unui cont astfel incat utilizatorul sa nu aiba acces la nivelul sistemului de operare. In sistemul OpenVMS, de exemplu, sistemul de operare trateaza un cont care a fost etichetat ca si "captiv" ca ne-avand nici-un privilegiu la nivelul sistemului de operare. Asadar, daca un utilizator va incerca sa iasa din aplicatia pe care o foloseste si incearca sa ajunga la nivelul sistemului de operare, procesul curent al utilizatorului va fi inchis. Utilizatorul va fi automat deconectat.
In mediul UNIX, utilizatorul poate fi plasat in ' trusted shell' (tsh). Profilul de conectare (.profile or .cshrc/.login) poate sa includa o comanda START pentru o aplicatie, urmata de comanda EXIT. In acest mod, aplicatia utilizatorului este pornita la conectare, si accesul la sistemul de operare este controlat s-au eliminat. Cand se iese din aplicatie se paraseste si sesiunea de logare. Acest .profile pentru cont trebuie personalizat pentru a captura roate caracterele de control astfel incat utilizatorul sa nu poata iesi di procesul de logare. In sistemul UNUX, aceasta se poate realiza usor prin comanda TRAP. Chiar si cu un control sever al contului aplicatiei, rolurile si privilegiile pentru cont ar trebui sa fie strict evaluate pentru a se asigura un pericol cat mai mic pentru sistem.
In fisierul de initializare al bazei de date (INIT.ORA) parametrul OS_AUTHENT_PREFIX poate fi setat la un prefix, daca exista, prefix ce va fi folosit pentru a identifica o baza de date care se bazeaza doar pe verificarea utilizatorului facuta de sistemul de operare. La instalare valoarea predefinita a RDBMS Oracle pentru OS_AUTHENT_PREFIX este 'OPS$'. De aceea, prin conventie, pentru a identifica un cont care permite conectarea la baza de date fara folosirea unui nume si unei parole, se va scrie numele utilizator precedat de valoarea 'OPS$'. De exemplu, numele contului din sistemul de operare este mary, numele bazei de date va fi ops$mary, si comanda CREATE pentru contul din baza de date va fi:
CREATE USER ops$mary IDENTIFIED BY abc75!d
Se observa folosirea unei parole in comanda de mai sus. Parola este ceruta de sintaxa comenzii, dar, deoarece este vorba e un cont OPS$, utilizatorul nu va trebui sa foloseasca aceasta parola la conectare. In mod predefinit, un cont creat cu prefixul OPS$ poate fi folosit pentru a accesa baza de date fara folosirea unui username/password de la un cont al sistemului de operare cu un nume asemanator (minus prefixul OPS$ ). Deci, daca un DBA va dori un cont ce poate fi folosit pentru a se conecta la baza de date prin de pe o masina client, si care sa poata fi folosit din sistemul de operare fara a face uz de un nume si o parola, aceasta conventie va functiona foarte bine. Cand utilizatorul se conecteaza folosind SQL*Net, tasteaza numele 'OPS$<username>' si parola in zona rezervata pentru parola. Cand se conecteaza direct prin contul din sistemul de operare, foloseste doar "/" ca nume utilizator si parola.
De exemplu de pe un PC client, utilizatorul mary se va loga folosind:
username: ops$mary
password: abc75!d
De la nivelul sistemului de operare utilizatorul se va conecta astfel:
sqlplus /
Un alt mod de a aborda aceasta problema este folosirea contului 'identified xternally' si setarea parametrului REMOTE_OS_AUTHENT pe 'TRUE'. Prin aceasta modalitate se activeaza un cont care a fost creat folosind acelasi nume ca contul client pentru conectarea la baza de date prin SQL*Net fara folosirea unei parole. Presupunem ca contul de pe PC este identificat prin numele mary si un cont este creat in baza de date SMOKE pentru mary identified externally.' mary poate acum selecta SQL*Plus din meniul start/program al PC propriu si la tastarea '/@SMOKE' sa se conecteze la linia de comanda SQL> in instanta SMOKE. Daca mary este conectata direct la sistemul de operare pe care ruleaza SMOKE, poate inca sa foloseasca 'sqlplus /' pentru a accesa baza de date.
In scenariul din paragraful anterior, amenintarea la adresa securitatii ar fi fost plecarea utilizatorului mary de la terminal fara sa il blocheze. Atunci oricine ar fi capabil sa acceseze baza de date fara sa cunoasca numele utilizator al lui mary si parola, si sa se foloseasca de privilegiile lui mary in sistem.
Al doilea potential pericol este faptul ca se foloseste un remote operating system
asupra caruia nu se are nici-un control. Tot ceea ce trebuie sa faca cineva este sa descopere in baza de date Oracle pe cineva care are rolul dorit, inclusiv DBA, cu un cont care a fost IDENTIFIED EXTERNALY. Atunci acea persoana poate crea un cont cu acelasi nume ca si contul cu privilegii al bazei de date, si acea persoana s-a conectat la baza de date cu cele mai inalte privilegii si nu se mai poate face nimic in privinta asta, exceptand setarea REMOTE_OS_AUTHENT=FALSE.
Ca o metoda alternativa se poate folosi in Oracle 8 pentru autorizarea unui cont utilitarul ORAPWD.
O alta metoda Oracle folosita pentru autentificarea unui cont este utilitarul ORAPWD. Acest utilitar este folosit pentru a crea un fisier parola pentru a permite contului unui client SQL*Net sa se conecteze la o baza de date fara sa foloseasca o parola. Acest utilitar este folosit de Oracle Enterprise Manager pentru conectarea la baza de date cu scopul de a realiza diferite sarcini de DBA.
Realizarea unui mediu in care sa se poata folosi fisierul parola implica doi pasi. Fisierul trebuie creat cu utilitarul, ORAPWD apoi trebuie asignata o valoare variabilei REMOTE_LOGIN_PASSWORD din INIT.ORA.
Sintaxa pentru utilitarul ORAPWD :
Usage: orapwd file=<fname> password=<password> entries=<users>
where
file - name of password file (mand),
password - password for SYS and INTERNAL (mand),
entries - maximum number of distinct DBA and OPERs (opt),
There are no spaces around the equal-to (=) character.
Sintaxa folosita pentru a crea fisierul parola ar trebui sa fie aceeasi de la un sistem de operare la altul. Parametrii au urmatoarele sensuri:
FILE
Este necesar sa fie o cale completa (i.e. numele trebuie sa includa numele disk, numele directorului, si numele fisierului).
PASSWORD
Stabileste parola folosita pentru utilizatorii sys si internal. Daca se actioneaza asupra utilizatorului pentru a schimba parola stabilita in fisierul parola, parola se va schimba atat in baza de date cat si in fisierul parola.
ENTRIES
Este folosit doar in cazul in care parametrul REMOTE_LOGIN_ PASSWORDFILE din INIT.ORA este setat pe 'EXCLUSIVE.' Aceasta valoare reprezinta numarul maxim de utilizatori care se pot conecta la baza de date cu privilegiile SYSDBA si SYSOPER. De vreme ce fisierul trebuie recreat daca numarul maxim de utilizatori permisi trebuie crescut , numarul ar trebui setat mare de crearea initiala.
Pentru a folosi utilitarul ORAPWD trebuie deci mai intai unde ar trebui plasat fisierul parola pentru fiecare baza de date si ce parole vor fi folosite. Trebuie de asemenea hotarat daca daca se va imparti un fisier parola sau daca va exista un fisier pentru fiecare baza de date existenta in sistem.
Daca este folosit un fisier imparti, conturile care acceseaza baza de date se pot conecta doar ca sys si system. Aceasta inseamna ca nu se pot restrictiona actiunile pe care acel cont le poate executa. Daca este folosit un cont exclusiv, conturile care acceseaza baza de date pot fi definite creand utilizatori in acea baza de date si acordandu-le privilegiile SYSDBA si SYSOPER. Asadar, cand se creeaza un fisier parola exclusiv, se pot controla mai bine privilegiile disponibile utilizatorilor care au acces la baza de date. Cand se creeaza un cont care are acordate SYSDBA si sau SYSOPER, parola asignata acestui cont este de asemenea inregistrata intr-un format codat in fisierul parola.
Urmatorul pas in stabilirea unui mediu in care sa se poata folosi un cont care sa acceseze baza de date folosind un fisier parola este sa se asigneze o valoare parametrului
REMOTE_LOGIN_PASSWORDFILE din INIT.ORA. Cele trei posibile valori sunt:
NONE
Nu se va folosi nici-un fisier parola.
EXCLUSIVE
Fisierul parola va fi folosit doar de o baza de date.
SHARED
Fisierul parola va fi impartit intre mai multe baze de date.
Aparitia unui produs care a facut posibila interactiunea cu o baza de date de la un client remote a reprezentat un mare avantaj pentru lumea calculatoarelor. Pentru RDBMS Oracle, acest produs a fost SQL*Net (Net8 pentru Oracle8). Acest utilitar este interfata de retea a sistemului Oracle facilitand comunicarea in retea dintre clienti si server-ele bazei de date, precum si intre doua sau mai multe server-e ale bazei de date. Este un utilitar Oracle care permite implementare arhitecturii client/server, realizand schimb de date intre nucleele Oracle. Utilitarul permite conexiunea unei aplicatii care se executa pe masina client cu un nod (nucleu) Oracle (server). Clientul trimite cererea server-ului sub forma de mesaje. Server-ul decodifica mesajele in cereri SQL, le executa si trimite apoi rezultatul clientului. Chiar daca aduce multe avantaje, acest produs aduce si posibile amenintari in ceea ce priveste securitatea.
Conectarea la baza de date prin SQL*Net este controlata de trei fisiere, fisierul LISTENER.ORA, fisierul TNSNAMES.ORA si fisierul SQLNET.ORA. Daca nu se defineste baza de date in aceste fisiere (operatiune numita 'configuring the Listener'), conectarea la baza de date printr-un remote client este imposibila. Intr-un mediu in care este folosit Oracle Names Server, al treilea fisier SQLNET.ORA, defineste locatia pentru Names Server si ordinea in care conectarea la baza de date este realizata. Fisierul SQLNET.ORA indica daca Names Server va fi verificat mai intai pentru informatii despre conectarea la baza de date sau daca fisierul TNSNAMES.ORA va fi verificat mai intai.
Daca se va folosi Names Server, trebuie configurate aceste trei fisiere, dupa instalarea produsului SQL*Net pe propriul sistem si pentru a lansa un proces listener, dupa cum urmeaza:
LISTENER.ORA
Acesta este un required file pe serverul bazei de date, si contine configuratia pentru listener. Daca cateva listenere vor fi folosite intr-un nod, vor imparti acelasi fisier
LISTENER.ORA. Fisierul contine trei parti: zona care defineste adresa de listening, SID pentru care fiecare baza de date este listens si parametrii care definesc comportamentul listenerului.
TNSNAMES.ORA
Acesta este un fisier required pe serverul bazei de date si s-ar putea sau nu , sa fie cerut pe client, depinzand de folosirea sau nu a Names Server. Fisierul contine the service names ale tuturor bazelor de date la care se doreste conectarea si informatii despre conectare -de exemplu, protocolul folosit, locatia gazdei, etc.
SQLNET.ORA
Acest fisier contine parametrii pentru locatia fisierelor log si trace pentru clientii SQL*Net. Daca va fi folosit Names Server, fisierul mai contine informatii despre numele de server preferate pentru Names Server si despre calea directorului pentru Names Server. Acest fisier va indica de asemenea daca Names Server sau fisierul TNSNAMES.ORA va fi cercetat primul pentru informatii privind conexiunea.
Instalarea produsului de baza SQL*Net este foarte directa pe orice platforma. Por si simplu se selecteaza produsele din meniul de instalare. Trebuie cunoscut protocolul folosit in mediul in care se lucreaza pentru a se selecta componentele potrivite din lista disponobila. Daca se instaleaza SQL*Net server, trebuie identificata locatia directorului client si numele grupului client.
Configurare SQL*Net s-ar pute sa nu fie asa directa ca instalarea produsului. In mediul Windows NT, listenerul poate fi configurat automat si pornit folosind programul de instalare si valorile predefinite.
Prima decizie care trebuie luata dupa instalarea produsului SQL*Net este daca se doreste ca Names Server sa furnizeze informatiile despre conectare pentru baza de date proprie sau daca se doreste mentinerea informatiilor legate de conexiune, personal. Instalarea, mentinerea si interactiunea cu Names Server presupune folosirea unui utilitar de management al retelei. Daca se foloseste Names Server pe Oracle 8, se va folosi Net8 Assistant pentru a configura Names Server.
Dupa ce a fost configurat listenerul si este gata de functionare, clientii trebuie sa isi instaleze o versiune client a SQL*Net si sa creeze fisierul TNSNAMES.ORA folosind un produs care se numeste Easy Net Config, pentru a se conecta la baza de date. Daca exista multe baze de date in sistem sau numele lor se schimba frecvent, va fi foarte dificil pentru clienti sa tina pasul cu fisierul lor TNSNAMES.ORA. De fiecare data cand se upgradeaza sistemul, utilizatorii clienti vor trebui sa isi upgradeze softul client SQL*Net.
Avantajul in a folosi Names Server este ca singurul fisier care trebuie fieldet catre toate masinile client este SQLNET.ORA. Toate noile baze de date sunt inregistrate cu Names Server, si toate fisierele necesare sunt generate automat. Dezavantajul consta in faptul ca trebuie facute modificari asupra configuratiei prin intermediul utilitarului Network Manager; daca datele privind configuratia sunt pastrate in baza de date si nu in fisier sistem si nu se poate avea acces la ele, clientii nu vor pute obtine informatii despre conectare si nu se vor pute conecta la baza de date.
A doua decizie care trebuie luata este daca fiecare network listener va avea o parola asociata sau nu. Parola predefinita pentru listener este listener, dar parola poate fi schimbata, ca in exemplul urmator:
PASSWORDS_LISTENER = (oracle)
Daca se va folosi o parola pentru fiecare listener, trebuie asigurata protectia fisierului LISTENER.ORA care pastreaza parolele, pentru a nu fi citit de cineva care nu este DBA insarcinat cu administrarea configuratiei SQL*Net.
Fisierele de initializare a parametrilor sunt principalul mijloc de configurare a RDBMS-ului. El este pur si simplu o colectie de valori ale unor parametrii, care fiecare controleaza sau modifica un anumit aspect din modul de functionare al bazei de date si instante. Fisierul de initializare este un fisier ASCII care poate fi editat de catre administratorul bazei de date pentru optimizarea performantelor acesteia. Numele atribuit in mod implicit fisierului de initializare a parametrilor este INITSID.ORA unde SID este identificatorul de sistem pentru baza de date pe care o controleaza. Fisierul de initializare este citit inainte de pornirea bazei de date, schimbarile facute parametrilor in acest fisier nu sunt luate in considerare pana cand instanta nu este oprita si re-pornita. Totusi unii din parametrii de initializare au caracter dinamic, adica pot fi modificati in timp ce o instanta este pornita. Efectul schimbarii acestor parametrii va fi imediat, nefiind necesara inchiderea si repornirea instantei. Schimbarea parametrilor in mod dinamic se poate face cu ajutorul comenzilor:
ALTER SESSION
Parametrii se schimba doar in acea sesiune si nu raman dupa ce sesiune se inchide.
ALTER SYSTEM
Parametrii raman neschimbati pana ce baza de date este oprita dar s-ar putea sa nu afecteze sesiunea curenta.
ALTER SYSTEM DEFFERED
Nu afecteaza sesiunea curenta dar s-ar putea sa afecteze sesiunile viitoare pana cand baza de date este inchisa.
Exista mai mult de 100 de parametrii care pot fi setati in fisierul INIT.ORA. RDBMS Oracle are valori implicite pentru fiecare parametru. Pentru a afla valoarea unui parametru se poate folosi utilitarul Server Manager. Comanda care afiseaza valoarea unui parametru este urmatoarea
SVRMGR> SHOW PARAMETERS
Exista parametrii in Oracle care au valori minime. Daca acesti parametrii sunt setatii la valori prea mici, Oracle fie nu va porni, fie va lucra foarte prost.
|
Politica de confidentialitate |
 .com |
Copyright ©
2024 - Toate drepturile rezervate. Toate documentele au caracter informativ cu scop educational. |
Personaje din literatura |
| Baltagul – caracterizarea personajelor |
| Caracterizare Alexandru Lapusneanul |
| Caracterizarea lui Gavilescu |
| Caracterizarea personajelor negative din basmul |
Tehnica si mecanica |
| Cuplaje - definitii. notatii. exemple. repere istorice. |
| Actionare macara |
| Reprezentarea si cotarea filetelor |
Geografie |
| Turismul pe terra |
| Vulcanii Și mediul |
| Padurile pe terra si industrializarea lemnului |
| Termeni si conditii |
| Contact |
| Creeaza si tu |
