Discussion :

[arona]

Comme déja demandé je continue sur mon upgrade de version. J'ai récupéré chez sybase le TAR (ase1254sol64.tar) de ASE 64 bits sous sun, j'ai "dé"tarer le fichier emais je ne trouve pas de fichier covert roll qq'un sait il si il existe encore ou pas ??

[mpeppler]

Dans la mesure où il s'agit d'une release "IR" il faut plutôt lire les "release notes" qui sont dans le package de documentation correspondant (avec tous les PDF). Celui-ci est aussi downloadable depuis subscribenet, ou alors accessible directement sur le site Sybase (sous product manuals).

Cependant, en court: la procédure est la même que pour l'application d'un EBF, cad on pose le code, on redémarre la base, on passe installmaster, instmsgs.ebf, et quelques autres scripts en fonction des options qu'on utilise (p.ex. installmontables si on utilise les tables MDA, installsecurity si on utilise l'audit, etc)

Michael

[arona]

J'ai éffectivement recréé master et autre mais j'ai aussi refais tout le serveur..
Recréation des devices ect... Pour ma part le passage en 12.5.4 64 bits est bcp plus lourd que prévu...
C'est due au fait aussi que toutes les tables systèmes sont out suite a l'install.. Maintenant que mon install est finalisé je vais sans doute faire un TAR de l'install ASE 64 le coller sur mes autres serveurs et la refaire un install master, mais avec cette méthode va t'il garder la table system avec la définition de mes devices ect ???
Merci de votre point de vue.

[arona]

Je continu dans mon upgrade, j'ai suivi vos remarques et je suis dans la phase de load de mon dump en 32 bit vers la new version en 64 et là a la fin du load il ne me rend pas la mains ... je retente de nouveau de refaire le load mais il me sort les erreurs suivante

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
Backup Server session id is:  17.  Use this value when executing the 'sp_volchanged' system stored procedure after
fulfilling any volume change request from the Backup Server.
Backup Server: 4.26.2.1: Volume validation error: failed to obtain device information, device: /TMP/aafdav3.dmp error:
No such file or directory.
Msg 8009, Level 16, State 1:
Server 'DEVFDA', Line 1:
Error encountered by Backup Server.  Please refer to Backup Server messages for details.
1> load database fdav3 from "/fidessa/save/aafdav3.dmp"
2> go
Backup Server session id is:  18.  Use this value when executing the 'sp_volchanged' system stored procedure after
fulfilling any volume change request from the Backup Server.
Backup Server: 4.10.2.1: Label validation error: first label not VOL1.
Backup Server: 6.31.2.4: Volume rejected.
Backup Server: 1.14.2.2: Unrecoverable I/O or volume error.  This DUMP or LOAD session must exit.
Backup Server: 6.32.2.3: /fidessa/save/aafdav3.dmp: volume not valid or not requested (server: , session id: 18.)
Backup Server: 1.14.2.4: Unrecoverable I/O or volume error.  This DUMP or LOAD session must exit.
Msg 8009, Level 16, State 1:
Server 'DEVFDA', Line 1:
Error encountered by Backup Server.  Please refer to Backup Server messages for details.

et la base est en status

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

don't recover, offline

quand je fais un sp_helpdb.
Merci de votre aide.

[mpeppler]

Il faut voir dans la log du backup server - mais à priori la première erreur indique que le (ou un des) fichier dump n'est pas lisible/trouvable ("no such file or directory").

Michael

[arona]

Sorry j'avais trouvé la réponsse ... éffectivement ce n'est pas un problème de fichier trouvé mais de format. J'avais fait mon dump en compress donc quand je fais un load sans le mode compress cela ne marche pas ;-)
mais merci quand même

[arona]

Salut je suis toujours dans mes upgrade de version mais avec la prod en continu je fais cela par épisode.
J'ai un autre serveur a upgrader mais comme je ne veux pas être dans les mêmes problèmes que lors de mon précédent upgrade, je le prépare "complètement".
Donc cette fois ci j'ai mon répertoire avec le binaire en 64 bit au même niveau que celui en 32 bits. Ma procédure prévu est la suivante.
- dump de ma base de prod
- bcp out de syslogins.
- lien logique (ln -s...) avec le même nom vers mon dossier avec le binaire 64
- copie des fichiers .cfg et RUN_file dans mon new répertoire.
-arret de ma base 32 bits
- Redémarrage en 64 bits.
- Réinstall de la basse master pour la 64bits.( sans doute messages et dbcc au cas ou ..)
- BCP in de syslogins
- load de mon dump fait en 32 bits sur ma base en 64.

