Discussion :

[JeanYvette]

Bonjour,

Je vous écrit pour différentes questions sur la supervisions Oracle notamment des Tablespaces.

J'ai lu par endroit que si l'on souhaite créer un script sql de supervision de tablespace, il fallait une option particulière à la licence Oracle.
Je suis potentiellement aveugle mais je ne trouve pas l'option qui est nécessaire à ça (Nous gérons la base mais nous n'en sommes pas les DBA)

Si en effet il faut cette option et que nous ne l'avons pas. Que se passerait-il si la supervision ne se fait pas par un script mais par un logiciel externe de supervision ? Des risques en cas d'Audit sont-ils imaginables ?


Ensuite dernière question (Je sais, y'en a beaucoup), si le script SQL est possible. J'imaginais une surveillance du style ; Taille de la tablespace et si autoextend est actif ou non.
Si autoextend n'est pas actif, quand il y a moins de 10% de libre (Ou moins d'une certaine taille) => Alert
Si autoExtend actif, check de la taille du/des datafiles associés et si seuil défini est dépassé => Alert

Merci de votre aide et désolé si je le sujet a déjà été évoqué, je ne l'ai pas vu.
Ne connaissant pas trop cet aspect d'Oracle, je découvre petit à petit...

Bisous

[13thFloor]

Hello,
si tu ne veux pas déclencher l'utilisation de l'option Diagnostic pack,
1) il faut désactiver son usage : paramètre control_management_pack_access à NONE
2) il ne faut pas utiliser les tables qui en font partie. dba_hist_tbspc_space_usage en est une.

Jettes un oeil à la note 1317265.1 pour éviter les mauvaises surprises.

En cas d'audit, si Oracle voit qu'une option est très peu utilisée, tu peux argumenter qu'il s'agit d'une erreur et qu'il n'y a pas matière à facturer. Encore faut-il que la team LMS (gestion des licences client) soit de bon poil et qu'elle n'ait pas trop d'objectif de chiffres d'affaires à faire rentrer.

Ton besoin en script est tout à fait faisable sans license supplémentaire, tu vas interroger des vues "ordinaires" (dba_tablespace_usage_metrics, dba_segments, dba_data_files; dba_free_space...).

[Lyche]

Hello,
si tu ne veux pas déclencher l'utilisation de l'option Diagnostic pack,
1) il faut désactiver son usage : paramètre control_management_pack_access à NONE
2) il ne faut pas utiliser les tables qui en font partie. dba_hist_tbspc_space_usage en est une.

Jettes un oeil à la note 1317265.1 pour éviter les mauvaises surprises.

En cas d'audit, si Oracle voit qu'une option est très peu utilisée, tu peux argumenter qu'il s'agit d'une erreur et qu'il n'y a pas matière à facturer. Encore faut-il que la team LMS (gestion des licences client) soit de bon poil et qu'elle n'ait pas trop d'objectif de chiffres d'affaires à faire rentrer.

Ton besoin en script est tout à fait faisable sans license supplémentaire, tu vas interroger des vues "ordinaires" (dba_tablespace_usage_metrics, dba_segments, dba_data_files; dba_free_space...).

C'est bien le gros souci avec Oracle en fait.. ils font tout ce qu'ils peuvent pour te la mettre. je comprends pas comment cette société a encore des clients avec une telle politique -_-'

[JeanYvette]

Merci pour vos réponses

Une question sur le fonctionnement des tablespaces. Si j'ai 5tablespace avec des données de ce type par exemple :

TableSpaceUn - 10% libre - AutoExtend Oui
TableSpaceDeux - 3% libre - AutoExtend Non
TableSpaceTrois - 70% libre - AutoExtend Non
TableSpaceQuatre - 90% libre - AutoExtend Oui
TableSpaceCinq - 10% libre - AutoExtend Oui

Les tablespace 3 et 4 sont ok car assez place de libre.
Les tablaspaces 1 et 5 sont quasi plein mais en autoextend
Le tablespace 2 est quasi plein et sans autoExtend

J'ai donc une alerte qui se lancera pour le tablespace 2.
Par contre mon interrogation sur porte sur les 1 et 5. En effet, ils sont certes en autoextend mais le script doit-il vérifier autre chose qui pourrait bloquer ?

[13thFloor]

je comprends pas comment cette société a encore des clients avec une telle politique -_-'

c'est historique. Une grosse base client est installée depuis des années, beaucoup d'erp fonctionnent sous Oracle.
Par contre de + en + se tournent vers l'open source pour sortir du carcan oracle et de sa politique commerciale parfois abusive (licence et audit).
Et malgré la floppée de bugs il y a quand même des technos très utiles et pratiques : smart scan, dataguard, partitionnement...

[Ikebukuro]

Et malgré la floppée de bugs il y a quand même des technos très utiles et pratiques

On peut avoir une liste de ces bugs?

[13thFloor]

Il suffit d'aller fouiner sur metalink (https://support.oracle.com) :
12.2.0.1 Base Release - Availability and Known Issues (Doc ID 2239820.1)
Exadata Critical Issues (Doc ID 1270094.1)
Zero Data Loss Recovery Appliance Critical Issues (Doc ID 1927928.1)
et tous les correctifs des patchsets.

[SQLpro]

c'est historique. Une grosse base client est installée depuis des années, beaucoup d'erp fonctionnent sous Oracle.
Par contre de + en + se tournent vers l'open source pour sortir du carcan oracle et de sa politique commerciale parfois abusive (licence et audit).
Et malgré la floppée de bugs il y a quand même des technos très utiles et pratiques : smart scan, dataguard, partitionnement...

Il existe un SGBDR qui est plus puissant (multibase avec un JT par base) et plus performant (voir TPC-E / TPC-H) avec beaucoup moins de bugs et de vulnérabilité...
C'est SQL Server de Microsoft...

Pour info Active Dataguard = AlwaysOn, l'équivalent du "smart scan" existe depuis l'origine dans toutes les versions sur Windows... Et le partitionnement et la compression est possible même en version standard.
Quant aux prix il est entre 4 et 24 fois moins cher !!!
En outre il y a beaucoup de technologies SQL Server qui n'existe pas dans Oracle, comme :

• les tables temporelles (toutes éditions)
• FileStream / Filetable (toutes éditions)
• Support complet des collations (près de 4000 - toutes éditions)
• Nom longs pour les identifiants SQL (toutes éditions)
• 7 modes de réplication de données (5 pour l'édition standard)
• Privilèges portables au niveau du schéma SQL (toutes éditions)
• Chiffrement de bout en bout (jusqu'à l'applicatif)
• Requêtes interbase optimisées (pas de DB link...)

Oracle à mis beaucoup de temps à introduire l'opérateur APPLY (créé par Microsoft en 2005) et vient juste de commencer à faire les noms longs (128 caractères, norme SQL de 1992), et pour les collations c'est encore très embryonnaire ! Ne parlons pas des jointures externes normalisées (LEFT/RIGHT/FULL OUTER JOIN) qu'oaracle à eu de la peine à mettre en œuvre, ni des CTE...

Les deux seules choses pour lesquelles il n'existe pas de strict équivalent ce sont exadata (anciennement RAC) et database vault.

• Pour Exadata il peut être remplacé par les DVP de SQL Server avec de la réplication transactionnelles.
• Pour database vault, les privilèges de SQL Server au niveau instance et au niveau base sont suffisant, mais le DBA possède toujours la possibilité de se réapproprier les privilèges.

Quand au coût de maintenance/exploitation, il est bien moindre à volume et transactions équivalente...

A +

[Ikebukuro]

Et l'historique des requêtes? Quel est l'équivalent de ASH et AWR sous SQL Server?
Il existe une gestion aussi fine des événements d'attentes que sous Oracle?
Quid du contrôle de SQL Server sur des ordres SQL qu'on ne maîtrise pas car ils viennent de logiciels tiers? Comment prendre la main dessus et forcer un plan d'exécution? Quel sont les équivalents des SQL Profiles et Baselines Oracle?