Dotaz: PHP+MySQL - update jen urciteho poctu (800) zaznamu scriptem

[Matyáš Dvořák]

Zdravim, po dlouhem hledani chyby v nastaveni php.ini, ve skriptech, v db dotazech jsem narazil na prekerni zalezitost...

PHP skript mi updatuje jen nekolik set zaznamu v mysql a dal se to nehne, tedy vypada to tak, ze se updatuje jen nekolik prvnich radku v tabulce zavisle na poctu sloupcu a jakmile je zaznamu vice, tak se zaktualizuje jen cast tabulky.

Pokud mam 20 radku v tabulce, tak je mozne bezchybne updatovat pouze 40 sloupcu dopredu, tj 800 zaznamu. (prima umernost zde funguje, tudiz pri 5 radcich je mozne aktualizovat 160, coz je zase 800 mysql zaznamu)

Zkousel jsem jestli problem neni na serveru, tak jsem na localhostu jsem zkusebne v php.ini nastavil max_input_vars, post_max_size, max_execution_time i memory_limit na vyssi a posleze i na opravdu vysoke hodnoty a po restartu apache se to chova stale stejne (nacteni konfigurace jsem overil pres phpinfo)

Najde se nejaky odbornik, ktery dokaze poradit, cim by to mohlo byt? Idealne bych potreboval updatovat misto osmiseti zaznamu zaznamu desetkrat tolik. Dekuji za jakekoliv posunuti!

---

---

Odpovědi

[Kit]

Zřejmě budou ty updaty chybně napsány. Nechápu, jak někdo může udělat tabulku se 40 sloupci. To je jako jeden záznam relací 4O atributů?

[Matyáš Dvořák]

Pardón! Blbe jsem to napsal - vystupem je html tabulka kde se jednalo o 20 radku a 40 sloupcu (takovy kalendar) a mysql tabulka vypada takhle:

mysql> describe rezervace;
+--------------+------------------+------+-----+---------+----------------+
| Field        | Type             | Null | Key | Default | Extra          |
+--------------+------------------+------+-----+---------+----------------+
| rezervace_id | int(10) unsigned | NO   | PRI | NULL    | auto_increment | 
| hotel        | int(11)          | NO   |     | NULL    |                | 
| den          | date             | YES  |     | NULL    |                | 
| stav         | smallint(6)      | NO   |     | NULL    |                | 
| jmeno        | varchar(32)      | YES  |     | NULL    |                | 
| pokoje       | smallint(6)      | YES  |     | NULL    |                | 
| obsazenost   | smallint(6)      | YES  |     | NULL    |                | 
| zaskrtnuti   | smallint(6)      | YES  |     | NULL    |                | 
+--------------+------------------+------+-----+---------+----------------+
8 rows in set (0.00 sec)

[Kit]

Není náhodou chyba v HTML formuláři? Pokud tam není

<form method="POST">

tak to odešle metodou GET, u které je omezená délka dotazu.

[Matyáš Dvořák]

