Kangs a écrit 260 commentaires

Sous Linux, avec git version 2.13.1 ces 2 commandes offres un GUI. Ils sont écrits en tcl/tk.
Je ne sais pas si sous Windows ils sont disponibles, mais je serais surpris si ce n'était pas le cas.

Il me semble bien plus probable que ce soit un fan ou un troll, et peut-être même quelqu’un qui a déjà un >(autre) compte sur LinuxFr, mais qui n’a pas voulu entamer son karma ou sa réputation, sachant qu’un tel >journal se ferait descendre d’une part par les inconditionnels de systemd et d’autre part par tous ceux >qui ne tolèrent pas les contenus courts (rappel : au début, Da Linux French Page*, c’était des contenus >courts).

Dans les 2 cas il n'est pas normale qu'il puisse poster un journal.
S'il n'est pas capable d'assumer ces propos qu'il se taise.

Il y a 14 ans, elle était déjà obsolète et sans intérêt.

J'ai pas de RHEL 6 sous la main mais tu devrais trouver les paquets à installer en faisant

yum provides libasound.so.2
et
yum provides libXtst.so.6

Ensuite tu fais un yum install le_nom_du_paquet

Je viens de voir que les sondages avaient disparus. Tu n'en parles pas ?
Par curiosité pourquoi ?

Je croyais que l'export était consistent depuis la v8 (d'ailleurs il y avait une option pour cela)

