Sample Page - Massimiliano Mauro

Logistica e prodotti a peso variabile

In questo articolo vedremo come gestire il ricevimento merci e il picking con i prodotti a peso variabile.

Il codice a peso variabile identifica quei prodotti per i quali la confezione non ha un peso predeterminato e costante ed il cui prezzo di vendita unitario varia in funzione del peso finale.

La bilancia prezzatrice genera Il codice relativo alla referenza completato con l’informazione:

Prezzo di vendita, se il canale di commercializzazione è la GDO (Grande Distribuzione Organizzata)
Peso, se il canale di commercializzazione è il Cash & Carry

Al codice della referenza ricevuto GS1 Italy si aggiungono le cinque cifre per il prezzo (oppure il peso per il canale Cash & Carry) e si calcola la cifra di controllo. Naturalmente le regole GS1 devono essere sempre rispettate.

Il codice di 13 caratteri (chiamato GTIN-13) avrà la seguente struttura numerica:

Come sappiamo Business Cube ha la gestione, oltre ai barcode EAN 8, EAN 13 ecc, gestisce anche gli EAN 128 SSCC (GS1-128). La funzionalità è abilitata in automatico nella gestione documenti, e funziona ‘sparando’ il barcode nel campo codice articolo della griglia del corpo del documento. Nel codice a barre EAN128 il codice è una normale sequenza di caratteri, dove alcuni sono degli identificativi di campo, altri il valore.

Al momento Business traduce il barcode EAN128 letto tramite i marcatori (AI); i marcatori letti da Business sono solo:

00 o 01: Business cerca un barcode con codice uguale a quello che segue il marcatore, qualora in Business non esista tale codice non sarà possibile determinare il cod. articolo, quindi verrà dato il messaggio di articolo inesistente
10: lotto alfanumerico (si consiglia di impostare in Business, nell’anagrafica ditta, la gestione dei lotti alfanumerici)
11: data produzione lotto
17: data scadenza lotto
21: matricola (in Business la matricola avrà sempre quantità proposta = 1)
242: commessa, il marcatore ha lunghezza massima di 6 caratteri, quindi non sarà possibile riconoscere commesse con lunghezza maggiore.
310x: Peso netto in chilogrammi, la x indica il numero di decimali e assume un valore tra 0 e 6. Il valore letto è sempre valutato come quantità
311x: Lunghezza, la x indica il numero di decimali e assume un valore tra 0 e 6. Il valore letto è sempre valutato come quantità
314x: Superficie, la x indica il numero di decimali e assume un valore tra 0 e 6. Il valore letto è sempre valutato come quantità
316x: Volume, la x indica il numero di decimali e assume un valore tra 0 e 6. Il valore letto è sempre valutato come quantità
02: Identificativo del cartone, contiene il barcode in formato GTIN indicato nell’anagrafica dell’articolo
37: Moltiplicatore della quantità indicata nel GTIN, presente solo nel caso di AI iniziale 02, il valore letto è sempre valutato come quantità. NB: se attiva l’opzione “OPZIONI\UsaDivisoreBarcodeGS1(02)” apparirà la colonna divisore nell’anagrafica barcode dell’anagrafica articoli, tale divisore sarà utilizzato per dividere le quantità specificate nell’AI 37 durante la lettura di un GS1 (EAN 128) che inizia con (02).
30: come AI 37
15: “Da consumarsi preferibilmente entro”

Per raggiungere il risultato di riconoscere il codice a peso variabile, ho modificato la sub “TrascodificaBarcodeEan128_IdentificaTipoMarcatore nella dll BNLBMENU”

Qui ho aggiunto tra i marcatori il 2 dividendo il codice letto. In questo modo ottengo in ritorno l’articolo e il peso, che sarà la quantità del documento (e delle operazioni di picking e ricevimento merci).

Nel nostro caso ogni prodotto a peso variabile parte da un peso approssimativo da cui può discostarsi in più o in meno.

