Oracle 11g: Index monitoring usage (appunti grezzi)

Standard


Ho creato questo script per mettere in monitoring gli indici di determinati schema del vostro db..

SET HEADING OFF
SET FEEDBACK OFF
SET LINESIZE 150
SET VERIFY OFF
SET ECHO OFF
SET PAGESIZE 1000
SELECT ‘ALTER INDEX “‘ || OWNER ||’”.”‘ || INDEX_NAME || ‘” monitoring usage ;’
FROM ALL_INDEXES
WHERE OWNER=’schema1′
OR OWNER=’schema2′
OR OWNER=’schema3′
ORDER BY OWNER,INDEX_NAME
SPOOL usage_indexes.sql
/
SPOOL OFF
SET VERIFY ON
SET LINESIZE 80
SET HEAD ON
SET FEED ON
SET PAGESIZE 24
SET ECHO ON

questo codice attraverso uno spool genera un altro script (usage_indexes.sql) che mette
in monitor gli indici di determinati schema, in questa maniera successivamente potrete
avere un calcolo del reale uso di questi indici (ed eliminare quelli che non servono..).

I modi per determinare quanto gli indici vengono usati sono per esempio:

SELECT owner, object_name, start_monitoring, end_monitoring, DECODE (flags, 0, ‘NO’, ‘YES’) USED FROM sys.object_usage o, dba_objects d WHERE O.OBJ# = D.OBJECT_ID;

oppure (meglio):

SELECT object_owner, object_name, COUNT(*) use_count FROM dba_hist_sql_plan WHERE object_type LIKE ‘INDEX%’ GROUP BY object_owner, object_name;

bye ;)

Openvpn over Squid (with NTLM auth)

Standard

Tanti pensano che saltare il firewall aziendale in ufficio serva solo a “farsi i cazzi propri”, sbattendosene delle policy del content filter sul web (social network, siti bannati, download brutali, etc etc): bene hanno ragione ahahaha …scherzoooo !!! :D ..la cosa che più mi da fastidio (almeno da quando non mi occupo di Networking nel posto in cui lavoro ahahah ) è che qualcun’altro oltre me possa (teoricamente) sfogliare i siti che visito..altre cose invece non mi infastidiscono ma, ancora peggio, mi limitano nell’uso dei protocolli di comunicazione che uso per informarmi (irc ad esempio) o quelli che uso addirittura per lavoro stesso ssh, ftp, nfs, vpn, rsync, etc. etc.
(in realtà nel mio caso esistono altri motivi, uno tra tutti il funzionamento a cazzo del gestore dei pacchetti della mia distribuzione linux in concomitanza ad un proxy che richiede autenticazione ntlm)

Tempo fa scrissi un articolo dove in due righe descrivevo le mosse per effettuare una vpn che
consentisse di non usare un proxy e utilizzare una propria macchina remota come gateway,
in quel caso pero’ la macchina remota potevo raggiungerla perchè avevo un exception su quel ip..
come promesso già ai tempi, vediamo come ottenere la stessa identica possibilità senza avere
questa volta nessun privilegio da networker raccomandato :P.

Analizziamo schematicamente cosa fare per risolvere:
problema-> per uscire sul web, anzi piu’ precisamente proprio su internet, si è obbligati a passare dal proxy, cio’ quindi vale sia per il protocollo http (porta 80) sia per https (443)
soluzione-> da questo momento la vpn nella mia macchina remota girerà sulla 443, in questa
maniera potro’ cmq raggiungerla passando per il proxy.

Il primo problema da superare è che nella mia macchina remota la porta 443 è già in uso dal
mio webserver (ssl), come faro’ a fargli girare pure la vpn avendo a disposizione un solo ip?

La soluzione è sslh un multiplexer che, in ascolto sulla 443, capisce autonomamente (header dei primi pacchetti in arrivo) dove buttarti, sito web, vpn o ssh per esempio..
Ecco un esempio di configurazione di /etc/conf.d/sslh:

