DATASTORE TAILLE DE 09 Gigas

Bonjour,



En voulant réinstaller un serveur Citrix sur la ferme d’un de mes clients, j’ai eu un message d’erreur que j’ai réussi à analyser … en fait, je ne peux installer d’autres serveurs Citrix dans ma ferme car la DATASTORE a atteint une taille de 08 Gigas !!! j’ai essayé la commande dscheck /clean mais rien n’y fait, auriez-vous une idée afin de nettoyer cette base ?



Par avance merci.



Cdlt

C’est la base ou ses log ?



http://www.doctor-citrix.com/fr/article/microsoft/87-journal-transaction-datastore.html

quelle table as-tu dans la base ?



Lors d’audit, j’ai constaté que des bases datastore, RM ou configuration logging etaient installé sur la même base. :o

C’est de loin le meilleur forum Citrix :), quelle rapidité.



Il s’agit de la base RM, la base DS ainsi que l’autre dont j’ai oublié le nom sont d’une taille normale.



Ce n’est pas moi qui ait installé le serveur SQL qui est en version 2000 SP4. Les logs sont de taille normale également (50 Mo).



Merci encore pour votre aide.



Cdlt

et donc ? c’est quoi le soucis ?

La base RM fait plus de 9 Gigas !!! , je pense avoir trouvé une solution mais n’en suit pas sur à 100 %. Il faudrait arrêter le service IMA sur le serveur mais vu qu’il n’est pas démarré, c’est un moindre mal … supprimer la base RM locale mais j’ignore encore où elle se situe, peut-être une valeur de la registry devrait me donner celà.



Sur les versions antérieures de Citrix, le chemin était %systemroot%Program FilesCitrixCitrix Resource ManagerLocalDB mais pour une Xenapp5.0, j’en ignore le chemin, une rapide recherche sur les fichiers .mdb devrait me donner ce chemin. Après suppression du fichier, tenter de redémarrer le service IMA et en principe la base RM du serveur Citrix devrait retrouver une taille normale bien inférieure à 9 Gigas.



Qu’en pensez-vous ?

Merci pour l’aide.



Cdlt

Faut que tu sois plus clair dans tes propos.



-> Ton problème : Impossible d’ajouter des serveurs à la batterie car la DS fait 8 Go.

Est-ce que la base de données DS héberge plus que 4 tables (signe que les bases DS et RM/CL sont mergés) ??? Note que j’ai deja vu le cas ou la DS était directement dans la table master SQL…

Si c’est un problème de ce type, je te conseille de migrer la DS dans une nouvelle base bien propre avec dsmaint migrate et config.



Tu confonds la base RM locale qui sert à stocker les métriques sur 3 jours et la base RM de synthese qui ne peut être hébergé que sur un serveur SQL/oracle.



Pour répondre à une de tes questions, pour shooter la RM locale, il faut au préalable arreter le service IMA puis supprimer le fichier RMLOCALDATABASE.mdb.

Merci pour tes réponses avisées, comme tu as pu le constater mes connaissances en SQL sont assez limitées … d’autant que je bosse pas directement chez le client donc il faut que fasse un gotoassist et que je vérifie tout celà. Je devrais pouvoir faire les checks demain et je ne manquerais pas de revenir vers toi afin de synthétiser celà.



En tout cas grand merci pour ton aide car là je séchais grave.



Cdlt

de toute façon, 9 Gb pour une base RM (et bien RM!) c’est pas surprenant… mais tu n’indiques pas si tu disposes de 10 serveurs avec 4 tondus et 5 pelés ou de 300 serveurs avec 2300 applications publiées et 10000 utilisateurs…



supprimer la base RM locale ne changera rien à la taille de ta base RM de toute façon.



pour une purge manuelle :

http://support.citrix.com/article/CTX121125



pour vérifier si tu as des records dans SDB_SESSIONS où le champ SESSIONEND est NULL, ce qui empêche la purge de ces sessions :

update sdb_session