Nell’esempio consideriamo un prodotto che pesa circa 2 KG. Come unità di misura principale si è utilizzato il Kg e come secondaria utilizziamo Pz indicando 0,5 il fattore di conversione, in questo modo ogni Kg e ½ Pz, cioè un Pz = 2 Kg

Al prodotto si assegna il codice a barre e gestione lotti.

Per proporre in ricevimento righe separate in caso di acquisto multiplo, nella logistica si è impostato il rapporto di conversione UDC pari al peso teorico. Questo si ottiene flaggando stampa etichette UDC in generazione

A questo punto si è generato un ordine a fornitore per 2 pezzi del nostro prodotto, utilizzando l’unità di misura secondaria e ordinando 2 pezzi

ordine fornitore prodotti a peso variabile

Come possiamo vedere, l’ordine di 2 pezzi corrisponde a 4Kg (teorici di prodotto)

All’arrivo il prodotto avrà l’etichetta seguente (per semplicità considero una sola etichetta) dove si evince che il peso effettivo è di 2,232Kg.

Dopo aver settato nel ricevimento merci le seguenti opzioni di registro, siamo passati al riscontro

Dopo aver selezionato l’ordine, abbiamo questa situazione nel ricevimento merce dove, leggendo il barcode, viene impostata la quantità riscontrata da etichetta

Avendo impostato la gestione dei lotti e impostato nel registro l’inserimento della data scadenza lotto, ad ogni lettura verrà richiesto il codice lotto, e se non è ancora anagrafato, verrà richiesta la data di scadenza. Il DDT ricevuto sarà il seguente

Errore di crittografia CredSSP

Se avete provato a connettervi a un server remoto tramite il protocollo RDP (Remote Desktop Protocol) e avete ricevuto il seguente messaggio di errore:

“Impossibile connettersi al computer remoto a causa di un errore di crittografia CredSSP (Credential Security Support Provider). Questo potrebbe essere dovuto alla configurazione del criterio di crittografia CredSSP sul server. Per ulteriori informazioni, consultare la documentazione del server o contattare l’amministratore del sistema.”

Allora siete incappati in un problema noto come “errore CredSSP Encryption Oracle Remediation”. L’errore di crittografia CredSSP si verifica quando il client e il server hanno una versione diversa del protocollo CredSSP, che è usato per autenticare le credenziali degli utenti e crittografare i dati trasmessi tra le due parti.

CredSSP è un protocollo che consente al client RDP di delegare le proprie credenziali al server remoto per eseguire operazioni che richiedono privilegi elevati, come l’installazione di software o la modifica delle impostazioni di sistema. Tuttavia, questo protocollo è vulnerabile ad un attacco di tipo “man-in-the-middle” in cui un malintenzionato può intercettare le credenziali del client e usarle per eseguire operazioni non autorizzate sul server remoto.

Il problema è stato introdotto da un aggiornamento di sicurezza di Windows rilasciato a marzo 2018, che ha modificato il comportamento di CredSSP per prevenire un tipo di attacco chiamato “oracle padding”.

Per risolvere questo errore, ci sono due possibili soluzioni:

Aggiornare il client e il server allo stesso livello di patch di sicurezza. Questa è la soluzione più consigliata, in quanto garantisce la massima protezione contro gli attacchi basati su CredSSP. Per verificare se il vostro sistema è aggiornato, potete usare lo strumento Windows Update o consultare il sito web Microsoft Update Catalog.
Modificare le impostazioni del registro di sistema del client per consentire la connessione RDP anche se il server non è aggiornato. Questa è una soluzione temporanea, che comporta un rischio di sicurezza maggiore, in quanto espone il client agli attacchi basati su CredSSP. Per applicare questa soluzione, dovete seguire questi passi:
- Aprire l’editor del registro di sistema (regedit.exe) e navigare alla chiave HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters
- Creare un nuovo valore DWORD (32 bit) chiamato AllowEncryptionOracle e impostarlo a 2
- Riavviare il computer
- Tentare nuovamente la connessione RDP al server remoto
Modificare il criterio di gruppo sul client o sul server per consentire la connessione con una versione precedente di CredSSP. Questa è una soluzione temporanea, che può esporre il sistema a rischi di sicurezza. Per modificare il criterio di gruppo, seguire questi passaggi:
- Aprire l’editor dei criteri di gruppo locale (gpedit.msc) sul client o sul server.
- Navigare fino a Configurazione computer > Modelli amministrativi > Sistema > Delega credenziali.
- Fare doppio clic sulla voce “Correzione oracolo crittografia CredSSP” e impostarla su “Abilitata”.
- Scegliere “Vulnerabile”o “Mitigato” tra le opzioni disponibili nel menu a discesa “Protezione oracolo crittografia CredSSP”. Le opzioni sono:
  - Forza aggiornamento: richiede che il server sia aggiornato alla stessa versione del client. Se il server non è aggiornato, la connessione viene rifiutata. Questa è l’opzione predefinita dopo l’aggiornamento di sicurezza.
  - Mitigato: consente la connessione con un server non aggiornato, ma solo se il client è protetto da un firewall o da un gateway RDP. Questa opzione riduce il rischio di attacco, ma non lo elimina completamente.
  - Vulnerabile: consente la connessione con qualsiasi server, indipendentemente dalla sua versione. Questa opzione espone il client a un alto rischio di attacco e dovrebbe essere usata solo in casi eccezionali.
- Fare clic su OK per salvare le modifiche.
- Riavviare il client o il server per applicare le modifiche.

Spero che questa guida vi sia stata utile per risolvere l’errore CredSSP Encryption Oracle Remediation.

Ricevimento merci, sospensione e giacenza di magazzino

Nei giorni scorsi un cliente che utilizza la logistica sul palmare, ha sottoposto la seguente problematica inerente il ricevimento merci, sospensione e giacenza di magazzino :

“In fase di ricevimento merci da ordine al fornitore, quando si sospende l’operazione di riscontro, anche se il ddt risulta sospeso sul palmare, l’ordine risulta totalmente caricato a magazzino.
Spesso, però, non tutta la merce ordinata viene spedita, e in questo caso, se l’operatore è costretto a sospendere il riscontro, tutta la merce risulta disponibile fino a quando non viene completato il riscontro e gestiti i residui. Ciò comporta notevoli difficoltà agli addetti alle vendite che più volte forniscono ai clienti informazioni errate su disponibilità e tempi di consegna”.

Nel tentativo di dare una risposta in tempi brevi, ho girato la problematica all’assistenza che mi ha così risposto:

“Salve Massimiliano, confermo che finché non viene concluso il ricevimento merce, l’ordine di partenza viene considerato evaso (in quanto il ricevimento lavora sul ddt ricevuto che viene creato), solo alla sua conclusione vengono aggiornati il ddt e la qta evasa sull’ordine. Non è presente l’aggiornamento della quantità evasa in tempo reale sull’ordine, ma si può avere una consultazione dello stato del ricevimento in monitor picking”

Per poi concludere così:

“Gentile Partner, la funzionalità da lei richiesta non è prevista dalle nostre procedure software.
Se, a suo parere, tale funzionalità riveste particolare importanza e può rappresentare un plus per il prodotto……ecc. ecc.”

Preso atto della risposta ho cercato un modo per risolvere il problema buttando giù qualche riga di codice.

Ovviamente ero convinto che non esistessero opzioni di alcun tipo per risolvere il problema.

Mentre leggevo il codice per capire dove poter intervenire, mi sono imbattuto in una funzione nella BERCRICM.

La funzione richiamava delle opzioni di registro, una che modifica il tipo b/f al momento del riscontro, e l’altra che lo reimposta alla chiusura.

Le opzioni in questione sono “TipoBfGenerazioneDDT” e “TipoBfCompletamentoDDT”