RUN=yes
STARTTIME=2
DAEMON_OPTS=”-u root -p ippubblico:443 –ssh 127.0.0.1:1022 –openvpn ippubblico:1194 –ssl 127.0.0.1:1443 -P /var/run/sslh.lock”

cio’ significa che questo demone rimarrà in ascolto sulla 443 e forwarderà le chiamate su sshd
che gira sulla 1022, sulla vpn (1194) o sul webserver (1443).
Ovviamente, prima di startare sslh,bisognerà bindare questi 3 servizi sulle porte specificate su.

Il secondo problema da superare è stato un po’ più complesso e ha richiesto un po’ più di tempo.
Il problema deriva dal fatto che il proxy (squid) nel mio caso prevede autenticazione NTLM
(brrrrrrrr si avete capito bene NTLM :D ) per carità nulla di strano se non fosse che squid ed
ntlm sono due entità poco amiche (penso che conosciate tutti bene i motivi…) e sopratutto il
loro uso congiunto è poco maturo e genera non pochi problemi se chi deve autenticarsi non è un
normale browser, come un proxy http si aspetta, ma un client per una vpn.
Dopo diverse prove (ho addirittura modificato i sorgenti di openvpn scopiazzando quello che
sniffavo durante normali sessioni autenticate con successo con firefox) ho optato per usare…..
indovinate? …Un altro proxy!… Praticamente ho installato un proxy nel mio portatile che
effettuava lui stesso le autenticazioni passandole a vpn… praticamente un relay :)

in questa maniera questa entità effettuava lei stessa l’auth ntlm sul proxy squid fingendosi un
browser e girava poi la connessione ottenuta al client vpn.
Non vi ho detto ancora come si chiama questo diciamo..proxyrelayer
(o come volete definirlo):
cntlm (in realtà ne esistono almeno altri due software open che fanno lo stesso
lavoro). L’ho configurato semplicemente aggiungendo:

Username
Domain
Password Header User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)

cioè l’utenza ntlm da autenticare e l’header per fregare squid fingendosi un browser…

in questa maniera openvpn bindato nella mia vps sulla 443 viene raggiunto dal client openvpn che
specifica come http-proxy quello locale (cntlm).
Ecco a seguire il conf del client (il server.conf rimane praticamente lo stesso di quel articolo
di tempo fa.. ma bindato sulla 443):

remote ipVPS
rport 443
proto tcp-client
tls-client
dev tap

ca ca.crt
key client1.key
cert client1.crt

pull
verb 6
comp-lzo

http-proxy 127.0.0.1 3128

http-proxy-option AGENT Mozilla/5.0+(Windows;+U;+Windows+NT+5.0;+en-GB;+rv:1.7.6)+Gecko/20050226+Firefox/1.0.1
http-proxy-option VERSION 1.0
http-proxy-retry

una volta istaurata la connessione alla vpn, come facevo già una volta (quando avevo l’ip in
exception), in perfetta sintonia con le policy aziendali, creo una rotta (network) per utilizzare
la mia vps come gateway per internet e il gateway aziendale per la lan (e raggiungere i servers
dove lavoro)
ip route add IPmiaVPS via IPgwAziendale (mantiene la connessione con la vpn nonostante il
comando qui sotto)
ip route del default (cancella la rotta di default gateway)
ip route add default via IPtap0 (crea la nuova rotta di default gateway)
ip route add 10.0.0.0/8 via IPgwAziendale dev eth0 (utilizzo il gateway aziendale per
raggiungere una classe 10.0.0.0/8)
ip route add 192.168.3.0/24 IPgwAziendale dev eth0 (come sopra per raggiungere un altra
classe 192.168.3.0/24)

da questo momento posso aprire il mio bel firefox togliendo il proxy dalle impostazioni e navigare
usando l’ip della mia vps (che di fatto effettua le connessioni) ma sopratutto non essere loggato
dal proxy e assicurare la mia privacy.
Salut!

2 parole sulla sicurezza…

Standard


La sicurezza informatica è una materia nuovissima, tanto nuova che diverse
multinazionali non la conoscono ancora…
almeno così sembrebbe leggendo il codice rimasto fino ad oggi in produzione. :D

