Discussion :

[salsero1]

Bonsoir,
Ca fait un petit moment que je me pose cette question.
C'est quoi le risque d'avoir deux schema de base de données dans la meme instance.
Si vous pouvez detailler ca serait vraiment bien? J'ai lu pas mal de trucs. Ca m'a embrouillé lol
Merci

[messalux]

2 schémas de bases de données???

[scheu]

Tu peux avoir une seule et même base de données pour plusieurs applications, si un schéma correspond à une appli
Pour garantir l'indépendance, utiliser des tablespaces différents, voire sur des disques différents. C'est pratique et ça mutualise les ressources de la machine (PGA+SGA communes), si ton serveur est limité
Néanmoins, en cas de restauration à un point passé dans le temps, cela concernera tous les schémas. Exemple : tu veux restaurer ton schéma A 1 heure avant car quelqu'un a fait un drop table, dans ce cas il te faudra aussi restaurer tous les autres schémas 1 heure avant, d'où perte de données potentielle
A moins de faire des exports/imports réguliers en guise de sauvegarde, dans ce cas tu peux réimporter seulement le schéma à restaurer

[salsero1]

Merci pour ta reponse.
Imaginons maintenant qu'on a la meme instance et le meme schema pour 2 applications differentes (Une base de production et une autre base style Datawarehouse) . Ton explication reste la meme pour ce nouveau cas.

[pifor]

Néanmoins, en cas de restauration à un point passé dans le temps, cela concernera tous les schémas. Exemple : tu veux restaurer ton schéma A 1 heure avant car quelqu'un a fait un drop table, dans ce cas il te faudra aussi restaurer tous les autres schémas 1 heure avant, d'où perte de données potentielle
A moins de faire des exports/imports réguliers en guise de sauvegarde, dans ce cas tu peux réimporter seulement le schéma à restaurer

Avec ou sans RMAN, il est possible de restaurer un tablespace à un état antérieur de celui des autres tablespaces en utilisant le Tablespace Point In Time Recovery (TSPITR). Avec un seul schéma par tablespace, il est donc possible de restaurer un schéma à un état antérieur de celui des autres schémas.

[scheu]

Avec ou sans RMAN, il est possible de restaurer un tablespace à un état antérieur de celui des autres tablespaces en utilisant le Tablespace Point In Time Recovery (TSPITR). Avec un seul schéma par tablespace, il est donc possible de restaurer un schéma à un état antérieur de celui des autres schémas.

Mais pour ça il y a besoin d'une autre base dans laquelle restaurer le tablespace avant de le transporter, ou bien non ?

[pifor]

Mais pour ça il y a besoin d'une autre base dans laquelle restaurer le tablespace avant de le transporter, ou bien non ?

Oui. C'est lourd mais si on utilise RMAN il y a des possibilités de demander à RMAN de faire une grande partie du travail.

[13thFloor]

Bonsoir,
Ca fait un petit moment que je me pose cette question.
C'est quoi le risque d'avoir deux schema de base de données dans la meme instance.
Si vous pouvez detailler ca serait vraiment bien? J'ai lu pas mal de trucs. Ca m'a embrouillé lol
Merci

J'ai travaillé il y a 2 ans en client final et nous avions des environnements mutualisés, c'est à dire que sur un (gros) serveur, il y avait 4 bases (1 par domaine fonctionnel) dans lesquelles se trouvaient plusieurs applications, et donc plusieurs schémas. Les risques et complications étaient :
- consommation de ressources, notamment cpu, par une appli au détriment des autres (ressource manager n'était pas généralisé)
- trouver les paramètres adéquats pour toutes les applications d'une même base (exemple : le db_file_multiblock_read_count)
- sizing (parfois excessif mais nécessaire pour éviter les échec de transaction) du temp et de l'undo. Un paliatif sera un temp par schéma mais l'undo va resté commun

[scheu]

Si ton serveur est suffisamment performant (CPU + mémoire) pour pouvoir faire tenir 2 bases, privilégie effectivement 2 bases distinctes (bien que même avec ça, c'est pas évident de savoir quelle base consomme quoi)
Sinon, mutualise les 2 schémas dans une seule base, techniquement c'est tout à fait faisable, tu auras les contraintes de dépendance de version, patch, sauvegarde/restauration ...
Pour ton exemple d'avoir 2 bases (prod + datawarehouse), il faut aussi voir quelles sont les périodes d'activité de chacune, et si les paramètres d'instance peuvent être les mêmes (ex : une appli transactionnelle et une appli datawarehouse n'auront sans doute pas besoin des mêmes valeurs pour certains paramètres d'instance, ...)
Bref, je dirais que pour 2 applis pas trop gourmandes en ressources et assez ressemblantes, on peut mutualiser