Ho pensato di creare un tipo bolla/fattura “neutro”, cioè che non facesse movimenti di magazzino, e di assegnarlo all’opzione TipoBfGenerazioneDDT, mentre all’opzione TipoBfCompletamentoDDT ho assegnato il tipo legato al carico per acquisto. A questo punto, però, mi sono chiesto: perché l’assistenza ha affermato che la funzionalità richiesta non è prevista dalle procedure software?

Così ho posto la mia attenzione sulle altre opzioni di registro ed ho trovato quest’altra “TipoBfCompletamentoRipristinaOrdine”. Questa opzione l’ho utilizzata al posto della “TipoBfCompletamentoDDT” in modo da ripristinare il tipo bolla fattura originale presente sull’ordine.

Ricevimento merci opzioni registro BSRMRICM

Assegnate le opzioni, ho cominciato a testare la procedura e sembrava andare tutto alla perfezione.

Al momento di iniziare il riscontro, si è generato un ddt con tipo b/f neutra.
Nel momento in cui il riscontro si completava, il tipo b/f assumeva il valore assegnato all’ordine fornitore.

Il problema è sorto quando si è creato un ordine che prevedeva il reverse charge.

In quel caso il tipo b/f doveva essere di tipo reverse ma impostandolo in quel modo o come misto, quando l’acquisto era normale si aveva il massaggio bloccante dell’assenza di righe con iva in reverse.

A quel punto ho supposto che la risposta dell’assistenza avesse tenuto conto di questa situazione.

Continuavo però a non capire la presenza delle altre opzioni.

Rimettendo mano al codice è stata analizzata la dll BNMGDOCU, cercando il punto in cui il controllo delle righe in reverse veniva fatto per poterlo bypassare.

Il controllo è all’interno della funzione “TestPreSalvaSTD” dove, con mio stupore, ho scoperto che il controllo è sottoposto ad una opzione in BNVEBOLL, non presente nell’elenco delle opzioni.

L’opzione in questione è “NoMsgAssenzaCodiciIvaReverseCharge”, che impostata a -1 salta il controllo della presenza delle righe in reverse

Ricevimento merci opzioni registro BNVEBOLL

In questo modo, senza intervenire sul codice, ma utilizzando solo le opzioni esistenti, si è messo in condizione il cliente di lavorare senza problemi in quanto se il fornitore è in reverse, questo è dichiarato già dall’ordine, senza correre il rischio di generare buchi nella numerazione del registro iva.

Rimappare unità rete al riavvio di SQL Server

La volta precedente abbiamo visto come mappare un’unità di rete in Sql Server in modo da poter effettuare backup o posizionare i database in unità di rete. Ora vedremo come fare per rimappare le unità di rete al riavvio di SQL Server

Questa operazione può essere utile se hai dei database o dei file di backup su unità di rete e vuoi assicurarti che siano sempre accessibili dopo un riavvio del server.

Una stored procedure è un gruppo di istruzioni SQL che viene compilato una volta e può essere eseguito più volte. Le stored procedure possono accettare dei parametri di input e restituire dei valori di output. Le stored procedure possono anche essere impostate per l’esecuzione automatica all’avvio di un’istanza di SQL Server, usando l’opzione sp_procoption.

Per creare una stored procedure per rimappare le unità di rete al riavvio di SQL Server, segui questi passi:

Apri SQL Server Management Studio e connettiti al server dove vuoi creare la stored procedure
Espandi il nodo Programmabilità e fai clic con il pulsante destro del mouse su Stored Procedure. Seleziona Nuova stored procedure dal menu contestuale

Nella finestra di query, sostituisci il testo predefinito con il seguente codice:
- CREATE PROCEDURE sp_RemapNetworkDrives
  AS
  BEGIN
  — Rimuove le eventuali unità di rete già mappate
  EXEC xp_cmdshell ‘net use * /delete /y’
  — Mappa le unità di rete desiderate con i percorsi e le credenziali corrette
  EXEC xp_cmdshell ‘net use Z: \\ServerName\ShareName /user:DomainName\UserName Password’
  — Ripete il passo precedente per ogni unità di rete da mappare
  END