In realtà loro conoscono benissimo la sicurezza ma spesso non vogliono
affrontare analisi, fuzzing, pentest e altro per paura di dover rivoluzionare
progetti interi che risalgono anche a piu’ di 10anni fa!!

Non faccio nomi, ma la situazione, anche per noi “clienti” che ci fidiamo
non è per niente sicura e non certo io ma la cronaca parla abbastanza
chiara: ogni anno milioni di normali utenti vengono inculati per colpa di
qualche azienda che non li tutela come dovrebbe..

vorrei pero’ abbandonare, almeno per il momento, quello che avviene negli
ambiti enterprise e parlare piu da vicino al privato: cosa deve fare un
normale utente per avere un minimo di sicurezza?

L’argomento è davvero grande già solo per questo ambito “casalingo” non
basterà sicuramente un post, ma cominciamo qui dalle basi, questo primo
appunto sarà di facile fruizione e dedicato a utenti alle prime armi, diciamo,
per intenderci meglio, un post aranzulliano :p

Una delle prime cose che dobbiamo analizzare per capire quanto il nostro
pc è sicuro è il “giro” che i pacchetti in uscita fanno verso internet e
sopratutto se tali pacchetti vengono trasmessi in chiaro..
un altra cosa poi, che riguarda forse più i portatili e i device destinati
ad “uscire da casa” è analizzare anche quanto sono fruibili i dati nostri
sul filesystem e quindi in primis se il nostro profilo è coperto da una
password robusta e consistente e in secundis se il nostro filesystem è
cifrato o meno..l’idea è quella di astrarre il piu possibile, di allontanare
le nostre informazioni da tutti tranne che da noi in maniera decisa e radicale..
più ci riusciamo, più diventa difficile raggiungere i nostri dati personali.

In questo post vi daro’ qualche idea, più avanti, appena trovero’ il tempo
giusto, scrivero’ anche qualche breve tutorial per spiegare come “tirarla su”
(l’idea) senza troppi problemi.

Cominciamo dal/i nostro/i hard-disk, prima di formattarli, se sono stati usati,
andrebbero sempre skretchati con dati randomici, per esempio con un bel:
dd if=/dev/urandom of=/dev/ bs=1M (/dev/drive è il device da sovrascrivere ovviamente)

..ci starà tanto quanto è grande il nostro device..se vogliamo una stima
possiamo dare un:
kill -USR1 $(pidof dd) durante l’operazione..

fatto questo possiamo decidere in base al tipo di partizione (bootabile o meno)
se utilizzare LUKS, truecrypt o altro.. piu avanti, in un altro post, entreremo
nel dettaglio su questo.

Avendo dei device crittati saremo sicuri che se dovessimo perdere il nostro
laptop piangeremo solo (con un occhio?) per lui e non per i nostri dati…
ovviamente questo vale anche per un hd esterno, una usbkey etc etc.

Passiamo adesso al network, come renderci davvero anonimi in rete?

Dicevo che innanzitutto bisogna analizzare quale sarà il giro che i pacchetti
faranno prima di raggiungere internet: il giro in parole povere è
NostroPC—->ROUTER—->In(f)ernet
e scrivo Infernet non a caso… già perchè è proprio cosi’ che dobbiamo
concepirlo per difenderci e renderci invisibili quanto piu’ possibile… :D

Nella rete oltre i piu’ comuni virus e worm girano tanti spider, parecchi robot
in grado di reperire informazioni dai più ingenui utenti..e non parlo delle
pratiche più stupide e facilmente sgamabili tipo il Phishing ma parlo di tanto
altro, di sniffer, trojan, massbots, rootkit etc etc tutte robe che giornalmente
vengono piazzate e utilizzate facilmente su milioni di pc a insaputa di utenti e
(pseudo)sistemisti…l’approccio è sempre lo stesso, il robot dapprima individua
un servizio buggato tramite uno scanport, successivamente sfrutta la vulne
per bindare un proprio socket o cmq avere accesso al target..