samozrejme POST tam je....skript funguje nekolik let bezproblemove, chyba bude nejaka komplikovanejsi se mi zda :(

[R]

Namiesto problemovej mysql_query("blabla") daj die("blabla") - nasledne si tu query skontroluj a pripadne spusti rucne - cez riadkoveho mysql klienta alebo cez phpmyadmin.

[Matyáš Dvořák]

Jednoducha $query = "update rezervace set stav='$stav' where rezervace_id='$rid'"; je fukcni i v terminalu

[R]

Este raz opakujem: nechaj si vypisat celu query, s doplnenymi premennymi, ako sa posiela do MySQL.

[Matyáš Dvořák]

mysql> update rezervace set stav='3' where rezervace_id='215937';

Query OK

[Matlák]

Zajímavé - jestli tomu dobře rozumím, tak na tenhle dotaz MySQL napíše mimo "query ok" taky "affected rows: XXXX" kde XXXX je o hodně větší než 800? A přesně to samé, spuštěné z PHP skriptu, updatuje maximálně 800 a nic víc?

[Matyáš Dvořák]

Dotaz se provadi postupne po jednotlivych ids (nemam tam jeden dotaz pro cely update) a updatuji se jen nektere zaznamy, ktere jsou aktualni..

Vychozi nasimulovana situace kde je ve vsech zaznamech vyplneny stav hodnotou 3 obsahuje 1820 zaznamu, viz:

mysql> select count(*) from rezervace where hotel>=3120 and hotel<=3139;
+----------+
| count(*) |
+----------+
|     1820 | 
+----------+
1 row in set (0.03 sec)

mysql> select count(*) from rezervace where hotel>=3120 and hotel<=3139 and stav='3';
+----------+
| count(*) |
+----------+
|     1820 | 
+----------+
1 row in set (0.00 sec)

Po zmene stavu v rozmezi prvnich 800 zaznamu se update provede:

mysql> -- zmena stavu jednoho sloupce na dvaceti radcich kalendare
mysql> select count(*) from rezervace where hotel>=3120 and hotel<=3139;
+----------+
| count(*) |
+----------+
|     1820 | 
+----------+
1 row in set (0.01 sec)

mysql> select count(*) from rezervace where hotel>=3120 and hotel<=3139 and stav='3';
+----------+
| count(*) |
+----------+
|     1800 | 
+----------+
1 row in set (0.00 sec)

mysql> select count(*) from rezervace where hotel>=3120 and hotel<=3139 and stav='0';
+----------+
| count(*) |
+----------+
|       20 | 
+----------+
1 row in set (0.01 sec)

Tedy, takhle to funguje jak ma.

Pri zmene stavu u zaznamu, kde je problem s updatem, a zmena neprovede se vypisou jen dotazy (echo $query;) z rozmezi prvnich 800, takze odhaduju, ze je problem v php skriptu a nesouvisi to z mysql protoze jinak echo vypsalo relevantni sql queries z rozmezi prvnich 800 a po rozmezi nevypsalo zadne....((

[Matlák]

Pri zmene stavu u zaznamu, kde je problem s updatem, a zmena neprovede se vypisou jen dotazy (echo $query;) z rozmezi prvnich 800, takze odhaduju, ze je problem v php skriptu

Aha. Takže, pokud PHP skript nespadne, a přitom updatuje jen to rozmezí prvních 800, problém není ani v DB, ani v apache, ani v Suhosinu a jiných - nýbrž v tom skriptu. Někde tam je triviální chyba, drobnost která způsobí že se část dotazů "tiše" neprovede. Na to je PHP expertní jazyk.

Doporučuju zpřísnit reportování chyb, sledovat logy, sem tam plácnout nějaký ten error_log() a nebo vůbec vzít pěkně Xdebug a odkrokovat to...

[Šangala]

Tak se podívej do logu, udělej si třeba pomocné echa a víš kde to padá a jak. Jak dlouho to běží (ten skript)?

[Matyáš Dvořák]

bezi asi 0.25 sec

[Kit]

Tohle zřejmě updatuje jen jeden záznam. Nás by zajímal SQL dotaz, který updatuje těch 800 záznamů.

[Matyáš Dvořák]

odpoved viz výše#18

[Kit]

Začínám mít tušení, že na vině bude DoS útok vedený na databázový server.

[Matyáš Dvořák]

To doufam snad ne, protoze na localhostu se to chova stejne :)

[Kit]

Už to tak vypadá. Jestli dobře počítám, tak ten tvůj skript během krátké chvilky vygeneruje 1600 databázových dotazů. To už je útok. Možná jsi narazil na nějaké omezení určené proti útokům tohoto typu.

[Matyáš Dvořák]

Snazim se updatovat jen zaznamy, ktere je potreba updatovat, takze pri zmene stavu u jednoho sloupce se provede jen 20 sql dotazu, ne ze by se updatovalo vsech 1600...o to stara php

[Kit]

Nebylo by lepší updatovat jen ten jeden záznam, který se právě změnil?

[Matyáš Dvořák]

Ano, tak to funguje, jak jsem psal predtim :)

...se provede jen 20 sql dotazu, ne ze by se updatovalo vsech 1600...o to stara php

[Kit]

Myslel jsem z formuláře do PHP skriptu odeslat jen ten jeden záznam. Ne všech 20.

[Matyáš Dvořák]

Diky za podnet, po dlouhem testovani odesilani formu a logovani $_POST jsem zjistil:

1)ze se odesila velke mnozstvi formularovych promennych, rikal jsem si, zda to neni prekrocenim tisice promennych nebo tak neco, co by slo prenastavit v php.ini...zkusil jsem ulozit vystupy do trech souboru a kazdy ma 1208 radku=formularovych promennych.

$ ll bbb*
-rw-r--r--  1 matyas  staff  41964  2 čvc 17:53 bbb_45dni_15augYES.php
-rw-r--r--  1 matyas  staff  41964  2 čvc 17:53 bbb_46dni_16augNO.php
-rw-r--r--  1 matyas  staff  41964  2 čvc 17:53 bbb_47dni_17augNO.php