Modifica il codice sostituendo i nomi delle unità, i percorsi e le credenziali con quelli effettivi che vuoi usare
Esegui il codice premendo F5 o facendo clic sul pulsante Esegui nella barra degli strumenti. Dovresti vedere un messaggio che conferma la creazione della stored procedure
Per impostare la stored procedure per l’esecuzione automatica all’avvio di SQL Server, esegui il seguente codice:
- EXEC sp_procoption ‘sp_RemapNetworkDrives’, ‘startup’, ‘on’
Per verificare che la stored procedure funzioni correttamente, riavvia il server e controlla che le unità di rete siano mappate correttamente.

Come mappare unità di rete su SQL Server

Mappare un’unità di rete su SQL Server è un’operazione utile per accedere a file o cartelle condivise da altri computer o server nella stessa rete. In questo modo si può sfruttare la potenza e la flessibilità di SQL Server per gestire e manipolare i dati presenti in queste risorse esterne. In altre parole avremmo la possibilità di posizionare i file del database su unità di rete (ad esempio un NAS)

Per mappare un’unità di rete su SQL Server, ci sono due metodi principali: usare il comando xp_cmdshell o creare una stored procedure con il codice Transact-SQL appropriato.

Metodo 1: usare il comando xp_cmdshell

Il comando xp_cmdshell è una funzione integrata di SQL Server che consente di eseguire comandi del sistema operativo direttamente da una query SQL, tuttavia, per usare questo comando, bisogna avere i permessi necessari e abilitare l’opzione xp_cmdshell nella configurazione di SQL Server.

Per abilitare l’opzione xp_cmdshell, si può usare il seguente codice:

EXEC sp_configure ‘show advanced options’, 1
RECONFIGURE
EXEC sp_configure ‘xp_cmdshell’, 1
RECONFIGURE

Dopo l’esecuzione del comando si dovrebbe ottnere un messaggio simile a questo:

L’impostazione 0 dell’opzione di configurazione ‘show advanced options’ è stata sostituita con 1. Per eseguire l’installazione, utilizzare RECONFIGURE.
L’impostazione 0 dell’opzione di configurazione ‘xp_cmdshell’ è stata sostituita con 1. Per eseguire l’installazione, utilizzare RECONFIGURE.

mappare unità di rete su SQL Server con comando xp_cmdshell

Una volta abilitata l’opzione xp_cmdshell, si può usare il comando NET USE per mappare un’unità di rete su SQL Server. Il comando NET USE ha la seguente sintassi:

NET USE [driveletter:] [\\computername\sharename] [password | *] [/USER:[domainname\]username] [/PERSISTENT:{YES | NO}]
Dove:

– driveletter: è la lettera dell’unità di rete da creare (ad esempio Z:)
– computername: è il nome del computer o del server che condivide la risorsa (ad esempio SERVER01)
– sharename: è il nome della risorsa condivisa (ad esempio una cartella)
– password: è la password per accedere alla risorsa condivisa (se richiesta)
– /USER: è il nome utente per accedere alla risorsa condivisa (se richiesto)
– /PERSISTENT: è l’opzione per rendere permanente o meno la mappatura dell’unità di rete

Per esempio, per mappare un’unità di rete Z: che punta alla cartella condivisa \\SERVER01\DATA, si può usare il seguente codice:

EXEC xp_cmdshell ‘NET USE Z: \\SERVER01\DATA’

Se la mappatura ha avuto successo, si dovrebbe ottenere un messaggio simile a questo:

The command completed successfully.

Se invece si verifica un errore, si dovrebbe ottenere un messaggio simile a questo:

System error 53 has occurred.
The network path was not found.