Dobbiamo allora rendere invisibili i nostri servizi, o cmq renderli almeno più
sicuri: per far cio’ mi viene in mente iptables, ipfw o anche il nostro router
casalingo, router che nel migliore dei casi è anche un firewall, in questa
maniera sapremo cosa rendere accessibile all’esterno e cosa no e sopratutto
sapremo che tutto cio’ che è accessibile deve essere prima ancora PATCHATO..

io spesso vado anche a cambiare il version sui sorgenti dei servizi prima di
compilarli, e cambio anche le porte di default..questa pratica è inutile se il
servizio è buggato ma è cmq un livello piccolo in piu’ di astrazione, diciamo che
è quel poco che basta per non rendere il servizio localizzabile almeno ai bot
piu’ stupidi che basano le proprie scansioni sulle porte in ascolto e il version
(la rete ne è satura!)..

Se patchati i nostri servizi sono più sicuri di prima (salvo 0day ovviamente).

Vediamo di analizzare adesso quello che “trasmettiamo” su internet:
i nostri pacchetti in uscita, le nostre navigazioni sul web per esempio..

Le pagine web navigate e altro (anche le password!) sappiamo che vengono
raccolte, quando abilitata, nell’history del browser…possiamo stare
sicuri almeno adesso sul fatto che queste siano più sicure visto che
prima abbiamo cifrato il nostro disco.. se volessimo astrarre ancora di
piu’ potremmo usare per le navigazioni più a rischio una macchina
virtuale opportunamente configurata, magari una VM che risieda su un
virtualdisk cifrato con truecrypt e che bootiamo solo all’occorrenza
(per esempio quando dobbiamo utilizzare carte di credito o accedere al
sito della nostra banca).. in questa maniera il file contenente la vm
(vmdk, vdi etc.) viene crittato e a sua volta risiede su un filesystem
crittato: livello di astrazione = +2

..il giro dei dati sarà pero’ sempre lo stesso: anche usando una VM i dati
verranno trasmessi in chiaro dal nostro gateway a Infernet..(e lo stesso
vale per le chiamate al DNS) l’idea sarebbe quella di trovare un nodo, un
relay al quale trasmettere i dati (magari crittati) e che provveda lui
stesso a girare tali dati cifrati in rete: per far cio’ potremmo utilizzare
una VPN in UDP utilizzando una nostra macchina in rete (io uso una vps per
esempio) oppure un qualche servizio su internet (cercate VPN services la
rete è piena, solitamente i migliori sono a pagamento ma assicurano la
cancellazione addirittura dei logs di accesso!).
Esiste anche l’opzione TOR, io la uso sempre come secondaria, nel senso che
arrivo a tor sempre dopo una vpn esterna perchè non mi fido al 100%..

I maniaci come me, inoltre, creano proprio delle sottoreti virtuali sul quale
girare i pacchetti, in particolare io potrei tirare su due o piu macchine
virtuali impostandole una come gw dell’altra e facendole viaggiare su vpn
diverse:

VM1—(vpn udp)—> 1GW/Relay VM2—-(vpn2 udp)—>2GW VM3

I miei dati praticamente “escono” dalla prima macchina virtuale incapsulati e
cifrati tramite la prima vpn instaurata con la seconda VM che a sua volta li
cifra nuovamente e li gira su internet sfruttando un’altra vpn e cosi via…

(PS: è indubbio che più è il numero delle vpn pubbliche più sarà lenta la
navigazione)

in questa maniera siamo sicuri che anche i nostri pacchetti
diventano per lo meno inleggibili (o quasi) :) per provarlo si puo’ utilizzare
un qualsiasi sniffer (tcpdump, ethereal, ettercap) e mettersi ai bordi e
catturare il traffico. ;)
Infine dicevamo delle interrogazioni ai DNS, solitamente queste vengono fatte
dirette dal host (cosa che in molti dimenticano) quindi per completare il nostro
giro dovremmo provvedere a crittarle, un consiglio è quello di cominciare
usando unbound+dnscrypt-proxy oppure nameserver pubblici con zerolog
garantiti…
ma per oggi mi fermo qui.
Amen!

