[ASE 15.0.2] database load segments devices

Bonjour
j'ai besoin d'effectuer un "load" à partir d'une base ci-dessous:

Citation:

---

create database xxx on xxx_data1 = 3072, xxx_log = 2048
log on xxx_data1 = 1024
with override

---

Dans cette base, suite à une erreur d'administration, les data et le log se retrouvent sur le même device.

La base cible est:

Citation:

---

create database yyy
on yyy_data1="5G"
log on yyy_log="2G"
go

---

Suite à un load classique, la structure de la base "yyy" devient identique que celle de base "xxx":
Comment arriver à regrouper les data sur yyy_data1 et basculer le log sur yyy_log?

Merci
msomso
P.S.
En raison du nombre de tables existant dans la base, je cherche une autre solution que bcp.

As-tu essayer sybmigrate ?

Bonjour,
je n'ai jamais utilisé sybmigrate.
Je vais essayer de le tester.
Sinon, il existe peut être une autre solution (plus simple ;) ) ?
Merci
msomso

Attention: ne faire ce qui suit que si un backup existe!!!

Première chose à faire - un select * from master..sysusages pour la base en question.

qqch du genre:

Code:

---

1 2 3 4 5

select * from master..sysusages u join master..sysdevices d on d.vdevno = u.vdevno where u.dbid = db_id('ma_base')

---

Ensuite - je pense qu'on peut mettre segmap à 7 pour tous les fragments, puis exécuter sp_logdevice pour déplacer la log vers le device approprié.

Ensuite les nouvelles allocations de log devraient aller sur le nouveau device...

CAVEAT: je n'ai pas fait ce genre d'opération moi-même, et cela pourrait tout à fait ne pas marcher.

Michael

Bonjour Michael
en disant "pour la base en question", penses-tu à la base cible (chargée via load et avec des segments "reformatés" à l'identique de source) ?
Autrement dit, cette intervention est-elle à faire avant ou après le chargement ?

Sinon je joins le résultat du SELECT proposé dans un fichier res.xls

D'après ce résultat, la colonne segmap prend la valeur 3 pour les data et 4 pour le log.
Pourquoi, et pour quels "fragments", la mettre selon toi à "7" ?

Citation:

---

je pense qu'on peut mettre segmap à 7 pour tous les fragments

---

Pourrais-tu me préciser davantage les étapes à suivre ?

Merci
msomso

En fait il y a deux possibilités:

1) recréer la base cible avec les fragments dans le bon ordre. Cela devrait être qqch du genre:

Code:

---

1 2 3 4 5

create database <nom> on armen_data1 = '1024M' log on armen_log = '1024m' alter database <nom> on armen_data1 = <reste du data voulu> alter database <nom> log on armen_log = <reste du log voulu>

---

et ensuite faire un load database. Cela va faire qu'on aura quand même plusieurs fragments, mais les fragments seront sur les bon devices.

2) Bidouiller les tables systèmes de la base cible:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

sp_configure 'allow up', 1 go begin tran update sysusages set segmap = 7 where dbid = 5 go -- faire un select pour vérifier que l'update a bien touché les bonnes -- lignes.... -- si tout est OK: commit sp_configure 'allow up', 0 go sp_dboption <ma_base>, 'single user', true go sp_logdevice <ma_base>, 'armen_log' go

---

Maintenant les NOUVELLES allocations de log vont aller sur le device 'armen_log'. Si il y a des pages "data" qui sont allouées sur armen_log celles-ci n'auront pas été déplacées par cette opération. Pour s'assurer que tout est au bon endroit on peut dropper et recréer les "clustered" indexes, ce qui a pour effet de recopier la table au bon endroit. Note que d'après le res.xls le device armen_log semble vide, donc ce dernier step ne devrait pas être nécessaire.

Je répéte: je n'ai pas eu l'occasion de faire ce genre de chose très souvent, donc je ne garantis pas que cela va marcher!!!

Michael

Bonjour Michael
*** Solution proposée 1
Cela semble ne pas marcher: j'ai créé la base cible avec 5Go pour les data et 2Go pour le log (cf. le premier post) et pourtant après le load tout est à l'identique de la base source.

*** Solution proposée 2
Pourrais-tu m'expliquer pourquoi mettre le segmap à 7 et comment diagnostiquer le log étant vide (

Citation:

---

d'après le res.xls le device armen_log semble vide

---

) ?

Merci
msomso