In questo caso, bisogna verificare che il nome del computer o del server sia corretto, e che la risorsa condivisa sia accessibile e che le credenziali fornite siano valide.

Per verificare che l’unità di rete sia stata mappata correttamente, si può usare il comando DIR per elencare i file e le cartelle presenti nell’unità di rete, per esempio

EXEC xp_cmdshell ‘DIR Z:’

In conclusione, se l’unità di rete è stata mappata correttamente, si dovrebbe ottenere un output simile a questo:

Volume in drive Z is DATA
Volume Serial Number is 1234-5678

Directory of Z:\

01/01/2020 12:00 <DIR> .
01/01/2020 12:00 <DIR> ..

La prossima volta vi mostrerò come mappare le unità di rete tramite una stored procedure, dopodiché come fare per rimapparle auomaticamente al riavvio di SQL Server

Integrazione Business CUBE – BRT

Dopo aver visto come inserire le immagini nella griglia ordini della desktop consolle, in questo video vi mostro l’integrazione tra Business Cube e lo spedizioniere BRT mediante l’utilizzo dello loro Rest Api per l’invio ai loro server dell spedizioni da ritirare per la consegna con generazione dell’etichetta per la spedizione riportante i dati del destinatario ed i riferimenti dell’ordine.

Immagini nella consolle Ordini

In questo articolo vedremo come inserire delle immagini nella griglia ordini della desktop consolle di Business Cube. In questo caso particolare gli ordini provengono da un’importazione da una piattaforma e-commerce e le immagini vengono prelevate direttamente dal sito tramite l’url dell’immagine stessa.

La prima operazione è stata quella di aggiungere il campo testo mo_hhimg alla tabella movord. In questo memorizzeremo il link al file proveniente dalla procedura di importazione. (Non stò a dilungarmi sulla procedura di import dal sito poichè si tratta di un sito costruito ad hoc. In pratica c’è un oggetto WebClient che richiama i dati da un link del sito che restituisce un elenco di ordini)

Dopo aver ereditato la DLL BNDKKONS, tramite le funzioni di editing aggiungiamo la colonna di griglia tipo text agganciandola alla colonna xx_hhimg.

Nell’ovveride della funzione Apri all’interno della BFDKKONS aggiungiamo la colonna xx_hhimg insieme all’aggiunta dell’Handler sulla ColumnChanged per caricare le immagini su ogni riga della griglia ordini della consolle.

Nella funzione inseriamo il ridemensionamento dell’immagine impostando una larghezza massima di 120px facendo in modo di mantere le proporzioni.

In questa verticalizzazione è stata inoltre effettuata un’integrazione con il corriere BRT per la stampe delle etichette di spedizione alla creazione del documento di vendita generato dall’evasione dell’ordine.

Database in modalità Restoring

Cosa fare quando il database è in modalità RESTORING?

Durante il ripristino di un backup di un database SQL Server, probabilmente vi è capitato che il questo rimanesse in modalità RESTORING.

Questa modalità indica che il database è in fase di ripristino da un backup o da una serie di backup. Questa fase può durare da pochi minuti a diverse ore a seconda della dimensione del database, del numero e del tipo di backup da applicare, e delle prestazioni del sistema.

In questa modalità il database non è accessibile e non è possibile eseguire altre operazioni di backup o ripristino sullo stesso database.

Perché il database è in modalità RESTORING?

Quando si ripristina un backup completo del database, il processo di ripristino copia i dati dal backup al database e applica le transazioni registrate nel log delle transazioni. Questo garantisce che il database sia consistente e rifletta lo stato al momento del backup.

Tuttavia, se si vuole ripristinare anche uno o più backup differenziali o del log delle transazioni, è necessario specificare l’opzione WITH NORECOVERY nel comando RESTORE DATABASE. Questa opzione impedisce al processo di ripristino di terminare e di rendere il database accessibile. In questo modo, si può applicare il backup successivo nella sequenza senza perdere le modifiche registrate nel log delle transazioni.

