Data Base Blog

2014-10-01T08:53:00.003+02:00

Open Enterprise: The PostgreSQL Open Source Database Blog from EnterpriseDB

Postgres Outperforms MongoDB and Ushers in New Developer Reality

The newest round of performance comparisons of PostgreSQL and MongoDB produced a near repeat of the results from the first tests that proved PostgreSQL can outperform MongoDB. The advances Postgres has made with JSON and JSONB have transformed Postgres’ ability to support a document database.

Creating document database capabilities in a relational database that can outperform the leading NoSQL-only solution is an impressive achievement. But perhaps more important is what this means to the end user – new levels of speed, efficiency and flexibility for developers with the protections of ACID compliance enterprises require for mission critical applications.

Postgres vs. Mongo

EnterpriseDB (EDB) began running comparative evaluations to help users correctly assess Postgres’ NoSQL capabilities. The initial set of tests compared MongoDB v2.6 to Postgres v9.4 beta, on single machine instances. Both systems were installed on Amazon Web Services M3.2XLARGE instances with 32GB of memory.

EDB found that Postgres outperforms MongoDB in selecting, loading and inserting complex document data in key workloads involving 50 million records:

Ingestion of high volumes of data was approximately 2.1 times faster in Postgres
MongoDB consumed 33% more the disk space
Data inserts took almost 3 times longer in MongoDB
Data selection took more than 2.5 times longer in MongoDB than in Postgres

The data is almost identical to the results found in testing with 10 million records. However, it’s important to note a Correction to earlier versions. PostgreSQL community member Alvaro Tortosa found that the MongoDB console does not allow for INSERT of documents > 4K. This led to truncation of the MongoDB size by approx. 25% of all records in the benchmark.
We have published the testing framework for public scrutiny and invite input on the results and our methods as well as suggestions on new testing frameworks. The testing framework is located here on the EDB Github repository.
Developer Freedom
With the newest version, PostgreSQL has ushered in a new era of developer flexibility exceeding the freedom they discovered with NoSQL-only solutions. The use of niche solutions, like MongoDB, increased because developers needed freedom from the structured data model required by relational databases. They needed to move quickly and work with new data types. They choose powerful but limited solutions that addressed immediate needs, that let them make changes without having to wait for a DBA.
However, many organizations have discovered that successful applications often require structure down the road, as data becomes more valuable across the organization.
Postgres gives developers broad new powers to start out unstructured, and then when the need arises, combine unstructured and structured data using the same database engine and within an ACID-compliant environment.

The code shows Postgres has the capability, and now our performance comparisons demonstrate Postgres can handle the loads.

By Marc Linster is Senior Vice President, Products and Services, at EnterpriseDB.

Quarta puntata - Bitmap Indexes

2014-02-25T10:55:00.000+01:00

Riprendiamo in questo post il racconto delle scelte effettuate in un nostro progetto reale per gestire grosse moli di dati. Dopo aver parlato del partitioning, affrontiamo qua il tema dei bitmap indexes, partendo da un’introduzione generale per poi vedere l’applicazione al nostro caso.

Gli indici bitmap in generale

Gli indici bitmap sono uno strumento che chi si occupa di VLDB, ed in generale di datawarehouse, non può di certo ignorare. L’utilizzo degli indici bitmap, specie se usati in combinazione tra di loro, può aumentare notevolmente le performance nelle query di select con filtri.

Ma cosa sono gli indici bitmap?

Gli indici normalmente utilizzati, e che vengono creati con la normale DDL “create index…” sono di tipo b-tree, ossia dei classici alberi di ricerca ben conosciuti da chiunque abbia studiato informatica.

Con un indice di tipo bitmap, invece, vengono create tante liste di bit quanti sono i possibili valori che sono assunti dal campo dell’indice. Supponiamo, ad esempio, di avere una tabella di ordini di acquisti e un campo con lo stato dell’ordine, che può assumere i valori APERTO, CHIUSO o DA CONFERMARE. Poniamo inoltre di avere le seguenti 5 righe.

ORDINE	STATO
1	APERTO
2	CHIUSO
3	IN ATTESA
4	APERTO
5	APERTO