Je ne l'ai jamais vu utilisé et ne l'ai jamais utilisé moi même (n'utilisant qu'au minimum exp/imp), mais sur une grosse base ou une base fortement sollicitée : l'export est trop impactant et l'import quasi impossible.
imp/exp ne fonctionnait pas sur une base spatiale (sans d'affreuses bidouilles) et peut être avec d'autre bases ayant des options particulières.

Quels problèmes as tu rencontré avec les exports / imports ? le renommage des TBS ? le volume des données ? ou autre ?
cela m’intéressent beaucoup

Les exports/imports sont extrêmement lents, les tables sont réalimentés, les indexes recréés (ou pas), les contraintes validées (ou pas) et j'en oublie…
Tout ça fait que l'import peut durée des jours et tu risques ensuite de passer des jours à rendre la base 100% opérationnelles (création d'index, activation contraintes & co).
Vers 2004 sur un AIX4/Oracle 9i (certes l'OS était obsolète) reconstruire un index en // de 60 ou 70Gb prenait 48h (et il y en avait bcp). La restauration full de la base via rman ~7h.

Sur les grosses bases imp/exp pas possible. Datapump est beaucoup plus performant, mais lors de la restauration tu n'auras pas physiquement la même base (donc des requêtes plus performantes ou d'autre moins performantes en gros c'est une loterie)

Par contre pour nous c'est un élément de la sauvegarde, car dans certains cas tordus nos devs préfèrent que l'on >remonte une table d'un export (même de la veille) pour qu'ils puissent refaire la (ou les) table(s) endommagée(s)

J'ai déjà vu ça et je n'aime pas trop cette solution, depuis là 11g tu peux garantir la rétention du flashback, restaurer une tables via la requête ci-dessus me semble mieux et l'espace supplémentaire sera certainement inférieur à l'espace des exports (la compression datapump est payante).
De plus tu n'es capable de 'restaurer' qu'à la date de ton export (pas de recovery), comment valider les dumps (corruption & co), combien de dumps garder, … ?
Je connais peu d'applications qui peuvent se permette de perdre 1 ou plusieurs journées en particulier un ERP.

Datapump peut servir à bcp de choses (extraction d'un subset de la base, transfert de données, migrations …) mais ce n'est pas un outil de restauration.

C'est exploitable, pour une restauration on préférera effectuer un flashback de la table pour dès histoires de contraintes d'intégrités (pour être sur que la requête ci dessus fonctionne on ne peut de toute façon pas se reposer sur l'undo donc il faut le flashback d'activé)

Avant même le flashback on pouvait restaurer une table, la manipulation était lourde (en 12c elle est simplifiée), les exports/imports n'étaient pas fiables, datapump est devenu consistent mais n'apporte strictement rien pour une sauvegarde.

Pourquoi ?

Sans vouloir être trop indiscret…

Vu les versions je n'ai plus aucun mal à te croire, depuis la 10g RMAN est, ama, vraiment fiable une fois correctement configuré.

et les précédente aussi (un script qui "oublie" certains fichiers..).

C'est trop gros, ou alors changer de DBA…

Pour information, la version 5.1.12 de VirtualBox corrige le problème.
Pour les versions précédentes il fallait désactiver kvmclock & co.

Mon impression est que seul le host (ou une seule VM si le host ne le fait pas) doit gérer la synchronisation parce qu'il n'y a qu'une seul horloge. Cette horloge unique est utilisée aussi bien par le host que les VM.

Tu fais un choix, tu synchronises ta VM sur le host ou tu utilises ntp, avoir les 2 mécanismes n'est pas bon. Mais attention, au moins sur VBox et VmWare, la synchro par le host est bourrin.

Autrement, j'ai vu sur une de mes VM des messages d'erreur de systemd qui n'arrivait pas à communiquer avec des serveurs ntp (le port est fermé).

Donc tu n'utilises pas ntp pour la synchro.

Oui, c'est une très mauvaise idée d'avoir 2 mécanismes de synchronisation.
La synchronisation via le 'host' n'est viable que pour une VM simple communiquant peu, il est vraiment préférable de synchroniser via chrony (ntp c'est plus compliqué).

Non, je n'ai pas le choix, le soft détecte la présence de ntp. Si pas de ntp pas de soft et chrony et fortement n'est pas supporté. (Il existe une alternative, mais mon problème c'est qu'est ce qui fait que ntp dérive)
RedHat conseille chrony surtout parce-que c'est son soft maison, mais il est le premier à expliquer comment désinstaller chrony pour utiliser ntp et à faire des "Best Practices" et pas que pour Oracle.

Je n'est pas le choix.

J'utilise VirtualBox, sans aucun 'Guest Additions'.
Le problème se produit indépendamment de l'activité.

Au niveau de VirtualBox j'ai activé hpet, mais je n'ai pas vus de changement.

Si je résume le problème, sans ntpd d'actif l'horloge avance très rapidement.
Quand ntp est actif, il n'arrive plus au bout de 5 à 8mn à synchroniser l'horloge et elle se met à avancer très rapidement.

Ce qui me surprend le plus c'est que chrony fonctionne très bien, mais dans la doc RedHat il est fortement conseillé d'utiliser chrony sur une VM.

Un cours d'apprentissage doit aussi te permettre de comprendre des bouquins, les termes rvalue et lvalue sont très souvent utilisés. Alors au minimum, je pense qu'un cour de C ou C++ doit en parler.

Merci de éclaircissement sur les lvalues et rvalues ainsi que les nouveautés.
De mon point de vue, ces définitions devraient être expliquées et apprissent dès le début, on lès voit partout.
Perso dans mes cours de C et de pseudo C++ (années 90), ces définitions n'étaient jamais données, par la suite lire des bouquins "d'expert" (en anglais) devenait vite compliqué à lire.

Moi je ferais l'effort d'essayer de comprendre, mais je sens que ça va me prendre du temps…

Oui, ils sont sur MacOS.

Maintenant je comprends ta blague ;)

Je sais c'est restreint, mais je serais vraiment curieux de connaître le type de contenu de la dépêche et les raisons de la réclamation et de la demande de fermeture ?

Attention je crois que ça ne fonctionne que sur un même FS…

Elles proviennent de mes collègues développeurs C++ dont Ziyue, Florent B et AKP :-D
https://github.com/cpp-frug/materials/blob/gh-pages/images/README.md

Vraiment rigolo :)
Continuez….

J'utilise bash comme shell :

[kangs<x2305:~]$ cat /etc/os-release
NAME=openSUSE
VERSION="13.2 (Harlequin)"
VERSION_ID="13.2"
PRETTY_NAME="openSUSE 13.2 (Harlequin) (x86_64)"

ID=opensuse

ANSI_COLOR="0;32"

CPE_NAME="cpe:/o:opensuse:opensuse:13.2"

BUG_REPORT_URL="https://bugs.opensuse.org"

HOME_URL="https://opensuse.org/"

ID_LIKE="suse"

[kangs<x2305:~]$ uname -a

Linux kangs 3.16.7-35-desktop #1 SMP PREEMPT Sun Feb 7 17:32:21 UTC 2016 (832c776) x86_64 x86_64 x86_64 GNU/Linux

[kangs<x2305:~]$ perl -v

This is perl 5, version 20, subversion 1 (v5.20.1) built for x86_64-linux-thread-multi