Database in modalità Restoring -RESTORE DATABASE WITH RECOVERY

Quando si applica l’ultimo backup della sequenza, si deve specificare l’opzione WITH RECOVERY nel comando RESTORE DATABASE. Questa opzione segnala al processo di ripristino di terminare e di rendere il database accessibile. Se non si specifica questa opzione, il database rimane in modalità RESTORING finché non si esegue manualmente il comando RESTORE DATABASE WITH RECOVERY.

Come uscire dalla modalità RESTORING?

Se il database è in modalità RESTORING perché si sta applicando una sequenza di backup, basta eseguire il comando RESTORE DATABASE WITH RECOVERY sull’ultimo backup della sequenza per uscire dalla modalità RESTORING e rendere il database accessibile.

Se invece il database è in modalità RESTORING perché si è interrotto il processo di ripristino o perché si è verificato un errore, si possono seguire due strade:

Riprendere il processo di ripristino applicando il backup successivo nella sequenza con l’opzione WITH NORECOVERY, fino a raggiungere l’ultimo backup con l’opzione WITH RECOVERY.
Annullare il processo di ripristino eseguendo il comando RESTORE DATABASE WITH RECOVERY. Questa operazione riporta il database allo stato precedente al ripristino, ma può causare la perdita dei dati modificati dopo l’ultimo backup.

In conclusione, la modalità RESTORING indica che il database è in fase di ripristino da uno o più backup. Per uscire da questa modalità e rendere il database accessibile, è necessario specificare l’opzione WITH RECOVERY nell’ultimo comando RESTORE DATABASE della sequenza. Se invece si vuole annullare il processo di ripristino, si può eseguire lo stesso comando senza specificare alcun backup.

Database in stato di Recovery

Se avete mai lavorato con SQL Server, probabilmente vi siete imbattuti in una situazione in cui un database ha lo stato RECOVERING. Questo significa che il database è in fase di ripristino dopo un’operazione di backup, restore, failover o altro evento che richiede la ricostruzione dei dati. In questo post, vedremo cosa succede durante il processo di ripristino, come verificare lo stato di un database e come risolvere eventuali problemi.

Il processo di ripristino

Quando un database SQL Server ha lo stato RECOVERING, significa che il motore di database sta eseguendo una serie di passaggi per riportare il database in uno stato consistente e pronto per l’uso. Questi passaggi sono:

Analysis: il database ha completato le transazioni e le ha analizzate nel log del motore di database per determinare quali erano valide e quali no. Questo passaggio serve a preparare i passaggi successivi e a stimare il tempo necessario per il ripristino.
Redo: il motore di database applica le modifiche al database che sono state registrate nel log delle transazioni ma non ancora scritte sul disco. Questo passaggio serve a ripristinare il database allo stato in cui si trovava prima dell’evento che ha causato il ripristino.
Undo: il motore di database annulla le modifiche al database che sono state registrate nel log delle transazioni ma non ancora confermate. Questo passaggio serve a eliminare le transazioni incomplete o non valide che potrebbero compromettere l’integrità del database.

Durante il processo di ripristino, il database non è accessibile agli utenti o alle applicazioni. Il tempo necessario per il ripristino dipende da diversi fattori, come la dimensione del log delle transazioni, il numero e la complessità delle transazioni da ripetere o annullare, le prestazioni del sistema e altri eventi concorrenti.

Tuttavia, in alcuni casi, il database può rimanere bloccato nello stato RECOVERING per un tempo eccessivo o indefinito, impedendo l’accesso ai dati. Questo può accadere per vari motivi, come ad esempio:

Il backup è incompatibile con la versione del server SQL Server.
Il backup è corrotto o incompleto.
Il database ha subito un arresto anomalo o una perdita di energia durante il ripristino.
Altri database hanno delle dipendenze sul database che non hanno ripristinato.
Il database ha delle opzioni di configurazione che impediscono il ripristino completo.