sslh ovvero ssl/ssh multiplexer

Standard


Avete bisogno di utilizzare la 443 per ssh o openvpn (tunnel etc.) ma avete la 443 occupata da https ?
Nessun problema cè SSLH! :)

Nel mio caso ho dapprima bindato sshd sulla 1022 e http ssl sulla 4433 e successivamente configurato il file di configurazione
di sshd (su archlinux /etc/conf.d/sslh ) in questo modo:


LISTEN=178.79.135.237:443
SSH=localhost:1022
SSL=localhost:4433

Il demone sslh praticamente si mette in ascolto sulla 443 analizza il pacchetto, se questo è http lo forwarda sulla 4433 altrimenti sulla 1022 se è una connessione ssh.
Amen

Condividiamo testi, logs etc. con Sprunge da console.

Standard


Post veloce veloce… creiamo un alias inserendo sul file .bashrc della nostra home utente:
alias sprunge=’curl -F “sprunge=<-" http://sprunge.us'
Per capire come funziona il tutto..volete per esempio sharare il vostro dmesg.log su web? Digitate:
cat vostro.log | sprunge
et voilà avrete il link su sprunge del vostro log:)

eccovi l’esempio:
# cat /var/log/dmesg.log |sprunge
http://sprunge.us/rtsNw

ciao!

Shrink Tablespace “problematici”

Standard


Se avete intenzione di modificare un TB su un ambiente di produzione prima ancora di pensarlo prendetevi subito e nell’ordine seguente:
1> una vacanza di almeno 7 giorni (occorre sempre e cmq!)
2> una buona dose di tranquillanti (ogni buon dba oracle/sysadmin unix conserva sempre qualcosa di chimico nel cassetto!)
3> un backup full del DB (non vi ho ancora parlato di export data pump e di RMAN vero? Beh lo faro’..intanto sappiate che Google è un vostro amico![cit.])

Bene ho scritto “Tablespace problematici” e non Tablespace.. già perchè spesso il comando da manuale per il resize:
ALTER DATABASE DATAFILE ‘/home/oracle/oradata/tbmaledetto.dbf’ size 10G
indovinate? Non funziona…
i motivi sono tanti e a volte basta semplicemente un PURGE RECYCLEBIN per risolvere
altre volte invece, quando siete tanto ma taanto ma proprio taaaanto sfigatti il vostro db proviene da svariati
porting e durante il suo percorso, di release in release, il tablespace in questione ha sempre più frammentato i suoi dati all’interno fino a rendere praticamente impossibile perdere tempo tra i blocks liberi e fantomatici recuperi “standard”…

Quindi la soluzione è:

1> Create un TS NUOVO con le dimensioni/datafiles utili a contenere il vecchio..dategli un nome PROVVISORIO
(io ho spostato USERS, e mi sono bastati due DATAFILE da 20Gb ciascuno)
create tablespace USERS2 datafile ‘/home/oracle/oradata/user1.dbf’ size 20G autoextend on,’/home/oracle/oradata/user2.dbf’ size 20G autoextend on;
2> muovete tutti gli oggetti del TS “vecchio” spoolando ed eseguendo questo script:
(io l’ho usato per spostare tutti gli oggetti di USERS dentro USERS2.. modificatelo voi stessi secondo quello
che vi serve oppure se siete fighi sostituite USERS e USERS2 con &VARIABILE1 e &VARIABILE2 ;)