Oracle creerà le seguenti tre 3 liste di bit (uno per ognuno dei possibili valori del campo) per indicare le posizioni delle righe in cui quel valore è presente:

APERTO: 1 0 0 1 1

CHIUSO: 0 1 0 0 0

IN ATTESA: 0 0 1 0 0

Queste liste vengono ovviamente modificate ad ogni insert, delete o update sulla tabella.

Da questa breve spiegazione su cosa è un indice bitmap seguono abbastanza intuitivamente le seguenti indicazioni su quandoè conveniente utilizzare un indice bitmap rispetto ad un indice b-tree. Un indice bitmap è conveniente quando:

- la tabella è molto numerosa, mentre i possibili valori assunti dalla colonna sono limitati (caso tipico, i flag sì/no). Questo perchè per ogni valore viene creata una lista.

- la tabella non ha un’alta transazionalità. Infatti la modifica delle liste bitmap è sicuramente più dispendiosa della modifica su un albero.

- più indici bitmap vengono utilizzati sulla stessa tabella (ad esempio una select con CAMPO1=’A’ and CAMPO2=’B’, dove CAMPO1 e CAMPO2 sono campi su cui sono definiti due indici bitmap). La velocità è dovuta alla possibilità di utilizzare le operazioni binarie tra le liste di bit per le operazioni di “and” e “or”.

Sono anche facilmente comprensibili anche le seguenti limitazioni:

- gli indici bitmap non possono essere definiti su un insieme di campi, ma solo un singolo campo.

- gli indici bitmap non possono essere funzionali.

- gli indici bitmap non vengono utilizzati nei filtri di tipo <,<=,>,>=,like ecc…

- gli indici bitmap su tabelle partizionate devono essere locali alla partizione.

A queste limitazioni se ne aggiunge un’altra di tipo non tecnico: è possibile utilizzare gli indici bitmap solo nella versione Enterprise di Oracle.

Come sempre rimandiamo alla documentazione ufficiale Oracle http://docs.oracle.com/cd/E18283_01/server.112/e16541/part_admin001.htm per una trattazione più completa.

Il nostro caso

Il caso concreto che stiamo raccontando in questa serie di post si prestava perfettamente all’utilizzo degli indici bitmap. Innanzitutto per la grande mole di dati. Inoltre, trattandosi di un datawarehouse, i problemi di performance non riguardavano i tempi di insert e update, quanto i tempi delle query di select generate durante il giorno dagli strumenti di analisi. Il numero di righe caricate ogni giorno, più di 400.000, certo non è esiguo, ma il caricamento avviene in un unico momento della giornata, e quindi i tempi necessari per aggiornare gli indici bitmap non rappresentano un problema.

Di seguito alcuni dei campi su cui abbiamo creato indici bitmap locali:

- rete vendita (3 valori possibili)

- causale di vendita (13 valori)

- azienda (5 valori)

- reparto (29 valori)

- categoria merceologica (1400 valori).

In effetti, se si esclude un indice b-tree sul campo con la data di caricamento, tutti gli indici della tabella in questione sono di tipo bitmap.

Le performance, utilizzando gli indici bitmap, sono decisamente ottime e, insieme al partizionamento, portano, ad esempio la seguente query:

select sum(VALCOSTOVENDUTO) from F_VENDITE

where ANNO='2013' and MESE='12' and RETEVENDCOD=555 and ECR2CANALECOD='022' and CAUSALESTATCOD='RW'

a rispondere in circa 0,6 secondi.

Non male, per una tabella di circa 500 milioni di righe.

Prossima puntata

Nella prossima puntata parleremo di indici viste materializzate.

Ciao
Paolo

Terza puntata - Partitioning

2014-02-11T11:00:00.000+01:00

Spiegate nella scorsa puntata le scelte riguardanti la modellazione della fact principale e l’ETL, parliamo questa settimana di uno degli strumenti principali che è bene utilizzare (quando il licensing Oracle lo permette) per gestire tabelle con grandi moli di dati.

Il partitioning in generale

Come ben noto, partizionare una tabella è una delle tecniche fondamentali nei VLDB. Il riferimento fatto sopra al licensing è dovuto al fatto che la possibilità di utilizzare il partitioning si ha solo con la versione Enterprise di Oracle e l’aggiunta dello opzione chiamata appunto “Partitioning”.

