Dimensione massima dei database del contenuto di SharePoint

Un'altra domanda è quella di parlare con i guru di SharePoint durante l'insegnamento di MCM ieri. Le linee guida di SharePoint prevedono che i database del contenuto superiori a 100 GB non siano supportati. Senza entrare nei motivi alla base di tali linee guida, sono interessato a conoscere i database dei contenuti di dimensioni superiori a 100 GB e le tue esperienze con essi (principalmente in merito a prestazioni, ripristino di emergenza e provisioning di HA).

Fino a che punto sei riuscito a spingere la tua installazione di SharePoint? Ho ascoltato storie di seconda mano su database di contenuto da 1 TB, ma mi piacerebbe conoscere gli stessi amministratori di SharePoint.

Grazie per qualsiasi informazione tu abbia.

Abbiamo un DB a 111 e 102 GB, rispettivamente, che viene eseguito il backup in meno di 30 minuti su una rete GigE. Ho sentito che database più grandi possono avere problemi con le stored procedure di lunga durata, ma non ne ho visto alcuna dimostrazione.

Una bella citazione dal white paper "Scaling SharePoint 2007: Storage Architecture":

"... Questo è comunemente indicato come" limitazione delle dimensioni del database del contenuto da 100 GB ". In realtà, questa non è una vera limitazione ma piuttosto una raccomandazione. I database di SQL Server hanno ridimensionato molto oltre i 100 GB da anni ormai. In pratica, il la raccomandazione si basa principalmente su due fattori significativi:

1. I requisiti del contratto di servizio (SLA) per una determinata organizzazione possono imporre che le operazioni di backup per i database di SharePoint debbano essere eseguibili in un periodo di tempo limitato. La dimensione dei database del contenuto avrà un impatto diretto sul tempo necessario per eseguire quel backup.

2. Il sottosistema di archiviazione deve essere sufficientemente robusto per gestire i requisiti di I / O del disco della soluzione SharePoint che serve.

Finché una determinata organizzazione è in grado di mitigare queste due considerazioni, è possibile consentire ai database del contenuto di crescere. Le implementazioni del mondo reale hanno visto implementazioni di successo di SharePoint che hanno implementato dimensioni del database di 100 GB, 150 GB, 200 GB, 250 GB, 300 GB, 350 GB e 400 GB. "

Per l'uso quotidiano, la dimensione del database non è così importante: la maggior parte delle query restituisce gli elementi in un elenco e non importa cos'altro c'è nel database. Tuttavia, le operazioni che funzionano sull'intero database diventeranno più difficili. I backup sono l'esempio più ovvio: impiegheranno più tempo con database di grandi dimensioni. Tuttavia, fintanto che il database non supera ciò di cui è possibile eseguire il backup durante la notte, andrà bene - i backup sono progettati per funzionare a lungo e sono abbastanza affidabili fino a quando non si esaurisce lo spazio su disco.

Il punto in cui ti imbatterai in problemi reali è con cose meno frequenti come lo spostamento o l'aggiornamento dei database del contenuto: questi possono richiedere circa 5 volte la dimensione del database nello spazio libero e vengono implementati usando query che possono fare cose come l'attivazione automatica del controllo.

Abbiamo un database di contenuti con dimensioni di 300 GB. Nessun problema con i backup dopo il passaggio a Lite Speed. Prima del passaggio vedremmo un grave peggioramento delle prestazioni con i siti web.

Per la cronaca NON volevamo avere un Content DB così grande. Avevamo requisiti aziendali specifici per la condivisione dei contenuti che sarebbe stato molto difficile da implementare se avessimo messo i contenuti in raccolte siti separate.

Quando siamo entrati in funzione per la prima volta, abbiamo riscontrato importanti problemi di blocco del database durante l'utilizzo di punta. Abbiamo rintracciato questo per usare l'oggetto CrossListQueryCache in SharePoint. Siamo passati dall'uso di quell'API e ha risolto molte delle nostre prestazioni.

Ho scritto un piccolo articolo sul blog con maggiori informazioni qui .

Riscontriamo ancora problemi di blocco con determinati tipi di aggiornamenti (eliminazione di BLOB> 20 MB), rinominazione di Web (ciò può causare aggiornamenti a molti record nella tabella AllUserData. Stiamo collaborando con il Supporto MS su casi specifici (ad esempio rimuovendo oggetti di grandi dimensioni dal cestino) Questi sono stati ricondotti al modo in cui specifiche procedure memorizzate in SharePoint stanno eliminando i dati, ma non abbiamo ancora una soluzione.

Personalmente penso che i problemi si verifichino dopo aver ottenuto così tanti record nella tabella AllUserData e il modo più semplice per MS di comunicare questo alle persone è stato quello di rimanere sotto i 100 GB.

Suggerisco di fare il ping alle persone di MS IT ... Ho sentito dire che hanno un database del contenuto di SharePoint> 800 GB.

La nostra azienda ha attualmente un database a 140 Mb. Stiamo riscontrando prestazioni lente in un particolare elenco a cui è stato consentito di aumentare a 1,5 GB che contiene allegati, tra cui più versioni di allegati. (Sono stato lì solo circa 2 mesi tra l'altro). Ora stiamo pianificando una migrazione e sembra che migrare su SP 2010 usando lo strumento Metalogix potrebbe richiedere giorni in base ai nostri test. Il nostro è un database mal progettato, un portale mal progettato che ora ha chi deve gestirlo con problemi reali.

Abbiamo un sito di backup che utilizziamo che è una copia esatta del nostro ambiente di produzione. Ma l'hardware è il nostro vecchio hardware dopo il nostro ultimo aggiornamento hardware: vecchio hardware per lo sviluppo, nuovo per la produzione. Alcune aree del nostro ambiente di sviluppo sono tuttavia inutilizzabili a causa di problemi di prestazioni che costringono alcuni sviluppi in elenchi di grandi dimensioni a essere eseguiti in produzione. Ahi, ahi, ahi ....

Questo è falso. Non ci sono limiti per le dimensioni. Si consiglia di non disporre di database di grandi dimensioni, ma solo per semplificare la gestione dei database e ridurre al minimo i tempi di backup / ripristino. Potremmo dire che la limitazione della dimensione dipende solo dalla tua infrastruttura SQL.