set pagesize 2000
set linesize 200
set echo off
set heading off
select ‘Transporting tablespace ‘ || ‘USERS’ || ‘ to tablespace ‘ || ‘USERS2′ from dual;
select ‘Size: ‘ || to_char((sum(ext.bytes) / 1048576), ’9,990.00′) || ‘ MB’
from dba_objects ob
inner join (
select ta.owner, ta.table_name as nom, ta.tablespace_name as tbs, ‘TABLE’ as tipo from dba_tables ta
union
select ind.owner, ind.index_name as nom, ind.tablespace_name as tbs, ‘INDEX’ as tipo from dba_indexes ind
) tb on tb.owner=ob.owner and tb.nom=ob.object_name and tb.tipo=ob.object_type
inner join dba_extents ext on ext.segment_name = ob.object_name
where ob.object_type in (‘INDEX’, ‘TABLE’, ‘LOB’) and (tb.tbs = ‘USERS’);
select ‘alter user ‘ || ob.owner || ‘ quota unlimited on ‘ || ‘USERS2′ || ‘ default tablespace ‘ || ‘USERS2′ || ‘;’
from dba_objects ob
inner join (
select ta.owner, ta.table_name as nom, ta.tablespace_name as tbs, ‘TABLE’ as tipo from dba_tables ta
union
select ind.owner, ind.index_name as nom, ind.tablespace_name as tbs, ‘INDEX’ as tipo from dba_indexes ind
) tb on tb.owner=ob.owner and tb.nom=ob.object_name and tb.tipo=ob.object_type
where ob.object_type in (‘INDEX’, ‘TABLE’, ‘LOB’) and (tb.tbs = ‘USERS’)
group by ob.owner;
select
decode(ob.object_type,
‘TABLE’,
‘alter table “‘ || ob.owner || ‘”.”‘ || ob.object_name || ‘” move tablespace ‘ || ‘USERS2′ || ‘;’,
‘alter index “‘ || ob.owner || ‘”.”‘ || ob.object_name || ‘” rebuild tablespace ‘ || ‘USERS2′ || ‘;’
)
from dba_objects ob
inner join (
select ta.owner, ta.table_name as nom, ta.tablespace_name as tbs, ‘TABLE’ as tipo from dba_tables ta
union
select ind.owner, ind.index_name as nom, ind.tablespace_name as tbs, ‘INDEX’ as tipo from dba_indexes ind
) tb on tb.owner=ob.owner and tb.nom=ob.object_name and tb.tipo=ob.object_type
where ob.object_type in (‘TABLE’) and (tb.tbs = ‘USERS’);
select
‘alter table “‘ || lo.owner || ‘”.”‘ || lo.table_name ||
‘” move lob (“‘ || lo.column_name || ‘”) store as (tablespace ‘ || ‘USERS2′ || ‘);’
from dba_lobs lo
inner join dba_segments se on se.segment_name = lo.segment_name
where se.tablespace_name = ‘USERS’;
select
decode(ob.object_type,
‘TABLE’,
‘alter table “‘ || ob.owner || ‘”.”‘ || ob.object_name || ‘” move tablespace ‘ || ‘USERS2′ || ‘;’,
‘alter index “‘ || ob.owner || ‘”.”‘ || ob.object_name || ‘” rebuild tablespace ‘ || ‘USERS2′ || ‘;’
)
from dba_objects ob
inner join (
select ta.owner, ta.table_name as nom, ta.tablespace_name as tbs, ‘TABLE’ as tipo from dba_tables ta
union
select ind.owner, ind.index_name as nom, ind.tablespace_name as tbs, ‘INDEX’ as tipo from dba_indexes ind
) tb on tb.owner=ob.owner and tb.nom=ob.object_name and tb.tipo=ob.object_type
where ob.object_type in (‘INDEX’) and (tb.tbs = ‘USERS’);

Adesso il vecchio TS è vuoto… cancellatelo e insultatelo quanto volete:
DROP TABLESPACE users INCLUDING CONTENTS AND DATAFILES;
(PS: se il TS è il DEFAULT USER settate come DEFAULT USERS quello nuovo così:
ALTER database default tablespace users2; )
e rinominate il nuovo con:
ALTER TABLESPACE users2 RENAME TO users;
Finalmente avete risparmiato lo spazio che desideravate e in più avete il vostro bel TS
con i dati frammetati e quindi resizzabile quando e quanto credete.
Amen

Ricreare la TABLESPACE TEMPORANEA su ORACLE

Standard


