Tablespace partizionati con DSSIZE>4GB

Dario Zoso

Tablespace partizionati con DSSIZE>4GB
In effetti il problema è nella gestione degli spazi su disco per i Reorg,
Unload e Copy, le quali richiedono delle quantità di disco notevoli... ci
vuole un grosso impegno nella stima degli spazi necessari e nella gestione
degli stessi.
Auguri

Dario Zoso
----- Original Message -----
From: "Moschelli Mauro" <[login to unmask email]>
To: <[login to unmask email]>
Sent: Thursday, February 17, 2005 4:01 PM
Subject: ZOS: Tablespace partizionati con DSSIZE>4GB


Ciao a tutti,
qualcuno ha esperienza di utilizzo di tablespace partizionati con
DSSIZE>4GB.
Quello che mi preoccupa maggiormente non è tanto il fatto che funzioni, ma
problematiche di gestione/manutenzione/recovery di oggetti che possono
superare le centinaia di gigabyte di dimensione (e relativi indici), anche e
sopratutto con utility di terze parti (CDB).

grazie a tutti


Mauro Moschelli
SanPaoloIMI S.p.A.

Il contenuto e gli allegati di questo messaggio sono strettamente
confidenziali, e ne sono vietati la diffusione e l'uso non autorizzato.

Le opinioni ivi eventualmente espresse sono quelle dell'autore: di
conseguenza il messaggio non costituisce impegno contrattuale tra
Sanpaolo IMI ed il destinatario, e la banca non assume alcuna
responsabilita' riguardo ai contenuti del testo e dei relativi allegati,
ne' per eventuali intercettazioni, modifiche o danneggiamenti.

Qualora il presente messaggio Le fosse pervenuto per errore, Le saremmo
grati se lo distruggesse e, via e-mail, ce ne comunicasse l' errata
ricezione all'indirizzo [login to unmask email]


This e-mail (and any attachment(s)) is strictly confidential and for use
only by intended recipient(s). Any opinions therein expressed are those
of the author. Therefore its content doesn't represent any commitment
between Sanpaolo IMI and the recipient(s) and no liability or
responsibility is accepted by Sanpaolo IMI for the above mentioned
content.

Sanpaolo IMI S.p.A. is a Bank authorised by Banca d'Italia; Sanpaolo IMI
S.p.A., London Branch, is regulated by the Financial Services Authority
for the conduct of investment business in the UK.

If you are not an intended recipient(s), please notify
[login to unmask email] promptly and destroy this message.

---------------------------------------------------------------------------------
Benvenuti alla lista DB2 User Group Italia.Per annullare l ' iscrizione
collegarsi a : http://www.idugdb2-l.org/archives/DB2-UG-Italy.html.
Selezionare "Join or Leave the list". Per consultare le IDUG Listserv FAQ
collegarsi a :http://www.idugdb2-l.org. L'amministratore della lista DB2
User Group - Italy può essere raggiunto al seguente indirizzo:
[login to unmask email] Per sapere le ultime novità sulle
conferenze IDUG potete consultare : http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Benvenuti alla lista DB2 User Group Italia.Per annullare l ' iscrizione collegarsi a : http://www.idugdb2-l.org/archives/DB2-UG-Italy.html. Selezionare "Join or Leave the list". Per consultare le IDUG Listserv FAQ collegarsi a :http://www.idugdb2-l.org. L'amministratore della lista DB2 User Group - Italy può essere raggiunto al seguente indirizzo: [login to unmask email] Per sapere le ultime novità sulle conferenze IDUG potete consultare : http://conferences.idug.org/index.cfm

Max Scarpa

