gros interet de la version 2003
cela eviterais des réponses erronées ou trompeuses comme récemment sur
Ca autoriserais aussi des tris plus efficaces via le moteur de recherche
Bonjour,
Je me demandais ou etait stocké les fichiers deposé dans sharepoint.
Comment faire en cas de plantage ?
Merci
gros interet de la version 2003
cela eviterais des réponses erronées ou trompeuses comme récemment sur
Ca autoriserais aussi des tris plus efficaces via le moteur de recherche
Bonjour,
Je me demandais ou etait stocké les fichiers deposé dans sharepoint.
Comment faire en cas de plantage ?
Merci
gros interet de la version 2003
cela eviterais des réponses erronées ou trompeuses comme récemment sur
Ca autoriserais aussi des tris plus efficaces via le moteur de recherche
Bonjour,
Je me demandais ou etait stocké les fichiers deposé dans sharepoint.
Comment faire en cas de plantage ?
Merci
Bonjour,
Je me demandais ou etait stocké les fichiers deposé dans sharepoint.
Comment faire en cas de plantage ?
Merci
Bonjour,
Je me demandais ou etait stocké les fichiers deposé dans sharepoint.
Comment faire en cas de plantage ?
Merci
Bonjour,
Je me demandais ou etait stocké les fichiers deposé dans sharepoint.
Comment faire en cas de plantage ?
Merci
Bonjour,
Il y a 4 bases de donnees :
<portal_name>-SITE content database housing sites in a portal
<portal_name>-PROF profile database containing user profiles
<portal_name>-SERV services database which contains component settings
SPS01_Config_db configuration database containing all portal configuration
data
Toutes les donnees sont stockees dans la base SQL, seul des elments de
l'habillage de SPS et des pages asp sont dans c:
de memoire la table est en doc....
Portail1_PROF 2.50 Mo
Portail1_SERV 3.63 Mo
Portail1_SITE 8.00 Mo
SPS01_Config_db : 2.50 Mo
Et voici la taille de ces memes bases apres l'ajout dun fichier de 14 Mo :
Portail1_PROF 2.50 Mo
Portail1_SERV 3.63 Mo
Portail1_SITE 42.56 Mo
SPS01_Config_db : 2.50 Mo
On remarque que la base Portail1_SITE contient les donnees uploades et
necessite une taille consequente.
Seulement 20 Mo sont utilisee dans la base Portail21_SITE qui fait
maintenant 42.56 MB
Les sites WSS sont par defaut dans la meme base de donnes que le portail.
Eventuellement si des bases de contenus supplementaires ont ete ajoutees,
elles sont presentes sous l'appellation TEAM_DBS
Bonjour,
Il y a 4 bases de donnees :
<portal_name>-SITE content database housing sites in a portal
<portal_name>-PROF profile database containing user profiles
<portal_name>-SERV services database which contains component settings
SPS01_Config_db configuration database containing all portal configuration
data
Toutes les donnees sont stockees dans la base SQL, seul des elments de
l'habillage de SPS et des pages asp sont dans c:
de memoire la table est en doc....
Portail1_PROF 2.50 Mo
Portail1_SERV 3.63 Mo
Portail1_SITE 8.00 Mo
SPS01_Config_db : 2.50 Mo
Et voici la taille de ces memes bases apres l'ajout dun fichier de 14 Mo :
Portail1_PROF 2.50 Mo
Portail1_SERV 3.63 Mo
Portail1_SITE 42.56 Mo
SPS01_Config_db : 2.50 Mo
On remarque que la base Portail1_SITE contient les donnees uploades et
necessite une taille consequente.
Seulement 20 Mo sont utilisee dans la base Portail21_SITE qui fait
maintenant 42.56 MB
Les sites WSS sont par defaut dans la meme base de donnes que le portail.
Eventuellement si des bases de contenus supplementaires ont ete ajoutees,
elles sont presentes sous l'appellation TEAM_DBS
Bonjour,
Il y a 4 bases de donnees :
<portal_name>-SITE content database housing sites in a portal
<portal_name>-PROF profile database containing user profiles
<portal_name>-SERV services database which contains component settings
SPS01_Config_db configuration database containing all portal configuration
data
Toutes les donnees sont stockees dans la base SQL, seul des elments de
l'habillage de SPS et des pages asp sont dans c:
de memoire la table est en doc....
Portail1_PROF 2.50 Mo
Portail1_SERV 3.63 Mo
Portail1_SITE 8.00 Mo
SPS01_Config_db : 2.50 Mo
Et voici la taille de ces memes bases apres l'ajout dun fichier de 14 Mo :
Portail1_PROF 2.50 Mo
Portail1_SERV 3.63 Mo
Portail1_SITE 42.56 Mo
SPS01_Config_db : 2.50 Mo
On remarque que la base Portail1_SITE contient les donnees uploades et
necessite une taille consequente.
Seulement 20 Mo sont utilisee dans la base Portail21_SITE qui fait
maintenant 42.56 MB
Les sites WSS sont par defaut dans la meme base de donnes que le portail.
Eventuellement si des bases de contenus supplementaires ont ete ajoutees,
elles sont presentes sous l'appellation TEAM_DBS
les BDD sont tout aussi maitrisés actuellement que les partages de disqueIl y a même plus d'applis critique qui se basent sur SQL que sur des fichiers plats ... Regardez tout les moteurs de gestion en assurance ou en bancaire : c'est du SQL (Oracle/db2/SQL serveur)
C'est un foncitonnement bien plus complexe que de juste mettre du binaire dans une table
il faut pas penser toujours en mono machine avec 50gigs de disque surtout en mutualisé ;)
Bien formés et équipé , il n y a qu'un risque faible (le risque zero n'existant pas)
les BDD sont tout aussi maitrisés actuellement que les partages de disque
Il y a même plus d'applis critique qui se basent sur SQL que sur des fichiers plats ... Regardez tout les moteurs de gestion en assurance ou en bancaire : c'est du SQL (Oracle/db2/SQL serveur)
C'est un foncitonnement bien plus complexe que de juste mettre du binaire dans une table
il faut pas penser toujours en mono machine avec 50gigs de disque surtout en mutualisé ;)
Bien formés et équipé , il n y a qu'un risque faible (le risque zero n'existant pas)
les BDD sont tout aussi maitrisés actuellement que les partages de disqueIl y a même plus d'applis critique qui se basent sur SQL que sur des fichiers plats ... Regardez tout les moteurs de gestion en assurance ou en bancaire : c'est du SQL (Oracle/db2/SQL serveur)
C'est un foncitonnement bien plus complexe que de juste mettre du binaire dans une table
il faut pas penser toujours en mono machine avec 50gigs de disque surtout en mutualisé ;)
Bien formés et équipé , il n y a qu'un risque faible (le risque zero n'existant pas)
Je ne vous comprends pas
Je suis bien d'accord que la notion de backup restore est assez complexe
plus par le nombre de cas possible que par sa nature
Le but n'est pas de restaurer un doc mais sde remettre en ligne un espace
collaboratif sécurisé et profilé : forcement , les manipulations sont d'un
cran au dessus que d'une simple copie de disque à disque
Sinon je ne vois pas plus de danger à utiliser une base SQL qu'un simple
partage.
de donnée.les BDD sont tout aussi maitrisés actuellement que les partages de
disqueIl y a même plus d'applis critique qui se basent sur SQL que sur des
fichiers plats ... Regardez tout les moteurs de gestion en
assurance ou en bancaire : c'est du SQL (Oracle/db2/SQL serveur)
Moi , je preferes l'approche base de données :
1) meilleur gestion des index !
2)mode transactionnel : un fichier en base est forcement correct car la
transaction la validé
3)outils de BK, montage en cluster , ... bref toute la technologie SQL
offerrtte à ma problématique
Je suis loin de partager l'avis d'Erol qui montre les différences de
tailles
entre les fichiers de baseC'est un foncitonnement bien plus complexe que de juste mettre du
binaire dans une table
il y a le fichier a proprement dit, l'ensemble de ses refenreces ainsiq ue
surtout , sa shadow copy pour la partie indexation et les reservation de
place en edition
Bref l'algo est complexe mais il ne sert que le systéme
Il est clair qu'il faut quand même prevoir un place disque suffisante dans
le cas de systéme de GED, mais ca se chiffre comme le reste (je suis loin
de
la notion de giga, je pense plus haut)il faut pas penser toujours en mono machine avec 50gigs de disque
surtout en mutualisé ;)
Sinon ou est le danger ?
Que 20 personnes accédent à un partage reseau ou utilise un BDD commune,
il
y aura toujours des disques qui vont mouliner (un .mdf n'est qu'un fichier
apres tout)
La charge se gére comme le reste mais uen base de donnée avec son systéme
de
cache est plus a même a repondre en hautre disponibilité que des partages
reseau couplé à un serveur web
Bref, je ne vois pas réellement votre soucis ...
Le seul risque que je vois depend plus de votre équipe d'infrastructure et
de ses compétences en terme de mainteance machine et gestion SPSBien formés et équipé , il n y a qu'un risque faible (le risque zero
n'existant pas)
Ca ne reste toujours qu'une histoire de moyen
Renaud COMTE [MVP]
Je ne vous comprends pas
Je suis bien d'accord que la notion de backup restore est assez complexe
plus par le nombre de cas possible que par sa nature
Le but n'est pas de restaurer un doc mais sde remettre en ligne un espace
collaboratif sécurisé et profilé : forcement , les manipulations sont d'un
cran au dessus que d'une simple copie de disque à disque
Sinon je ne vois pas plus de danger à utiliser une base SQL qu'un simple
partage.
de donnée.
les BDD sont tout aussi maitrisés actuellement que les partages de
disque
Il y a même plus d'applis critique qui se basent sur SQL que sur des
fichiers plats ... Regardez tout les moteurs de gestion en
assurance ou en bancaire : c'est du SQL (Oracle/db2/SQL serveur)
Moi , je preferes l'approche base de données :
1) meilleur gestion des index !
2)mode transactionnel : un fichier en base est forcement correct car la
transaction la validé
3)outils de BK, montage en cluster , ... bref toute la technologie SQL
offerrtte à ma problématique
Je suis loin de partager l'avis d'Erol qui montre les différences de
tailles
entre les fichiers de base
C'est un foncitonnement bien plus complexe que de juste mettre du
binaire dans une table
il y a le fichier a proprement dit, l'ensemble de ses refenreces ainsiq ue
surtout , sa shadow copy pour la partie indexation et les reservation de
place en edition
Bref l'algo est complexe mais il ne sert que le systéme
Il est clair qu'il faut quand même prevoir un place disque suffisante dans
le cas de systéme de GED, mais ca se chiffre comme le reste (je suis loin
de
la notion de giga, je pense plus haut)
il faut pas penser toujours en mono machine avec 50gigs de disque
surtout en mutualisé ;)
Sinon ou est le danger ?
Que 20 personnes accédent à un partage reseau ou utilise un BDD commune,
il
y aura toujours des disques qui vont mouliner (un .mdf n'est qu'un fichier
apres tout)
La charge se gére comme le reste mais uen base de donnée avec son systéme
de
cache est plus a même a repondre en hautre disponibilité que des partages
reseau couplé à un serveur web
Bref, je ne vois pas réellement votre soucis ...
Le seul risque que je vois depend plus de votre équipe d'infrastructure et
de ses compétences en terme de mainteance machine et gestion SPS
Bien formés et équipé , il n y a qu'un risque faible (le risque zero
n'existant pas)
Ca ne reste toujours qu'une histoire de moyen
Renaud COMTE [MVP]
Je ne vous comprends pas
Je suis bien d'accord que la notion de backup restore est assez complexe
plus par le nombre de cas possible que par sa nature
Le but n'est pas de restaurer un doc mais sde remettre en ligne un espace
collaboratif sécurisé et profilé : forcement , les manipulations sont d'un
cran au dessus que d'une simple copie de disque à disque
Sinon je ne vois pas plus de danger à utiliser une base SQL qu'un simple
partage.
de donnée.les BDD sont tout aussi maitrisés actuellement que les partages de
disqueIl y a même plus d'applis critique qui se basent sur SQL que sur des
fichiers plats ... Regardez tout les moteurs de gestion en
assurance ou en bancaire : c'est du SQL (Oracle/db2/SQL serveur)
Moi , je preferes l'approche base de données :
1) meilleur gestion des index !
2)mode transactionnel : un fichier en base est forcement correct car la
transaction la validé
3)outils de BK, montage en cluster , ... bref toute la technologie SQL
offerrtte à ma problématique
Je suis loin de partager l'avis d'Erol qui montre les différences de
tailles
entre les fichiers de baseC'est un foncitonnement bien plus complexe que de juste mettre du
binaire dans une table
il y a le fichier a proprement dit, l'ensemble de ses refenreces ainsiq ue
surtout , sa shadow copy pour la partie indexation et les reservation de
place en edition
Bref l'algo est complexe mais il ne sert que le systéme
Il est clair qu'il faut quand même prevoir un place disque suffisante dans
le cas de systéme de GED, mais ca se chiffre comme le reste (je suis loin
de
la notion de giga, je pense plus haut)il faut pas penser toujours en mono machine avec 50gigs de disque
surtout en mutualisé ;)
Sinon ou est le danger ?
Que 20 personnes accédent à un partage reseau ou utilise un BDD commune,
il
y aura toujours des disques qui vont mouliner (un .mdf n'est qu'un fichier
apres tout)
La charge se gére comme le reste mais uen base de donnée avec son systéme
de
cache est plus a même a repondre en hautre disponibilité que des partages
reseau couplé à un serveur web
Bref, je ne vois pas réellement votre soucis ...
Le seul risque que je vois depend plus de votre équipe d'infrastructure et
de ses compétences en terme de mainteance machine et gestion SPSBien formés et équipé , il n y a qu'un risque faible (le risque zero
n'existant pas)
Ca ne reste toujours qu'une histoire de moyen
Renaud COMTE [MVP]