Da un punto di vista fisico, al posto di un unico segmento in cui vengono immagazzinati i record di una tabella, vengono creati segmenti distinti per ogni partizione (o sottopartizione nel caso di doppio livello di partitioning). Questo spesso permette all’ottimizzatore di Oracle, in modo totalmente trasparente per la sintassi lato utente, di andare a cercare i dati di interesse direttamente nel segmento che li contiene, piuttosto che eseguire un full scan su una tabella (e quindi un segmento) enormi. Permette anche all’ottimizzatore di parallelizzare in modo migliore le query, anche nel caso di full scan.

Anche gli indici possono essere partizionati o sotto-partizionati, ed è di solito conveniente utilizzare indici partizionati su tabelle partizionate. Il principio dal punto di vista fisico è sempre lo stesso delle tabelle, ossia avere tanti segmenti invece che un unico grande segmento unico. Un indice su una tabella partizionata può essere partizionato “localmente”, ossia seguire la stessa logica di partizionamento della tabella, oppure essere partizonato “globalmente”, cioè avere una logica di partizionamento indipendente.

Come vedremo in una delle prossime puntate, oltre che per le performance, la scelta del partitioning presenta notevoli vantaggi dal punto di vista della gestione di tabelle e indici. E’ possibile infatti eseguire alcune operazioni di tipo DDL su una singola partizione o sottopartizione) invece che sull’intera tabella o indice. Truncate, move, rebuild, drop sono solo alcuni esempi di queste operazioni.

Come sempre rimandiamo alla documentazione ufficiale Oracle http://docs.oracle.com/cd/E18283_01/server.112/e16541/part_admin001.htm

per una trattazione completa del tema del partitioning, e passiamo alle scelte nel nostro caso concreto.

Il nostro caso

Avendo a disposizione la versione Enterprise o l’opzione Partitioning, la scelta di utilizzare il partitioning per la nostra tabella F_VENDITE è stata abbastanza scontata. Così come è stato abbastanza semplice scegliere i cui campi su cui effettuare il primo livello di partizionamento. E’ risultato evidente che la principale dimensione su cui sarebbero state effettuate le analisi sarebbe stata quella del tempo. Ossia i dati sarebbero stati sicuramente filtrati da una certa data in poi e raggruppati su un periodo temporale, o si sarebbero effettuati confronti mese su mese o anno su anno. Abbiamo quindi partizionato by range sulla coppia di colonne ANNO e MESE.

La scelta di partizionare su ANNO e MESE avrebbe permesso inoltre (e lo vedremo in seguito) di trattare in modo diverso dati storici ormai non più movimentati e dati recenti ancora soggetti a modifiche.

Più complicata è stata la scelta del secondo livello di partizione. Diversi campi, infatti, erano buoni candidati per la scelta. Non avendo ancora un quadro completo delle analisi che sarebbero state effettuate, non è emersa una dimensione che sarebbe stata sempre utilizzata da tutti i report. Si è scelto comunque di sotto-partizionare by hash sulla dimensione del punto vendita, ma si sarebbe potuto fare probabilmente anche su altri campi, ad esempio rete di vendita o insegna.

Per quanto riguarda gli indici abbiamo creato tutti indici partizionati localmente, ossia con le stesse partizioni e sottopartizioni della tabella.

La sintassi

Di seguito riportiamo una parte della sintassi utilizzata per creare la tabella F_VENDITE e un indice.

CREATE TABLE "F_VENDITE"

(

"AZIENDACOD" VARCHAR2(3 CHAR),

"RETEVENDCOD" VARCHAR2(3 CHAR),

"ANNO" VARCHAR2(4 CHAR),

"MESE" VARCHAR2(2 CHAR),

"DATA" VARCHAR2(10 CHAR),

"PTOCONSEGNACOD" VARCHAR2(6 CHAR),

"ARTICOLO_SK" NUMBER(*,0),

"ARTICOLOCOD" VARCHAR2(9 CHAR),

"ARTICOLOVARCOD" VARCHAR2(3 CHAR),

"FORNITOREULTIMOCARICO_SK" NUMBER(*,0),

"FORNITOREULTIMOCARICOCOD" VARCHAR2(7 CHAR),

"FORNITOREULTIMOCARICOVARCOD" VARCHAR2(3 CHAR),

..... altri campi

)