Est ce que cela vous semble correcte comme manip ???

[mpeppler]

A priori cela a l'air raisonnable, si les deux install sont sur des machiens différentes. Si c'est sur la même machine on doit pouvoir faire plus simple!

Michael

[arona]

Plus simple ??? c'est sur la même machine dans deux répertoire différent d'oû mon lien logique (ln -s toto) pour redonner le même nom au répertoire et pas modifier tout mes scripts d'admin ...
Donc plus simple tu propose quoi ?? quand c'est sur la même machine??

[mpeppler]

Plus simple dans le sens qu'il n'est pas nécessaire de recréer le dataserver (reload de master, etc.)

Il suffit de redémarrer l'instance avec le code 64bit.

Si la version 64bit est différentes (plus récente, mais tout de même un 12.5.x), alors on doit rejouer installmaster, instmsgs.ebf et peut-être quelques autres, à priori la même opération que pour le passage d'un EBF.

Michael

[arona]

oki oki, merci de ces infos mais comme j'ai pas passé d'ebf depuis des années et que je fais plus d'oracle qu'autre chose en ce moment je peine un peu ... ;-)
merci en tout cas.
A+

[arona]

Bon j'ai fait ma migration en réalisan la manip que j'avais d"crite plus haut ... cela a mis 40 minutes (petite base de 10 Go)... MAIS je n'ai pas réinstallé la base master ou fait les scripts messages est ce que cela peu avoir une incidence ?? et si j'avais relancer l'install de master ma base aurait été sans doute détruite, vu que (je pense) les tables systems syslogins devices et autre doivent être HS aprés une réinstall de master non ??

[mpeppler]

