Se hai abbastanza spazio, ti suggerirei di copiare tutti i dati di produzione da testare. Sarà molto più semplice da amministrare, potrebbe anche essere una buona opportunità per testare il tuo backup (ripristinare dal backup a una nuova istanza).
Dal punto di vista dello sviluppatore, non sarai in grado di testare le prestazioni della tua applicazione in modo affidabile senza un set di dati rappresentativo. Questo set di dati dovrebbe avere le stesse proprietà dei dati di produzione (volume di dati, distribuzione fisica...). Il modo più semplice per ottenere questo risultato è avere gli stessi dati in prova come in produzione.
Se puoi permetterti dei tempi di inattività, potresti interrompere il db di produzione, copiare il file sul server di prova e montare entrambi i database. Se non puoi permetterti tempi di inattività, potrebbe essere una buona idea acquisire alcune competenze DBA (ed eventualmente conoscere il backup a caldo, quindi ripristinare in una nuova istanza).
Aggiornamento:se la copia fisica del database non è fattibile, dovresti esaminare la copia di massa dei dati con expdp e impdp (o il vecchio exp /imp ). Puoi copiare tutti gli schemi o filtrare dati in esportazione
. In questo caso sceglieresti manualmente la clausola WHERE appropriata. L'esportazione e l'importazione in blocco saranno ordini di grandezza più veloci rispetto alla copia dei dati riga per riga.