A volte, nelle giornate peggiori, quando magari determinate congiunzioni astrali non ci sono particolarmente favorevoli puo’ capitare che una TABLESPACE se ne vada a puttane, quando questa TABLESPACE poi è quella TEMPORANEA, dopo aver bestemmiato abbondantemente cominciate a ordinare nella vostra mente le persone alle quali recentemente avete fatto del male filtrando quali tra queste possano centrarci qualcosa con il voodoo, la macumbaa e la stregoneria in generale
ma tralasciamo adesso l’ astrologia, l’ alchimia e le scienze magiche e tornaniamo su sqlplus e al nostro db… :D
la rottura della TS TEMP fortunatamente non capita spesso, puo’ capitare successivamente ad un ripristino o a qualche operazione particolare nel db (*).
Vediamo come è possibile uscirne vivi:
La nostra TS TEMP principale del db è:
SQL> select PROPERTY_VALUE from database_properties
where property_name = ‘DEFAULT_TEMP_TABLESPACE’;

PROPERTY_VALUE
——————————————————————————–
TEMP
E ovviamente se proviamo a fare la cosa più normale in questi casi, e cioè dropparla e rigenerarla, essendo la TEMP globale del db otterremo un errore ORA-12906:
SQL> drop tablespace temp;
drop tablespace temp
*
ERROR at line 1:
ORA-12906: cannot drop default temporary tablespace

Per risolvere il problema dobbiamo quindi creare una nuova TS temporanea provvisoria così:
SQL> create temporary tablespace temp2 tempfile ‘/oradata2/temp2.dbf’ size 10M;
Tablespace created.

Definirla come temporanea principale:
SQL> alter database default temporary tablespace temp2;
Database altered.

Per confermare che sia la TS che vogliamo diamo un:
SQL> select username, temporary_tablespace from dba_users where username in (‘utente1′,’SCOTT’,’utente2′);

USERNAME TEMPORARY_TABLESPACE
—————————— ——————————
utente1 TEMP2
PROD TEMP2
utente2 TEMP2

A questo punto finalmente cancelliamo la TS temporanea ex-di-default
SQL> drop tablespace temp;
Tablespace dropped.

Cancelliamo il datafile corrispondente nel filesystem mi raccomando e infine riprocediamo come sopra
ma stavolta per la TS TEMP definitiva.
Amen

2 Metodi “sicuri” per il cambio del SID su un db ORACLE 11g

Standard


Recentemente, dopo un urgente ripristino di un db su un ambiente diverso da quello sorgente (un ambiente di produzione su uno di collaudo), mi sono ritrovato a imprecare doverne cambiare il nome e diversi altri parametri.
L’ operazione delicata in questi casi è proprio quella del cambio del SID. Esistono due modi che ho sperimentato con esito positivo, il primo è più semplice e consiste nel usare l’ utility DBNEWID.
Dopo il ripristino ho dovuto tirarmi provvisoriamente su l’ istanza in modalità mount e per farlo, nel mio caso, ho in ordine:
* cambiato il sid sul bash_profile dell’utenza unix usata (e ovviamente reso attivo, con il comando source o con login o con su - etc. etc.);
* editato il file init.ora (solitamente initSID.ora) cambiandone il nome (appunto initNUOVOSID.ora) e tutti riferimenti al vecchio SID (dbname, path flashback/logs etc.);
* restartartato il listener (nel mio caso ho lasciato intatto il file listener.ora, visto che il vecchio SID sarà stato successivamente proprio quello che volevo riconfermare);
* SQL> startup mount exclusive ;
* nid target=sys/password DBNAME=nuovoSID SETNAME=Y ;
In questa maniera lo scopo è stato raggiunto e per tirare su il “nuovo” db ho dovuto solo:
* Ricambiare il sid sul enviroment dell’ utente di sistema per oracle;
* Spegnere il db.
* Ricreare l’ SPFILE con un:
SQL> create spfile from pfile=puntando al path di quello nuovo (initNUOVOSID.ora)
* SQL> startup
FINE.

————————————————-