//poznamka pro me:
//45dni*20=900 zaznamu ANO
//46dni*20=920 zaznamu NEprovede se
//47dni*20=940 zaznamu NEprovede se
//tech 800 bylo teda zaokrouhlene na 40 dni

2) Dal me napadlo, jestli skript neorizne ridici promeny pro switch, dal jsem je tedy na zacatek formu a zmena zadna, takze to musi byt necim jinym.



Problem je, ze bez ohledu na pocet promennych se proste z $_POSTu provede jenom cast, kterou pobere skript, ostatni zustane beze zmeny, pokusim se skript projit rucne zitra, ted uz jsem z tech vsech idcek perplex...

[Šangala]

Jen tak bokem: „dej si ty id-čka do pole…“

[Matyáš Dvořák]

jsou...))

Array
(
    [0] => 3120
    [1] => 2014-07-02r212531
    [2] => 2014-07-03r212532
    ...
    [1197] => 2014-08-28r215567
    [1198] => 2014-08-29r215587
    [1199] => 2014-08-30r215607
)

[Šangala]

To je pole z jedné položky POST-u?

[MMMMMMMMM]

Suhosin?

[MMMMMMMMM]

Jen doplním, že nedávno jsem řešil něco podobného, kdy měl kamarád formulář a ten dokázal updatovat jen 2500 záznamů v jeho formuláři, zbytek ignoroval. Na hostingu měli nastaveno suhosin.request.max_vars = 10000 a kamarád posílal z HTML formuláře 4 položky na záznam a vše zpracovával v PHP přes $_REQUEST, takže 2500*4 = 10000. A víc ani ťuk. :)

[Matyáš Dvořák]

Doplnuju ze "A víc ani ťuk" je presne to same :) akorat je to 800...puvodne jsem myslel, ze by to mohlo byt tim max_input_vars, tak jsem nastavil z 1000 na 5000 a na localu na 10000 a nic..

[Matyáš Dvořák]

Tak suhosin na serveru neni, to vypada

ini_get('suhosin.request.max_vars'):
ini_get('suhosin.post.max_vars'):
ini_get('max_input_vars'):5000

[2X4B-523P]

není problém ve verzi? viz. http://anothersysadmin.wordpress.com/2012/02/16/php-5-3-max_input_vars-and-big-forms/

[Matyáš Dvořák]

Verze na serveru je PHP Version 5.4.28-1~dotdeb.0

[Matyáš Dvořák]

NO KONECNE!!!!

Tak uz vim cim to bylo...demenci v includu uncheck_fix.php z 19 prosince 2010....

1) mel jsem pole vsech (zaskrtnutych, odskrtnutych) rezervaci konkretniho hotelu [0]..[1199]

2) v jinem poli jsem mel zaskrtnute rezervace

3) provedl jsem array_diff na tyto dve pole a ziskal jsem jen odskrtnute rezervace, pole se 40 zaznamy vypadalo takhle:

$odskrtnute_rezervace
(
    [0] => 212531
    [35] => 212776
    [70] => 212899
    [105] => 213022
    [140] => 213145
    ...
    [1196] => 215624
    [1197] => 215625
    [1198] => 215626
    [1199] => 215627
)

4) v includu uncheck_fix.php ktery byl na posledni urovni vnorene funkce, byla obsazena nejake dalsi funkcnost a byl tam cyklus:
for ($i=0;$i<1000;$i++) {...} ktery tedy nevzal id-cka nad index pole 1000, ktere se v poli predavaly pro dalsi zpracovani cyklem, kde byly finalne tvorene sql updaty.



Dekuji vsem moc za pomoc a nejblize problemu byl Matlák, ktery psal:

Někde tam je triviální chyba, drobnost která způsobí že se část dotazů "tiše" neprovede. Na to je PHP expertní jazyk.

[Šangala]

Jen abychom ospravedlnili PHP, tentokrát za to nemůže. :)

[Matyáš Dvořák]

Samozrejme moje historicka demence, PHP je bez viny ;)

[Kit]

Takhle to dopadá, když někdo použije cyklus "for" místo "foreach".

[Matyáš Dvořák]

Presne tak...koukal jsem pro zajimavost ktery prevazujou v minule verzi bylo 250 for a 102 foreach a v nove verzi je 151 for a 68 foreach :)