Pour 1) il faut faire bien attention de créer les fragments dans le bon ordre.

Pour 2) on mets le segmap à 7 pour "tricher" et mettre tous les fragments à "data + log". sp_logdevice fait la modif inverse (regarde le code de sp_logdevice...)

Pour voir que c'est vide - dans sysusages le champs unreservedpgs doit être égal à size (si mes souvenirs sont bons)

Bonjour Michael
Comment utiliser l'option "for load" pour créer la base avec tous les fragments dans l'ordre en évitant le formatage inutile avant le load ?

Merci
msomso

Il suffit d'ajouter "for load" dans le create database et le ou les alter database...

Code:

---

1 2 3 4 5 6 7 8 9

create database toto on dev1='1024m' log on logdev='1024m' for load go alter database toto on dev1='1024m' for load go alter database toto on logdev=... for load go load database toto from .... go

---

Citation:

---

Envoyé par mpeppler

2) Bidouiller les tables systèmes de la base cible:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

sp_configure 'allow up', 1 go begin tran update sysusages set segmap = 7 where dbid = 5 go -- faire un select pour vérifier que l'update a bien touché les bonnes -- lignes.... -- si tout est OK: commit sp_configure 'allow up', 0 go sp_dboption <ma_base>, 'single user', true go sp_logdevice <ma_base>, 'armen_log' go

---

Maintenant les NOUVELLES allocations de log vont aller sur le device 'armen_log'. Si il y a des pages "data" qui sont allouées sur armen_log celles-ci n'auront pas été déplacées par cette opération. Pour s'assurer que tout est au bon endroit on peut dropper et recréer les "clustered" indexes, ce qui a pour effet de recopier la table au bon endroit. Note que d'après le res.xls le device armen_log semble vide, donc ce dernier step ne devrait pas être nécessaire.

Je répéte: je n'ai pas eu l'occasion de faire ce genre de chose très souvent, donc je ne garantis pas que cela va marcher!!!

Michael

---

J'ai déjà mis le segmap à 7 pour un device de data, ça fonctionne bien, il passe en log and data (pas testé de le mettre a 7 pour un device de data).
sp_logdevice fonctionne aussi très bien.
Plutôt que de dropper/recréer tous les index clustered, il est aussi possible de faire un reorg rebuild sur toutes les tables (c'est possible de le faire même sur les tables en APL depuis la 15).
Enfin on peut utiliser sp_helplog ou dbcc checkalloc pour vérifier que le device de log est bien le seul à contenir des pages de log.

Pour avoir plus d'infos, pourrait-on avoir le résultat d'un:

Code:

---

1 2 3 4 5

use base go sp_helpdb base go

---

Bonjour
merci à tous ceux qui ont pris le temps de me répondre.
***
J'ai appliqué la solution la plus simple en recréant la base cible avec la fragmentation à l'identique de la base source et option "for load" (je ne savais pas qu'il fallait indiquer cette option dans "alter database" après un "create ... for load" - merci Michael) .
Après le load, les segments sont bien positionnés (cf. sp_helplog - merci Roller)
***
J'ai hésité pour la solution avec le basculement du log, car il me semble que mon segment armen_log de la base cible n'était pas tout à fait vide:

Citation:

---

dans sysusages : size =1048576 et unreservedpgs=1044480

---

Cet écart, serait-il dû aux allocations "data" dans le segment prévu pour log ?

Merci encore
msomso

Bonjour
j'ai voulu tester quand même la solution 2 (avec le basculement du log).

Cela a marché sur une base, par contre sur une autre j'ai un petit souci:
- je n'ai pas de message d'erreur
- toutes les commandes se déroulent bien
- les segments sont bien maj dans sysusages

Seulement quand je veux faire la vérification via "sp_helplog" j'obtiens ceci:

Citation:

---

No valid log device can be found to contain the starting logpage of '850902', on database 'xxx'.
Perhaps the segment mapping of database has changed recently.
Please inspect the sysusages catalog and contact your system administrator.

---

Je joins le fichier de trace d'exécution de commandes citées ci-dessus.
Qu'en pensez-vous ?

Merci
msomso

Je ne suis pas à 100% sûr - mais essaye de générer de l'activité dans la base, pour que le pointeur du log ce déplace et migre vers le nouveau segment log de la base.

Par "activité", j'entends faire des inserts, updates, etc - même sur des tables bidons que tu peux dropper après...

Michael

Malheureusement ,
le message persiste après les inserts générés ...
msomso