Per risolvere questi problemi, si possono provare le seguenti soluzioni:

Verificare la compatibilità del backup con la versione del server SQL Server e usare un backup adeguato o un server diverso.
Verificare l’integrità del backup e ripetere l’operazione di ripristino con un backup valido.
Interrompere e riavviare il servizio SQL Server per forzare il ripristino del database.
Eliminare il database con problemi e ripristinarlo nuovamente.
Ripristinare tutti i database correlati al database con problemi, mantenendo la stessa sequenza temporale dei backup.
Modificare le opzioni di configurazione del database, come ad esempio il recovery model o l’opzione RESTRICTED_USER, per consentire il ripristino completo.

Queste sono alcune delle possibili soluzioni per risolvere i problemi se un database SQL Server ha lo stato RECOVERING. Si consiglia di eseguire sempre un backup dei dati prima di effettuare qualsiasi operazione di ripristino e di consultare la documentazione ufficiale di SQL Server per maggiori dettagli e istruzioni.

Database in modalità Emergency

Se il vostro database SQL Server è danneggiato o non avviabile, potete provare a ripristinarlo usando la modalità EMERGENZA. Questa modalità consente di accedere al database anche se è in uno stato inconsistente, e di eseguire operazioni di riparazione o di recupero dei dati.

La modalità EMERGENZA si attiva impostando lo stato del database a 1 con il comando ALTER DATABASE. Ad esempio:

ALTER DATABASE MioDatabase SET EMERGENCY;

Una volta attivata la modalità EMERGENZA, il database diventa accessibile solo ai membri del ruolo sysadmin. Inoltre, il database viene aperto in sola lettura e non viene eseguita alcuna operazione di rollback o di recupero.

Per ripristinare il database, è necessario eseguire i seguenti passi:

1) Verificare l’integrità fisica del file di dati e del file di log del database con il comando DBCC CHECKDB. Questo comando restituisce un report con gli eventuali errori rilevati e le possibili azioni di riparazione. Ad esempio:

DBCC CHECKDB (MioDatabase) WITH NO_INFOMSGS, ALL_ERRORMSGS;

SQL Server in modalità EMERGENZA- DBCC CHECKDB

2) Se il comando DBCC CHECKDB non restituisce errori, significa che il database è integro e può essere riportato in modalità normale con il comando ALTER DATABASE. Ad esempio:

ALTER DATABASE MioDatabase SET ONLINE;

SQL Server in modalità EMERGENZA- SET ONLINE

3) Se invece il comando DBCC CHECKDB restituisce errori, significa che il database è danneggiato e richiede una riparazione. La riparazione può essere eseguita con il comando DBCC CHECKDB con l’opzione REPAIR_ALLOW_DATA_LOSS. Questa opzione consente di eliminare le pagine o le righe corrotte dal database, ma comporta una perdita di dati. Ad esempio:

DBCC CHECKDB (‘MioDatabase’, REPAIR_ALLOW_DATA_LOSS);

4) Dopo aver eseguito la riparazione, è necessario verificare nuovamente l’integrità del database con il comando DBCC CHECKDB. Se il comando non restituisce errori, significa che la riparazione è stata effettuata con successo e il database può essere riportato in modalità normale con il comando ALTER DATABASE. Ad esempio:

ALTER DATABASE MioDatabase SET ONLINE;

5) Se invece il comando DBCC CHECKDB restituisce ancora errori, significa che la riparazione non è stata sufficiente e il database è irrecuperabile. In questo caso, l’unica soluzione è ripristinare il database da un backup valido.

La modalità EMERGENZA è un’ultima risorsa per tentare di recuperare un database SQL Server danneggiato. Si raccomanda di usarla solo dopo aver esaurito tutte le altre opzioni e di essere consapevoli dei rischi di perdita di dati. Inoltre, si raccomanda di effettuare sempre dei backup regolari del database e di verificarne la validità.