PARTITION BY RANGE

(

"ANNO",

"MESE"

)

SUBPARTITION BY HASH

(

"PTOCONSEGNACOD"

)

SUBPARTITION TEMPLATE

(

SUBPARTITION "SP1",

SUBPARTITION "SP2",

SUBPARTITION "SP3",

SUBPARTITION "SP4"

)

(

PARTITION "FACTVENDITE_201101" VALUES LESS THAN ('2011', '02') ,

PARTITION "FACTVENDITE_201102" VALUES LESS THAN ('2011', '03') ,

PARTITION "FACTVENDITE_201103" VALUES LESS THAN ('2011', '04') ,

PARTITION "FACTVENDITE_201104" VALUES LESS THAN ('2011', '05') ,

PARTITION "FACTVENDITE_201105" VALUES LESS THAN ('2011', '06') ,

….... altre partizioni

PARTITION "FACTVENDITE_FUTURE" VALUES LESS THAN (MAXVALUE, '01')

)

PARALLEL 4 ;

create index F_VENDITE_IDX01 on F_VENDITE (DATA) local;

Prossima puntata

Nella prossima puntata parleremo di indici bitmap.

Ciao Paolo

Funzione SQL OVER PARTITION

2014-01-21T11:00:00.001+01:00

Spesso abbiamo il problema di eliminare dei "duplicati" su delle tabelle di database, o di raggruppare i dati secondo uno schema predeterminato e non c'è la possibilità di usare strumenti evoluti di Business Intelligence come QlikView.

Allora per MsSql Server ci può venire in aiuto la funzione OVER.
OVER (
       [ <PARTITION BY clause> ]
       [ <ORDER BY clause> ]
       [ <ROW or RANGE clause> ]
      )

Questa funzione permette di partizionare ed eventualmente ordinare un set di righe prima dell'applicazione di una funzione. In altre parole, la clausola OVER definisce una finestra o un set di righe specificato dall'utente all'interno di un set di risultati della query.
Successivamente una funzione calcola un valore per ogni riga del set. È possibile utilizzare la clausola OVER con le funzioni per calcolare i valori aggregati, ad esempio medie, aggregazioni cumulative, totali parziali o i primi N risultati per gruppo.

Le funzioni che si possono utilizzare sono ad esempio

Funzioni di rango( ad esempio Rank, Row_number..)
Funzioni di aggregazione (AVG,MIN, MAX, SUM, COUNT...)

La clausola
PARTITION BY
    Suddivide il set di risultati della query in partizioni. La funzione viene applicata a ogni singola partizione e il calcolo viene effettuato per ogni partizione.
Si deve specificare la colonna (o più colonne) secondo la quale il risultato della query viene partizionato. Ovviamente deve essere una (o più) colonne estratte dalla query.

ORDER BY
    E' possibile definire l'ordine logico delle righe di ogni partizione. Quindi specifica l'ordine logico secondo il quale la funzione viene eseguita.

ROWS | RANGE
   Limita ulteriormente le righe all'interno della partizione specificando i punti iniziali e finali.
La clausola ROWS limita le righe all'interno di una partizione specificando un numero fisso di righe precedenti o successive alla riga corrente.
In alternativa, la clausola RANGE limita logicamente le righe all'interno di una partizione specificando un intervallo di valori rispetto al valore nella riga corrente. Le righe sono determinate come precedenti o successive secondo la definizione data dall' ORDER BY.
Ad Esempio ROWS BETWEEN 2 PRECEDING AND CURRENT ROW significa che la finestra di righe a cui viene applicata la funzione è di tre righe, a partire dalle 2 righe precedenti fino alla riga corrente inclusa.

Esempio:
Abbiamo una tabella chiamata DatiTimbrature che indica gli accessi a un posto di lavoro, effettuati tramite tessera.
Le colonne della tabella sono Cod_tessera, Codice_Sede_Lavoro, Matricola e TimeStamp che indica l'orario di timbratura.
Se vogliamo eliminare gli accessi che sono duplicati, ovvero che sono stati registrati all'interno di 1 minuto, possiamo usare la funzione OVER raggruppando per Cod_tessera, Codice_Sede_Lavoro, Matricola e prendendo il minimo timeStamp quando ho due record che differiscono di 60 secondi.
Ecco come si scrive:

select [Cod_tessera]
      ,[Codice_Sede_Lavoro]
      ,[Matricola]
      ,max_temp as orario_entrata
       from(
             select *
                    ,(max_temp -min_temp)as delta
                    ,datediff (second,max_temp ,min_temp) as secdeltaint
                     from
                         (SELECT [Cod_tessera]
                                ,[Codice_Sede_Lavoro]
                                ,[Matricola]
                                ,[TimeStamp]
                                , min([TimeStamp]) OVER(PARTITION BY [Cod_tessera] ,[Codice_Sede_Lavoro],[Matricola] ) AS min_temp
                                , max([TimeStamp]) OVER(PARTITION BY [Cod_tessera] ,[Codice_Sede_Lavoro],[Matricola] ) AS man_temp
                                 FROM [dbo].[DatiTimbrature]
                          )as g
          )as w

where secdeltaint   between -60 and -0.1
group by
       [Cod_tessera]
      ,[Codice_Sede_Lavoro]
      ,[Matricola]
      , max_temp

ciao

Giulia

Come tenere sotto controllo il transaction log

2013-12-10T10:33:00.000+01:00

Dba e non, tutti coloro che han a che fare con qualsivoglia versione di Sql Server, si sono imbattuti nel seguente errore:

Error: 9002, Severity: 17, State: 2.

The transaction log for database 'MyDB' is full.

Per scoprire, almeno una volta tanto il motivo per cui lo spazio nel log non può essere riutilizzato, basta estrarsi la colonna log_reuse_wait_desc della tabella sys.databases.

"Ma, ma, ma ..." mormora il tecnico che ha appena ricevuto un’altra strigliata dal capo o dagli utenti… "I backup dei log sono in esecuzione, perché è il log si è riempito?"
Beh, il backup dei log mancante o fallito è solo uno dei motivi per cui un transaction log si riempie.

Altra cosa che si tenta di fare, per non avere questo sgradevole problema è mettere in db in recovery mode simple….Lasciando così gestire a Sql server i log, e non potendo così farne il backup per poterli poi shrinkare.

Ci sono diverse altre possibili cause.
Da dove cominciare?
Facciamo una query sulla tabella sys.databases nel db incriminato,   per vedere il valore della colonna log_reuse_wait_desc .
DECLARE @ DatabaseName VARCHAR (50);
SET @ DatabaseName = ' MyDB '

SELECT name, recovery_model_desc, log_reuse_wait_desc
   FROM sys.databases
   WHERE Name = @ DatabaseName

Il valore della colonna log_reuse_wait_desc mostra il motivo per cui lo spazio attualmente utilizzato dai log non può essere riutilizzato.

E' possibile ci sia più di un motivo per cui non si riesca a riutilizzare il log, ma nella tabella Sys.databases ne è visualizzato solo uno. Quindi leggendo questa tabella di sistema è possibile risolvere almeno un problema. Basterà poi lanciare un’altra query sulla stessa tabella sys.databases e controllare nuovamente se c’è un diverso motivo per il mancato riutilizzo dei log.
I valori possibili per log_reuse_wait_desc sono elencati nella documentazione on line di Microsoft Sql Server. Ma prima di arrivare a una spiegazione dei vari motivi, un breve excursus di teoria.

Architettura dei Transaction log
Il log delle transazioni è un file circolare, che è diviso internamente in un certo numero di file di log virtuale (VLF). SQL scrive le voci di log in sequenza nei VLF. Quando un VLF si riempie, SQL si muove a quello successivo. Quando raggiunge la fine del file, (in teoria) riparte da capo e iniziare a utilizzare il primo VLF (e quindi circolare).

Un VLF può trovarsi in uno dei seguenti due stati:
1. Attivo
2. Inattivo

Attivo
Un VLF attivo è quello che contiene uno o più record di log che sono necessari per il motore del database. I record di log possono contenere informazioni riguardanti operazioni attive, record di log che sono necessari per la replica o il mirroring, oppure necessari per un backup, o associate a cambiamenti che non sono ancora state scritte nel file di dati, ecc .