Il secondo metodo come vi dicevo è piu complesso e lungo, consiste nel rifare la procedura a mano x la creazione del controlfile:
Bisogna innanzitutto ricordarsi il PATH settato x files di trace del db:
* SQL> show parameter USER_DUMP_DEST ;
Questo PATH ci servirà a prendere il trace generato dal comando:
* SQL> alter database backup controlfile to trace;
Come vedete dal comando in questa maniera avremmo il ddl per la creazione del cf all’interno del file trace
appena creato.
* Spegniamo il db appena ripristinato:
SQL> shutdown immediate ;
e dalla directory DUMPDEST preleviamo il trc-file corrispondente al controlfileToTrace;
* Editiamolo cominciando a eliminare tutte le righe prima della fase 2 ( Set #2. RESETLOGS case )
* Aggiungiamo un “REUSE” davanti il “SET” della riga: “create controlfile….” modificando il SID vecchio col nuovo, otterremo: “CREATE CONTROLFILE REUSE SET DATABASE “NUOVOSID” ……..
* Cancelliamo tutto quello che viene dopo “CHARACTER SET…”
* Salviamo il nostro file come script sql (.sql)
* Rinominiamo adesso il file initVECCHIOSID.ora in initNUOVOSID.ora (e modifichiamo all’interno i riferimenti al vecchio SID);
* Settiamo l’enviroment x l’ utenza unix e carichiamola.
* SQL> startup nomount ;
* lanciamo il file precedentemente modificato per la creazione del nuovo controlfile ;
* SQL> alter database open resetlogs (occhio alle dir nuove per i logs, il nome sarà il nuovo SID, ci sono già?)
* SQL> alter database rename global_name to
* SQL> alter database open;
* Ricreiamo la TABLESPACE temporanea.

Gather stats for only lastAnalyzed apps Tables (appunti grezzi)

Standard


#!/bin/sh
cd /home/oracle/script/
. /home/oracle/.env11g
/home/oracle/app/product/11.2.0/bin/sqlplus -s /nolog < set feed off pages 1000 lines 120 echo off verify off
connect userDBA/passwd;
spool on
spool statLast.sql
select 'exec dbms_stats.gather_table_stats('''||OWNER|| ''',''' ||table_name|| ''',cascade => TRUE);’ from dba_all_tables where OWNER not like ‘%SYS%’ AND OWNER not like ‘SCOTT’ and OWNER not like ‘XXXX’ AND LAST_ANALYZED is not null AND last_analyzed > (sysdate-NUMdays) order by last_analyzed;
spool off
EOF
#lavora lo spool sql in modo da togliere intestazione della query
/bin/sed /OWNER/d statLast.sql > statLast2.sql
/bin/sed /—–/d statLast2.sql > statLast3.sql
#esegue lo script dinamico creato per le stats specifiche + uno spool per eventuali
/home/oracle/app/product/11.2.0/bin/sqlplus -s /nolog < set feed off pages 1000 lines 120 echo off verify off
connect userDBA/passwd;
spool on
spool ESITOSTATS.TXT
@statLast3
spool off
EOF
exit 0

Juniper/Linux – in VPN con Network connect da linux

Standard


PREPARAZIONE DEL CLIENT (1 sola volta)
- effettuare una prima connessione completa al sito del network connect di juniper https://extranet.dominio.net, in questa maniera verrà scaricato il client nella propria $home creando cosi /home/utente/.juniper_networks/network_connect

- compilare dentro $HOME/.juniper_networks/network_connect/ l’eseguibile ncui così:
gcc -m32 -Wl,-rpath,`pwd` -o ncui libncui.so

- prendiamo adesso il certificato ssl dal host con:
echo | openssl s_client -connect extranet.dominio.net:443 2>&1 |sed -ne ‘/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p’ |openssl x509 -outform der > ssl.crt

CONNESSIONE
- Da questo momento per ogni connessione alla VPN faremo il login sul frontend web del network connect https://extranet.dominio.net e preleveremo il DSID cookie tramite il browser con il comando:

javascript:alert(document.cookie)

in questa maniera successivamente potremmo far partire il client con:
(cd /root/.juniper_networks/network_connect; )
./ncui -h extranet.sace.it -c “DSID=733f7719f6f92672b63bea541f24c73b” -f ssl.crt