Le script installmaster ($SYBASE/$SYBASE_ASE/scripts/installmaster) ne fait que de reinstaller les procs stockées système. Ce script ne recrée pas les tables dans master, ou ailleur. Il est donc NON destructeur (sauf si on a créé une version modifiée d'une proc système, évidemment).

Pour rappel, voici la procédure pour installer un EBF:

Arrêt de la base, et du backup server, etc.
Backup du code (repertoire $SYBASE) pour pouvoir faire retour arrière.
Upgrade du code (via exécutable "setup" fourni dans l'EBF)
Démarrage de la base
cd $SYBASE/$SYBASE_ASE/scripts
isql -Usa -P... -S... -i installmaster -o /var/tmp/installmaster.log
isql -Usa -P... -S... -i instmsgs.ebf

Si l'audit est installé, il faut aussi exécuter installsecurity.
Si on utilise des transactions distribuées, il faut exécuter installcommit.
Si on utilise les tables MDA, exécuter installmontables.

Et voilà - c'est assez simple...

Michael

[arona]

OUi en effet, mais j'ai fait mon upgrade sans faire l'installmaster, et cela fonctionne convenablement !! pense tu que faire cette install est obligatoire ?? ( bon j'inclus messages aussi)???

[mpeppler]

L'installmaster est fortement conseillé si tu change de version (nouvelle ESD).

Si tu as installé la même version entre 64 bit et 32 bit il n'est pas nécessaire de recharger installmaster.

Michael

[arona]

Bon fini !!
J'ai installé comme tu as conseillé "installmaster" et messages.ebf. Tout fonctionne bien.
Donc dans un soucis de partage je refais ici un petit doc ... Merci encore.
A+

donc sujet UPGRADE de version de Sybase ASE sous platte-forme Sun Solarisde la version

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
select @@version
go
Adaptive Server Enterprise/12.5.2/EBF 11941 ESD#1/P/Sun_svr4/OS 5.8/ase1252/1838/32-bit/FBO/Sat May 29 09:42:35 2004
#VERS#
select @@version
go
Adaptive Server Enterprise/12.5.4/EBF 13381/P/Sun_svr4/OS 5.8/ase1254/2006/64-bit/FBO/Wed May 24 03:14:30 2006

Pour ce faire j'ai copier (via TAR) le répertoire 64 bits au même niveau que ma directorie ASE 32 bits.
J'ai copier sous le repertoire 64 bits les fichiers
- .profile
- interfaces
- toto.cfg (toto étant le nom de votre dataserver)
- RUN_file dataserver
- RUN_file Backup et Monitor server.

Ensuite dbcc checkcatalogue puis dump de la (ou les...) databases qui passent en 64 bits.
Arret backup server et shutdown du data server.

Dans le soucis d'une possibilitée de retour arrière en cas de problème.
Renommage du répertoire 32 bits en .old et lien logique (ln -s ...) avec mon répertoire en 64 bits.
RUN backup et dataserver en 64 bits.
- installmaster
- install messages.ebf

load avec le DUMP fait au début de la procédure, la migration est faite automatiquement.
Vila merci a tous j'espére avoir été relativement clair.
lut'

[ecerisier]

Hello tout le monde,

Hello Michael: je ne savais pas que tu parlais francais

Pour info: je dois faire a peu pres le mem style d'upgrade que arona:
Passage de 3 ASEs 12.5.3 ESD#2 32bits vers 12.5.4 64bits, avec en plus le fait que ces serveurs sont primary et replicates d'un system de replication repserver 12.6.

Apres avoir un peu discute avec mon support, il semblerait que la solution consistant a deplacer le binaire 32bits sur une machine 64, puis deposer le code 64bits 12.5.4 par dessus et relancer l'ASE + postinstall scripts n'est: "pas recommande/pas supporte/ne marchera pas" (on choisit )

D'apres ce que j'ai compris, Sybase recommande de faire ce qu'a fait arona: creer un serveur a blanc, le configurer comme il faut (syslogins copies, dbccdb, tuning, etc.) creer les devices puis reloader les dumps des bases du serveur 32bits.

Moi mon seul probleme c'est concernant la replication: mettons que j'upgrade mon ASE conteant des replicate dbs, il faudra que je reloade un dump de la RRS_RSSD, puis : comment faire pour que mon repsystem voie le nouveau serveur comme son replicate ?
Je changerai le nom/interface/IP address pour matcher l'ancien serveur, mais je me demande si cela va suffire...

Des idees ?

Emmanuel.

[mpeppler]

Hello Michael: je ne savais pas que tu parlais francais

Contrairement à ce qu'on peut penser, je suis Suisse...

Pour en venir au passage 32->64 avec la repli: je n'ai pas encore eu le plaisir de faire cette opération, mais en principe la méthode suivante devrait marcher:

1. quiesce de la connexion rep->base à upgrader
2. suspension de la connexion.
3. arrêt du dataserver à upgrader, migration en 64bit, reload des bases
4. Changement de l'interfaces file pour le repserver
5. resume de la connexion.

Je ne pense pas que le repserver "cache" l'information du fichier interface, donc je ne pense pas qu'un redémmarage du repserver soit nécessaire.

Je répète que je n'ai pas fait cette opération moi-même, mais je ne vois pas, à priori, pourquoi cela ne marcherait pas.

Michael

[arona]

Lors de mon Upgrade j'étais dans une configuration du type dataserver primaire --> REP Server --> secondary dataserver.
Donc ce que j'ai fait c'est un upgrade de la Secondary avec en amont arret de la répli par le biai d'un Suspend connection et passage de mon upgrade, deux heures parès resume connection sur la répli vers le secondary. Pour cette phase pas de problème en reprenant la méthodologie que j'ai mise plus haut.
Ensuite test de non régréssion et on regarde le comportement de la répli pendant qq jours. Ensuite upgrade de la primary avec la même méthode. Vila pour mon expérience perso les liens logique avec les deux répertoire 32 et 64 avec copie des cfg, RUN et interface persmet un retour arrière relativement simple.

[ecerisier]

Merci messieurs pour vos reponses,

Je passe l'upgrade 32bits -> 64bits + 12.53 -> 12.5.4 + filesystem -> rawdevices + NAS -> SAN (tant qu'a faire, on va pas s'embeter !! ) la semaine prochaine...Je vous tiendrai au courant mais d'apres vos experiences, ca devrait rouler

Merci,

Emmanuel