Cześć
Mam pytanie w kwestii wielkości tablic SAP-owych. Chodzi o MARC, MARD, MARA, LIKP, MSEG, itp. Dotyczące głównie masterdaty i kwestii materiałowo-magazynowych. W tych tablicach SE16N pokazuje mi np. 146 mln (tak milionów) wpisów. Z drugiej strony czytałem, ze SAP zaleca by w tabelach nie było więcej niż 99999 wpisów. Jak to się ma do siebie ? Gdzie jest 100 tyś a gdzie 146 mln ?
Jak jest np. u Was ? Macie też takie ilości ?
U nas jest specyfika retaila i są tworzone tysiące indeksów (unikalnych) rocznie. Każdy jest przypisywany do osobnego składu sklepu, co daje sporą ilosć odchyleń np. w MARC.
A problem zaczyna być, bo w części transakcji magazynowych zaczynamy mieć błędy czy wydajności czy błędnego np. rozdzielania towarów na dostawy.
Takie ilości mogą mieć wpływ ? Czy rozwiązaniem byłaby np. archiwizacja ?
Dzięki z góry za wasze odpowiedzi, pozdrawiam, Michał
Ilości danych w tabelach - dobre praktyki SAP
-
- Posty: 8356
- Rejestracja: wt kwie 03, 2007 4:05 pm
- Has thanked: 1924 times
- Been thanked: 1477 times
- Kontakt:
Re: Ilości danych w tabelach - dobre praktyki SAP
Cześć moim zdaniem dobrą praktyką jest trzymanie w bazie tylko tych danych, które są naprawdę potrzebne. Tutaj nie można powiedzieć, że 100k rekordów jest ok, a 100M już nie. To wszystko zależy od wielkości firmy, rodzaju działalności, branży itd. - słowem od uwarunkowań biznesowych. To jest naturalne, że w retail tworzy się b. dużo indeksów, które mają krótki czas życia. Dobrze zatem byłoby wdrożyć efektywną procedurę archiwizacji danych i wykonywać ją regularnie. Przy uruchamianiu archiwizacji największym wyzwaniem jest uzgodnienie z biznesem czasu retencji poszczególnych dokumentów w systemie. Moim zdaniem archiwizacja nie jest tematem technicznym czy informatycznym, jest przede wszystkim tematem biznesowym i powinna być integralną częścią wdrożenia (najczęściej niestety nie jest), a archiwizowanie i skasowanie z bazy powinno być ostatnim etapem cyklu życia każdego dokumentu w systemie.
Tak naprawdę tylko moc współczesnych baz danych pozwala nam na ignorowanie tematu archiwizacji i trzymanie w systemie wszelkich dokumentów, od samego początku wdrożenia.
Tak naprawdę tylko moc współczesnych baz danych pozwala nam na ignorowanie tematu archiwizacji i trzymanie w systemie wszelkich dokumentów, od samego początku wdrożenia.
-
- Posty: 1061
- Rejestracja: pt mar 14, 2008 12:51 pm
- Has thanked: 71 times
- Been thanked: 315 times
Re: Ilości danych w tabelach - dobre praktyki SAP
To chwalimy się
MARC 2.204.704
MARD 2.742.824
MARA 900.399
LIKP 20.870.210
MSEG 46.156.754
w sumie tych proporcji bym się spodziewał i stosunkowo nie mamy dużego asortymentu ale raczej non stop to samo w dużych ilościach produkcja i handel.
MARC 2.204.704
MARD 2.742.824
MARA 900.399
LIKP 20.870.210
MSEG 46.156.754
w sumie tych proporcji bym się spodziewał i stosunkowo nie mamy dużego asortymentu ale raczej non stop to samo w dużych ilościach produkcja i handel.
-
- Posty: 8356
- Rejestracja: wt kwie 03, 2007 4:05 pm
- Has thanked: 1924 times
- Been thanked: 1477 times
- Kontakt:
Re: Ilości danych w tabelach - dobre praktyki SAP
Od jak dawna używacie SAP, tj. jakie są najstarsze dokumenty materiałowe?
Robiliście już archiwizację?
Robiliście już archiwizację?
-
- Posty: 406
- Rejestracja: pn kwie 13, 2015 10:17 pm
- Lokalizacja: Poznań
- Has thanked: 35 times
- Been thanked: 229 times
Re: Ilości danych w tabelach - dobre praktyki SAP
Z przerostem bazy danych jest trochę jak ze strychem / garażem w niejednym domu Odkładamy niepotrzebne rzeczy dopóki jest miejsce. Z czasem jak potrzebujemy coś znaleźć to poszukiwanie zajmuje coraz więcej czasu i powoli zaczynamy się irytować. Sprzątać zaczynamy jak już mamy wyraźny problem z przemieszczaniem się między stertą niepotrzebnych nikomu rzeczy.
Z moich obserwacji:
1) przerost tabel powoduje wolniejsze działanie niektórych programów. Najszybciej można to zaobserwować w zetowych programach. Źle napisane zapytania do BD z czasem działają coraz wolniej, mogą nawet przestać działać kończąc się time outem. Przy okazji absorbują znaczną część ograniczonych procesów roboczych wpływając na ogólną wydajność systemu.
2) Dane zajmują miejsce na dysku. Miejsce na dysku to dodatkowy koszt dla firmy, zwłaszcza jeśli utrzymanie serwerów zlecamy zewnętrznej firmie.
3) Dane nie zawsze trzeba archiwizować, czasem można je po prostu trwale usunąć z systemu.
Przykład tabele od idoc, których to danych raczej nikt nie będzie analizował klika lat wstecz. W firmach, które wymieniają dużo komunikatów idoc (np. ponad 100 tys. dziennie) te tabele zajmują sporo miejsca.
Można to zrobić zgodnie z notą 1574016 - Deleting idocs with WE11/ RSETESTD.
4) Szybki zbiorczy przegląd, które tabele zajmują najwięcej przestrzeni dyskowej można przeprowadzić w transakcji DB02.
I na koniec, jeśli ktoś nabrał ochoty na wiosenne porządki
SAP database growth control: technical cleanup
Z moich obserwacji:
1) przerost tabel powoduje wolniejsze działanie niektórych programów. Najszybciej można to zaobserwować w zetowych programach. Źle napisane zapytania do BD z czasem działają coraz wolniej, mogą nawet przestać działać kończąc się time outem. Przy okazji absorbują znaczną część ograniczonych procesów roboczych wpływając na ogólną wydajność systemu.
2) Dane zajmują miejsce na dysku. Miejsce na dysku to dodatkowy koszt dla firmy, zwłaszcza jeśli utrzymanie serwerów zlecamy zewnętrznej firmie.
3) Dane nie zawsze trzeba archiwizować, czasem można je po prostu trwale usunąć z systemu.
Przykład tabele od idoc, których to danych raczej nikt nie będzie analizował klika lat wstecz. W firmach, które wymieniają dużo komunikatów idoc (np. ponad 100 tys. dziennie) te tabele zajmują sporo miejsca.
Można to zrobić zgodnie z notą 1574016 - Deleting idocs with WE11/ RSETESTD.
4) Szybki zbiorczy przegląd, które tabele zajmują najwięcej przestrzeni dyskowej można przeprowadzić w transakcji DB02.
I na koniec, jeśli ktoś nabrał ochoty na wiosenne porządki
SAP database growth control: technical cleanup
-
- Posty: 1061
- Rejestracja: pt mar 14, 2008 12:51 pm
- Has thanked: 71 times
- Been thanked: 315 times
Re: Ilości danych w tabelach - dobre praktyki SAP
My będziemy migrować na system Hana więc przy okazji migracji danych będą przenoszone tylko potrzebne dane (minimum do służb skarbowych, pozostałe typu IDoc czy SLG1 pewnie przepadną).
Re: Ilości danych w tabelach - dobre praktyki SAP
Potrzymaj mi piwo ...
MARC 146.562.810
MARD 139.762.502
MARA 568.736
LIKP 1.652.458
MSEG 178.380.496
Czyli coś musimy z tym zrobić ...
pozdrawiam, Michał
-
- Posty: 8356
- Rejestracja: wt kwie 03, 2007 4:05 pm
- Has thanked: 1924 times
- Been thanked: 1477 times
- Kontakt:
Re: Ilości danych w tabelach - dobre praktyki SAP
Zrobiłbym porządną archiwizację przed migracją do S/4HANA - na pewno mniejsza baza danych ułatwi taką migrację.
Również nie musisz zostawiać w bazie danych dokumentów, których przechowywanie jest prawnie wymagane. Większość standardowych transakcji SAP potrafi czytać dokumenty nie tylko z bazy, ale również z plików archiwalnych.
-
- Posty: 8356
- Rejestracja: wt kwie 03, 2007 4:05 pm
- Has thanked: 1924 times
- Been thanked: 1477 times
- Kontakt:
Re: Ilości danych w tabelach - dobre praktyki SAP
Popatrz jeszcze na tablice dot. dokumentów WM - tutaj zwykle jest mnóstwo rekordów, w większości niepotrzebnych oraz np. na IDoc'i. Z Twoich wcześniejszych postów wynika, że intensywnie korzystasz z różnych interfejsów. Te obiekty można szybko i bez bólu zarchiwizować.
Re: Ilości danych w tabelach - dobre praktyki SAP
Tak, masz rację. Wszelkich IDoców też są już pewnie miliony ... No, musimy do tego intensywnie podejść ...dominik.tylczynski pisze: ↑śr lut 05, 2020 8:44 am Popatrz jeszcze na tablice dot. dokumentów WM - tutaj zwykle jest mnóstwo rekordów, w większości niepotrzebnych oraz np. na IDoc'i. Z Twoich wcześniejszych postów wynika, że intensywnie korzystasz z różnych interfejsów. Te obiekty można szybko i bez bólu zarchiwizować.
pozdrawiam, Michał
-
- Posty: 8356
- Rejestracja: wt kwie 03, 2007 4:05 pm
- Has thanked: 1924 times
- Been thanked: 1477 times
- Kontakt:
Re: Ilości danych w tabelach - dobre praktyki SAP
W sumie to normalna sprawa - najpierw uruchamiamy system i się cieszymy, że działa. Potem pakujemy do niego mnóstwo danych i zaczynamy się martwić, że działa jakby wolniej. Wtedy przychodzi myśl o archiwizacji.
-
- Posty: 1061
- Rejestracja: pt mar 14, 2008 12:51 pm
- Has thanked: 71 times
- Been thanked: 315 times
Re: Ilości danych w tabelach - dobre praktyki SAP
tak widziałem już screeny z transakcji rozszerzone o soft kupiony do archiwizacji - na przykład w VA03 pojawia się radio button czy wyświetlić dokumenty z bazy czy z archiwum i wszystko działa dokładnie tak samo - tyle że pewnie z archiwum wolniej będą dane pobierane.dominik.tylczynski pisze: ↑śr lut 05, 2020 8:42 am Również nie musisz zostawiać w bazie danych dokumentów, których przechowywanie jest prawnie wymagane. Większość standardowych transakcji SAP potrafi czytać dokumenty nie tylko z bazy, ale również z plików archiwalnych.
-
- Posty: 1061
- Rejestracja: pt mar 14, 2008 12:51 pm
- Has thanked: 71 times
- Been thanked: 315 times
Re: Ilości danych w tabelach - dobre praktyki SAP
Obstawiam że w EWM, którą mamy już w trzech magazynach, ilość danych będzie dużo bardziej przytłaczająca. Wydanie kilku pojemników do jednego zlecenia produkcyjnego to jest kilka tysięcy zadań magazynowychdominik.tylczynski pisze: ↑śr lut 05, 2020 8:44 am Popatrz jeszcze na tablice dot. dokumentów WM - tutaj zwykle jest mnóstwo rekordów, w większości niepotrzebnych oraz np. na IDoc'i. Z Twoich wcześniejszych postów wynika, że intensywnie korzystasz z różnych interfejsów. Te obiekty można szybko i bez bólu zarchiwizować.
Re: Ilości danych w tabelach - dobre praktyki SAP
Też już patrzyłem, są transakcje do archiwizacji w standardzie ... Czy one są ok ? Bo znów "soft" to mi brzmi jak kolejna kasa ...wojtas7 pisze:
tak widziałem już screeny z transakcji rozszerzone o soft kupiony do archiwizacji - na przykład w VA03 pojawia się radio button czy wyświetlić dokumenty z bazy czy z archiwum i wszystko działa dokładnie tak samo - tyle że pewnie z archiwum wolniej będą dane pobierane.
A ta archiwizacja przeprowadzona "standardowo" nie daje takiej opcji ? Jak jest realizowany dostęp do dokumentów z archiwum ?
pozdrawiam, Michał