set sessionend = (

select min(e.eventtime)

from sdb_eventlog e

where e.eventtime > sessionstart

and e.fk_serverid = sdb_session.fk_serverid

and e.eventcode in(0,1))

,duration = 0

where sessionend is null;

"ThinIsFat" wrote:
de toute façon, 9 Gb pour une base RM (et bien RM!) c'est pas surprenant... mais tu n'indiques pas si tu disposes de 10 serveurs avec 4 tondus et 5 pelés ou de 300 serveurs avec 2300 applications publiées et 10000 utilisateurs...

+1 mais surtout la durée de rétention des données

De toute façon RM c'est mort, maintenant c'est edgesight basic à minima

Bonjour,



Merci encore pour vos réponses, je dois contacter mon client aujourd’hui … je vais tâcher d’obtenir plus d’information, en fait la ferme est en 4.5 et ne se compose que de 04 serveurs ; pas énormément d’applis publiées non plus.



Je vais regarder de près la CTX121125

ThinisFat, pour ce que tu as indiqué après, j’avoue qu’étant donné mon niveau proche de 0 en SQL, je ne sais pas quoi en faire, il faut que je regarde dans la table SDB_SESSIONS si le champ SESSIONEND est positionné sur NULL ?



Par contre pour le reste du petit script en SQL, j’en fait quoi ?



Je crois qu’ils ont un DBA enfin j’espère, mais cette partie m’intéresse. Sinon pour RM je sais que c’est mort mais bon vu l’infra actuelle, je vais pas leur proposer du EdgeSight -:slight_smile:



Merci encore



Cdlt

mon script ne concerne QUE la Summary DB de RM et SURTOUT PAS le DataStore.

comme ce n’est toujours pas très clair si ton post est lié aux 9 Go de la SumDB ou du DS…



bref, le script permet de vérifier si tu as des records dans SDB_SESSIONS qui ont une valeur NULL pour SESSIONEND ce qui empêche la purge automatique de fonctionner



Il est de toute façon impossible d’avoir 9 Go de DataStore avec 4 petits serveurs…

Avant de balancer le script, tu postes une capture d’écran des tables contenues dans la base de données, parce que t’es pas clair du tout.

+10 comme cela on saura si tu parles de DataStore ou de base RM!!

Bonjour,



J’ai tout bien saisi, je vais demander à mon client de faire des captures des tables contenues dans la BD. Désolé si je ne suis pas très clair mais je bosse à vue, très peu d’info de la part du client.



Merci encore.

Bonsoir,



Voici les différentes captures d’écran réalisées par le client. J’espère que cela sera suffisant pour analyser la problématique.



Merci encore.

donc c’est bien une base RM…



les éléments que j’ai donnés t’aideront à virer les données dans SDB_SESSION où sessionend est NULL et ensuite la purge automatique pourra fonctionner correctement

Bonjour ThinisFat,



Merci encore pour ton aide précieuse, j’avais déjà communiqué les éléments que tu m’avais donné au client mais je doute qu’il dispose d’un dBA sur site donc les choses risquent de ne pas avancer énormément de ce point de vue.



Donc je résume, le client doit exécuter le script suivant que tu m’as donné sur le serveur SQL sur lequel est hébergé la base RM ?



update sdb_session

set sessionend = (

select min(e.eventtime)

from sdb_eventlog e

where e.eventtime > sessionstart

and e.fk_serverid = sdb_session.fk_serverid

and e.eventcode in(0,1))

,duration = 0

where sessionend is null;





J’espère que le client saura mettre en place ce petit bout de script sans trop de problème. Je reviendrai sur ce post pour informer des résultats.



Grand merci encore.



Cdlt

ce bout de code ajoute une valeur au champ sessionend qui sont null pour ainsi permettre la purge automatique de la base

Kreos, tu peux renommer ton topic.

c’est un problème de taille de la base RM, laisse la datastore tranquille. ;D



PS : A la vue de tes différents topics, je te conseillerais de changer de clients. Ils ont trop de problèmes :police: