J'ai créé le déclencheur pour l'événement de connexion, comme indiqué ci-dessous:
CREATE OR REPLACE TRIGGER "log_users_session"
AFTER LOGON ON DATABASE
WHEN USER = 'SomeUser'
BEGIN
INSERT INTO "users_logon_log" ("username","date") VALUES ("Some user",sysdate)
END;
3 Réponses :
Il y aura un coup de performance allant de très minimal à fortement élevé sur la base des connexions simultanées. Le coup est proportionnel linéairement au non. de connexions simultanées, c'est-à-dire. Plus de connexions signifient gros succès, moins de connexions signifie moins de succès. Il serait idéal de prendre une décision en fonction de l'AVG no. des utilisateurs qui se connectent au système à un moment donné. J'avais mis en place cela pour une base de données de 300 Go avec environ 200 connexions, il n'avait pas beaucoup d'impact.
Aussi, users_logon_log Table doit être pris en compte pour une maintenance régulière / nettoyage de la croissance trop grande et occuper un espace disque important.
Salut, merci pour votre commentaire! Pour 200 connexions simultanées?
Oui (via des travaux planifiés). Mais le seul moyen de déterminer si votre système manipulera ou non en essayant.
Quelques objections, si je peux.
Débarrassez-vous des citations doubles lorsque vous travaillez avec Oracle, c'est-à-dire NO qui affecte le nom de la colonne: comme de votre question: vous avez décidé de vous connecter uniquement Fondamentalement, cela dépend simplement de ce que vous faites et de la façon dont vous faites. Cela ne coûterait pas trop cher que si vous essayez-le et voyez comment il se comporte. Si cela affecte la performance, ne l'utilisez plus. "LOG_USERS_SESSION" mais LOG_USERS_SESSION . À Oracle, tout est (par défaut) stocké dans le dictionnaire de données comme majuscule, mais vous pouvez le faire référence à votre guise. Avec des guillemets doubles, vous devez le renvoyer en utilisant exactement ce cas de lettre avec des citations doubles, toujours.
"date" . Lorsque vous supprimez les guillemets doubles, vous obtiendrez date et c'est un nom invalide sous la date DATE est réservé pour Oracle DataType; Ainsi, utilisez log_date ou quelque chose comme ça.
certains SO - si cet utilisateur n'établit pas zillion connexions, je ne voudrais pas t s'attend à un impact significatif. Bien que, s'il s'agisse d'une grosse base de données de reporting et de tous les utilisateurs (lire: personnes), utilisez les mêmes informations d'identification tout en connectant / établissant une nouvelle session, alors peut-être . D'autre part, quel est le but d'une telle configuration? Vous obtiendrez un grand nombre de connexions pour le même utilisateur pendant tout le temps que vous surveillez.
Bonjour, merci de votre réponse. Dans ma société, nous ne pouvons pas réaliser une vérification complète de toutes les données de base de données (objectif d'origine) en raison de ressources limitées. Nous ne pouvons donc essayer de mettre en œuvre un autre audit de base. Je comprends que ce n'est pas une bonne solution, mais ... et cet utilisateur utilisé uniquement par certaines personnes (l'accès ne les accordait que). Ps. J'ai oublié de dire que la table de journaux contiendra nom d'utilisateur comme dans Active Directory, Hôte utilisateur et IP. Et cette information, je pense que vous pourrez suffisamment pour l'audit de base.
La gâchette va tirer sur chaque connexion , quel que soit l'utilisateur. Il va évaluer le «si» pour chaque connexion. Je ne vois pas comment cela est perçu comme mieux que d'utiliser l'audit pour exactement ce qu'il a été conçu et optimisé pour. L'audit n'est pas une proposition tout ou-rien. Vous pouvez le configurer pour enregistrer uniquement des connexions , comme votre déclencheur. Et cela capturera tous les éléments de données que vous mentionnez. Et vous n'aurez pas à le revenir et de le modifier lorsque la liste des utilisateurs de votre déclenchement proposé change.
De plus, et très important encore, votre déclencheur ne fera que capturer des connexions performantes. Il ne verra pas les logines ayant échoué car seule une connexion réussie peut entraîner le déclenchement de la gâchette. L'audit capturera les deux, ce qui est important pour toute configuration de sécurité grave.
@Kiazimkhutaba Utilisez cela plutôt que pour seulement tirer pour un utilisateur spécifique: Créer ou remplacer le déclencheur log_users_session après la connexion sur ONUSERER.SCHEMA ... . Ce changement est important non seulement pour la performance, mais que si ce déclencheur rompt jamais, cela ne parsait au moins pas pour tout le monde . De plus, à moins que quelque chose ne soit sérieusement faux avec votre base de données, je ne peux pas imaginer un tel déclencheur de la performance. Par rapport au temps nécessaire pour créer des données de session, ce déclencheur n'est pas pertinent.
Si vous n'avez besoin d'enregistrer que des connexions à la base de données, je voudrais simplement utiliser des fonctions d'audit de base de données: https://docs.oracle.com/en/database/oracle/oracle-database/19/dbseg /introduction-a-aditing.html#guid-f901756d-f747-489c-Acde-9DBFDD388D3E