Re: Tablespace partizionati con DSSIZE>4GB
(in response to Dario Zoso)
Bè intanto controlla di avere le PTF di SMS aggiornate per la gestione dei
file EA, che non guasta, a volte Media Manager gli EA non li digerisce:-)
Anche quelle DB2, DSN1PRNT potrebbe non funzionare a dovere per es.
(gestione dell'RBA critica oltre i 4 Gb).

Poi cerchiamo di usare i file EA a ragion veduta e tenendo conto della
futura evoluzione per non trovarsi 'con le braghe calate' più avanti,
specialmente in ambienti grossi (vedi articolo di Susan Lawson per
esempio)....e qui si entra in un lungo discorso per certi versi
'filosofico' (e una filosofia rispetto ad un'altra in genere viene scelta
in base a quante volte hai preso botte sui denti.....). Le tabelle sono in
lettura, scrittura, 90% in lettura o 90% in scrittura ? Ti riporto alcune
cose relative alla mia esperienza (ambiente bancario, che potrebbe valere
meno di zero per altri) e DB2 V6 (questo passa il convento).

Qui da noi si usano per tabelle storiche, estratti conti e comunque tabelle
grosse ma poco aggiornate o aggiornate in periodi ben determinati. Non la
vedrei bene per l'anagrafica per es., ma anche qui dipende: se è enorme non
hai molta scelta.

Una volta si prevedeva l'uso di LOAD per gli update che, se va male,
non è così banale da ricoverare (e succedeva spesso perchè chi a suo tempo
fece l'analisi degli spazi faceva....diciamo pena). Infatti abbiamo
trasformato questa procedura utilizzando programmi applicativi che
prevedono ROLLBACK., fatti girare nei 'buchi' di utilizzo macchina e che,
con una SERVICE CLASS adeguata, vanno abbastanza bene. Utilizziamo ancora
le LOAD, ma in maniera estremamente limitata.

Qui abbiamo file EA da parecchio tempo e tablespace DB2 (DSSIZE 32 e 64 GB)
e il problema lo abbiamo risolto in vari modi, in primis utilizzando i
dischi 'spare' ovvero i dischi SMS non ancora assegnati all'utenza (tutte
le installazioni ne hanno in misura variabile, ma molti li tengono lì
inutilizzati perchè 'non si sa mai' oppure perchè il capo degli storage
gals/guys se la/lo tira) per i dataset di work delle reog. Usiamo SHRLEVEL
REFERENCE per lo più, aggiugnendo o togliendo dischi se il pool risulta
inadeguato, se no reorg come ai vecchi tempi (ma non succede quasi mai). E'
ovvio che il DBA ha accesso ai dati del/dei pool di dischi (cosa che non
sempre capita). Utilizziamo le REORG....DISCARD per lo svecchiamento e lo
possiamo fare perchè il design lo aveva già previsto, anche se in via
fortuita.

Sarebbe altamente simpatico avere uno storage group di dischi dedicati,
anche se non è essenziale, ma per la mia esperienza (che non ha valore
statistico) la crescita come spazio occupato dalle tabelle non è mai
esplosiva. Ma aiuta se devo togliere/aggiungere dischi e a tenere sotto
controllo lo spazio con reportistica adeguata. Una analisi utilizzando
algoritmi di time series analysis potrebbe rivelarti una certa
seasonality/trend nella crescita dello spazio su disco e aiutare nella
gestione del pool.

Per quanto riguarda le copy direi che il backup su cassetta è obbligatorio,
qui non crea problemi perchè appunto sono in lettura e le copy possono
girare senza problemi anche perchè le esigenze di 'downtime avoidance' sono
più 'larghe' rispetto ad altri database. E ormai la recovery per crash del
disco direi che è un ricordo, devi ricoverare solo in caso di caricamento
di dati errati o incaute DROP. Va da sè che è essenziale una corretta
history delle copy e dei punti per eventualy recovery point-in-time.
L'unico vero problema qui è che con SHRLEVEL REFERENCE devi *ancora*
mettere la INLINE COPY che per queste tabelle è una fesseria colossale e ti
obbliga ad avere altro spazio su disco che potresti evitare (utilizzando le
utility IBM, per le BMC per es. mi pare di no). Ma tant'è.

Questo per quello che riguarda noi. Ti invito anche ad una ricerca su DB2-L
internazionale, lì abbiamo dibattuto il tema più volte.

Max Scarpa

DB2 sysprog
DASD manager
WLM administrator

PS Se qualcuno è a conoscenza di ricerche di personale per DB2 su mainframe
nell'area VE/VI/PD o limitrofe può farmelo sapere ? Grazie in anticipo.


---------------------------------------------------------------------------------
Benvenuti alla lista DB2 User Group Italia.Per annullare l ' iscrizione collegarsi a : http://www.idugdb2-l.org/archives/DB2-UG-Italy.html. Selezionare "Join or Leave the list". Per consultare le IDUG Listserv FAQ collegarsi a :http://www.idugdb2-l.org. L'amministratore della lista DB2 User Group - Italy può essere raggiunto al seguente indirizzo: [login to unmask email] Per sapere le ultime novità sulle conferenze IDUG potete consultare : http://conferences.idug.org/index.cfm