Inattivo
Un VLF inattivo non contiene record di log necessari per il motore di database: non ci sono transazioni attive, i record di log non sono necessari per la replica o il mirroring e tutti i cambiamenti associati a quei record di log sono stati scritti nel file di dati.

Se il database è in full o bulk-logged recovery mode questi sono i VLF di cui è stato eseguito il backup, se il database è in simple i VLF inattivi sono quelli che hanno subito checkpoint.

Riutilizzo dei log
Perché un VLF possa essere riutilizzato da SQL, ha bisogno di essere inattivo. Se tutte le VLF nel registro sono attive e SQL ha riempito quella che sta scrivendo, il transaction log crescerà o, se non può crescere, alla prima modifica dei dati verrà generato un errore 9002. (Il log delle transazioni per il database 'MyDB’ è pieno)

L'atto di segnare uno o più VLF come inattivo è generalmente chiamato troncamento del log (log truncation). Malgrado sia stato utilizzato da Microsoft questo termine, quello che succede con un truncation non è un’accorciamento…non si riduce lo spazio utilizzato, viene solo reso disponibile lo spazio per il riutilizzo . Quindi se il nostro log era già da 10 GB, dopo il troncamento, sarà ancora da 10 GB.

Cause di ritardo del troncamento dei log

Questi sono i principali motivi di mancato di riutilizzo log che si possono trovare nelle colonne log_reuse_wait e log_reuse_wait_desc della vista sys.databases.

Active transaction
Il trancaction log ovviamente è attivo se c'è una transazione aperta che sta mantenendo la VLF attivo.
Con i due comandi DBCC OPENTRAN e sys.dm_exec_sessions potremmo individuare la fonte della transazione aperta. Però questo motivo è insito nella vita del database.

DBCC OPENTRAN elenca le informazioni della più vecchia transazione aperta nel database.

Esempio:

SPID (server ID di processo): 51
UID (user ID): -1
Nome: user_transaction
LSN: (10861:3200:1)
Ora di inizio: 14 GENNAIO 2013 1:04:26:017 AM
SID: 0x0105000000000005150000002e86f8cbc457a001b905c7e95e040000
Esecuzione DBCC completata. Se DBCC stampata i messaggi di errore, contattare l'amministratore di sistema.

In questo esempio, la connessione con SPID 51 ha avuto una transazione aperta dal 01:04 del 14 gennaio. Mentre non c'è nulla che ci permetta di identificare chi gestisce tale operazione,ma la SPID può essere utilizzato insieme con alcuni dei DMV per ottenere tali informazioni.

SELECT program_name, original_login_name, st.text
from sys.dm_exec_sessions es
      INNERJOIN sys.dm_exec_connections ec
          ON es.session_id = ec.session_id
      CROSSAPPLY sys.dm_exec_sql_text (ec.most_recent_sql_handle) st
   where ec.session_id = 51

Questo dovrebbe fornirci abbastanza informazioni per prendere una decisione se killare la connessione, o attendere che finisca se è troppo importante per essere killata.

Checkpoint
Il checkpoint log reuse wait dovrebbe essere una condizione transitoria della maggior parte dei casi. E’ però più comunemente osservabile in un recovery mode simple.
SQL Server esegue automaticamente i Checkpoint a intervalli regolari per mantenere il numero di record di log di cui ha bisogno per un eventuale ripristino del database. Viene eseguito il Checkpoint per una serie di altre ragioni. Per una lista completa, vedere http://msdn.microsoft.com/en-us/library/ms188748.aspx
Se il checkpoint log reuse wait appare frequentemente potrebbe indicare che ci sono problemi di i/o o che vi sono un gran numero di pagine modificate che il checkpoint deve processare.

Backup del database
La parte attiva del log è necessaria per il backup del database, dato che il backup deve includere almeno una parte di log tale a garantire un restore coerente. Come tale, un backup del database che duri a lungo può causare la crescita del transaction log, poiché aumenteranno le dimensioni del log necessarie che vengono trattenute durante tutto il tempo di esecuzione del backup. Per questo avere dei tempi di backup limitati è altamente consigliato.

Bisogna quindi ottimizzare i backup stessi (ottimizzazione del sottosistema di I / O, fare striping di backup su dispositivi multipli), o utilizzare backup compresso sia in modo nativo (SQL 2008 Enterprise, SQL Server 2008 R2 Enterprise ed edizioni Standard) o tramite uno strumento di terze parti .

Backup dei log
I backup del log sono il modo più veloce per poter effettuare il riutilizzo dei log. Nei recovery mode full e bulk-logged , il VLF non può essere contrassegnato come inattivo fino a quando tutti i record del VLF non siano stati sottoposti a backup. Il log backup wait non apparirà mai in un db con recovery mode simple .
Se vedete questo motivo nella tabella XXX, verificate che i backup dei log siano correttamente pianificati e siano efficaci.

Una volta che abbiamo quindi capito i motivi che possono rallentare il troncamento dei log ( e li abbiamo evitati), potremmo lanciare il comando che effettivamente libera lo spazio occupato dai log inattivi:

DBCC SHRINKFILE (nome_logico_file_di_log);

Quindi c’è sempre il modo, efficace di analizzare come mai il log è attivo, renderlo inattivo e fare uno shrink dei log in modo da tenere sotto controllo quei log che arrivavano anche a 100 GB.

Ciao

Giulia

PostgreSQL maintenance release

2013-12-05T16:42:00.002+01:00

Oggi, 5 Dicembre, PostgreSQL Global Development Group ha rilasciato un fix molto importante, che richiede l'immediato update del database a tutti gli users.
In a nutshell, leggete qui sotto le tematiche interessate dall'update che Matteo, il nostro DBA Guru, ci ha sintetizzato:
"Chiunque usi la replicazione o il backup a caldo di Postgres (che implica il meccanismo di point in time recovery in caso appunto di restore e recover), deve urgentemente upgradare alle versioni ultime di fix: 9.3.2, 9.2.6, 9.1.11, 9.0.15, and 8.4.19."

> Leggi il comunicato originale
> Più informazioni sulla Replication
> Release note

A breve l'oracolo ci darà informazioni più dettagliate. Stay tuned!

Confio Ignite | Quinta puntata: Lo Scaricabarile

2013-12-03T11:00:00.000+01:00

Una delle giornate tipiche nel dipartimento IT dell’azienda medio grande: un progetto va male, tutti in crisi per il ritardo e per l'incapacità di capire l'origine della problematica. La produzione riscontra un calo – dal giorno prima ci sono strani fenomeni, mai riscontrati prima, evidente calo di produttività, management infuriato per la sospettata perdita economica. Tensione, panico, le ricerca delle problematiche si sussegue, riunioni che non portano risoluzione, verbali che inseguono il colpevole.

Hanno toccato la rete? No, è il codice! La colpa è della nuova release dell'applicativo? No, il problema sta nel database! Manca un indice? Le statistiche? Tabelle da ricostruire? No, no, è colpa dello storage – dischi non rispondono bene!

Il vero problema si perde nel caos delle informazioni puramente soggettive, mentre la sensazione di impotenza cresce sempre più. Si punta il dito, volano insulti, si arriva alle tirate di capelli senza risolvere niente. Osservando queste riunioni mi viene sempre in mente il popolarissimo gioco “Attacca la coda all’asino” dove un concorrente bendato e disorientato cerca di incollare la coda ad una sagoma di un asino, provando ad avvicinarsi il piú possibile al suo posto “naturale”. Il giocatore quasi sempre non appende la coda al posto giusto perché non puó aiutarsi esplorando la sagoma con le mani, e fa divertire chi assiste all'esilarante spettacolo.

Per non sbagliare basterebbe poter “vedere”: vale a dire, tornando al nostro contesto, poter combattere l'informazione soggettiva con i fatti, affiancare l’intuizione con indizi e prove indiscutibili.

Il database è un naturale crocevia di problematiche diverse. Un bravo DBA Senior riesce trovare le tracce giuste, interpretarle e dimostrare con prove o indizi la risoluzione problemi, che interessano sia l'hardware che il software.

Confio Ignite sostiene questi bravi DBA con un tool intuitivo e semplice, che anche un manager è in grado di leggere, contribuendo alla collaborazione tra diversi team IT e fornitori esterni, condividendo velocemente le informazioni e la vera natura tecnica dei problemi.

La collaborazione nell’azienda non è mai facile perché i vari team spesso perseguono obiettivi diversi: gli sviluppatori hanno in sè il seme del cambiamento, mentre il gruppo di assistenza alla produzione richiede stabilità. Tuttavia la possibilità di riconoscere e circoscrivere bene i problemi aiuta queste persone a concentrarsi sul caso pratico ed evitare inutili dibattiti. Confio Ignite può essere utilizzato in piena autonomia dagli sviluppatori, ingegneri QA e personale dell’IT management. I dati e i grafici sono visibili in sola lettura ma con la possibilità di piena analisi ed esplorazione. DBA mantiene il controllo al 100% ma gli sviluppatori possono controllare performance del loro codice in autonomia, gli ingegneri QA sono in grado di trovare iproblemi prima del rilascio in produzione e l'IT management riesce interpretare i fenomeni tecnici.

Un miglioramento che si traduce in una migliore erogazione dei servizi e più rapido time-to-market.

Vuoi rivedere il video del webinar che si è tenuto il 27 Novembre? Watch now!

GUARDA I QUICK VIDEOS

Performance Monitoring for Development and Operations

SCARICA IL WHITE PAPER: Five DevOps Essentials for Better DBA and Developer Collaboration
SCARICA IL CASE: Database and Application Development Best Practices

SCARICA LA FREE TRIAL!

Agnieszka

PostgreSQL RDS How To

2013-11-25T11:09:00.000+01:00

Sull’onda delle novità introdotte da AWS fra Ottobre e Novembre, un breve tutorial tutto dedicato ai DBA per usare le potenzialità di PostgreSQL RDS.

Amazon da qualche tempo offre PostgreSQL (per ora 9.3) come servizio RDS; in altre parole, il database viene offerto come servizio DBaaS, alleggerendo la gestione della base dati per la parte di backup, ripristino, HA / DR (se multi zona) e rendendo più agile l’infrastruttura.

Vedremo quindi di seguito i pochi passi necessari per lanciare una istanza PostgreSQL.
Dalla nostra console AWS, accediamo al settore, dove possiamo selezionare il lancio di un nuovo database.
Selezioniamo l’engine PostgreSQL:

Nella schermata sucessiva ci viene chiesto se si vuole un'istanza Multi Zona [Si] o single instance [No]:

A questo punto, selezioniamo il size dell’istanza (micro, large, in base alle necessità di performance); qui sarà possibile scegliere anche la dimensione, il multi AZ (HA + DR), la possibilità di minor upgrade, il sizing dell’istanza e del db, oltre che il nome utente e password. Attenzione: attualmente AWS supporta solo PostgreSQL 9.3.1.

Nella successiva finestra possiamo scegliere di creare un database (potremo farlo in seguito manualmente):

Dopo di che, potremo selezionare le finestre di backup e le finestre di manutenzione (per i minor upgrade, ad esempio)

A questo punto verrà proposto il lancio dell’istanza:

A questo punto si dovrà attendere il deploy del servizio; alla fine del processo nella schermata principale apparirà la seguente interfaccia di detail. Da notare che l’endpoint avrà il nome del database inserito:

Fatto questo, la nostra istanza verrà creata e sarà accessibile previa l’aggiunta delle regole di firewall al security group RDS.

Notiamo che i database presenti sono quelli normali a parte rdsadmin ad uso interno di Amazon:

Anche se abbiamo creato una multi istanza, non sono presenti parametri relativi allo streaming replication [max_wal_senders=0 è disabilitata la streming replication]

E’ fissato il wal_buffers a 394*8kb e il backend è in archivelog [wal_level], e si suppone che Amazon stia usando la replicazione warm standby invece della streaming replication, oppure qualcosa di similare ad una logical replication che sfrutti il log:

Notare archive_command modificato:

Collegandoci quindi con l’utente creato e relativa password, potremo verificare come è il PostgreSQL di Amazon.
Nelle prossime appuntate proveremo a mettere alla prova il PostgreSQL in salsa AWS, testandolo su problematiche di restore di database e performance.
Ne vedremo delle belle!
Ciao