IT sviestapika » SQL

MySql SQL vaicājumu monitorings

Kaspars — Wed, 14 Sep 2011 10:18:23 +0000

Dažreiz rodas nepieciešamība paskatīties kādus tieši vaicājumus konkrēta sistēma veic datubāzei.
To pavisam vienkārši var izdarīt MySql konfigurācijas failā iespējojot SQL attēlošanu.
/etc/msql/my.cnf failā atrodam un atspējojam:
general_log_file = /var/log/mysql/mysql.log
general_log =1

//turpat var ieslēgt arī logot tikai vaicājumus, kuri izpildās ilgi
Lai izmaiņas stātos spēkā ir jārestartē MySql:
restart mysql
un skatāmies rezultātu:
tail –f /var/log/mysql/mysql.log
Wordpress sākumlapas attēlošanai veic aptuveni šādus SQL pieprasījumus:

Otrs variants, kā paskatīties SQL, bet neveicot MySql restartu ir mysql konsolē ievadīt:
mysql> SET GLOBAL general_log = ‘ON’;
Query OK, 0 rows affected (0.00 sec)

Tikai tad SQL pieprasījumi tiek ierakstīti citā failā:
tail –f /var/log/mysql/bt.log

Ja ir kāda neskaidrība, kas ir ieslēgts un kurā failā kas tiek rakstīts:
Apskatīt iestatītos logošamans parametrus var:
mysql>show variables like ‘%log%’;

!Jāatceras, ka pati logošana atstāj būtisku iespaidu uz veiktspēju.

Reset MySQL password

Kaspars — Mon, 31 Jan 2011 07:10:50 +0000

Bija nepieciešams pieslēgties MySql serverim, kuram nezināju root paroli.
Izrādās, ka to izdarīt ir vienkāršāk par vienkāršu-
vajag tikai apstādināt servisu, pēc tam to palaist noteiktā režīmā un nomainīt root paroli.
//apstādinām
sudo /etc/init.d/mysql stop vai sudo service mysql stop
//palaižam
sudo mysqld –skip-grant-tables
//piesledzamies kā root
mysql -u root mysql
//nomainām paroli
UPDATE user SET Password=PASSWORD(‘YOURNEWPASSWORD’) WHERE User=’root’; FLUSH PRIVILEGES; exit;

Enable connection logging on Windows

Kaspars — Fri, 21 Jan 2011 10:37:42 +0000

Izmeklējot vienu incidentu atklājās, ka uz MS Windows 2000 servera, kuram virsū stāv MSSQL 2000 nav pieejams logs, kur var redzēt no kuras IP adreses lietotāji cenšas tikt klāt.
MSSQL 2000 admin tools rāda tikai lietotājvārdu, laiku, sekmīgi/nesekmīgi.
MS WIN 2003 rāda tikai tekošās konekcijas.
Iekšējā tīklā router/switch konekciju logs arī nav ieslēgts (pagaidām).
Patreizējais secinājums- nav iespējams izmeklēt, kurš pāris minūtes atpakaļ pamēģināja paminēt SQL paroles.

Lai to novērstu ir pieejami šādi MS risinājumi:
XP, 2000, 2003
Windows Server 2008, Windows Server 2008 R2, Windows Server 7

www.atlaizuklubs.lv SQL kļūda

Kaspars — Wed, 29 Dec 2010 07:54:21 +0000

Šorīt apmeklējot www.atlaizuklubs.lv atklājās medusmaize- SQL kļūdas paziņojums no kuras var izsecināt daļu no datubāzes uzbūves.
Pēc visa spriežot uz servera aptrūkās vieta.
Konkrētā gadījumā izskatās pēc divām klasiskām kļūdām:
1. Nav atslēgta kļūdu izvadīšana (nepieciešama izstrādes posmā, bet ne produkcijas serveros).
2. Un nebija uzstādīts servera disk space monitorings (alerts).

Izraksts no PHP un MySql

Kaspars — Sun, 26 Dec 2010 14:45:35 +0000

Dažas pamat lietas no php.net, lai katru reizi nav jāmeklē kā pārbaudīt vai tabulā ir meklējamie ieraksti.




$conn = mysql_connect("localhost", "mysql_user", "mysql_password");



if (!$conn) {

    echo "Unable to connect to DB: " . mysql_error();

    exit;

}
if (!mysql_select_db("mydbname")) {

    echo "Unable to select mydbname: " . mysql_error();

    exit;

}
$sql = "SELECT id as userid, fullname, userstatus

        FROM   sometable

        WHERE  userstatus = 1";
$result = mysql_query($sql);
if (!$result) {

    echo "Could not successfully run query ($sql) from DB: " . mysql_error();

    exit;

}
if (mysql_num_rows($result) == 0) {

    echo "No rows found, nothing to print so am exiting";

    exit;

}
// While a row of data exists, put that row in $row as an associative array

// Note: If you're expecting just one row, no need to use a loop

// Note: If you put extract($row); inside the following loop, you'll

//       then create $userid, $fullname, and $userstatus

while ($row = mysql_fetch_assoc($result)) {

    echo $row["userid"];

    echo $row["fullname"];

    echo $row["userstatus"];

}
mysql_free_result($result);
?>

PHP funkcija, kas atgriež tekošo URLI

Datubāzes struktūras: mantošana, klasifikācija, arks

Kaspars — Thu, 13 Nov 2008 16:45:04 +0000

Tā nu ir sanācis, ka līdz galam tās atšķirības un līdzibas izpratu vakar, tādēļ ātri jāpieraksta, lai neaizmirstu Ja kas tās ir datu struktūras datubāzēs, kuras izmanot zīmējot ER diagrammas.

Klasifikācija:

Klasifikācijas būtība ir klasificēt pēc kāda no atribūtiem.

Apzīmē to var šādi:

Piez: ar R apzīmē realitāti, un L- lomu

Klasifikācijā iesaistītām lomām ir jābūt homogēnām, tas nozīmē, ka to lauku struktūrām savstarpēji ir jābūt vienādām.

Piem. Ir realitāte (tabula) ar atribūtiem(kolonām): L1,L2,L3 un L4

Un loma L1 un L2 ar atribūtiem: L1,L2,L3

Lomās(tas arī var būt tabulas) vienmēr būs par vienu atribūtu mazāk, jo pēc viena no atribūtiem notiek klasifikācija(nosaka to piederību lomai viens vai divi).

Iepriekšējo piemēru var iedomāties šādi:

Augstāk minētais piemērs fiziski dabā var izskatīties divos veidos:

vai nu no vienas tabulas trasformējot to uz diviem skatiem(vai citam 2 tabulām), tas izskatās šādi:

Kur piemēram skatā S1 būs visas tās rindiņas, kurās laukā L4 bija vērtība1, un skatā S2 būs rindiņas, kurās L4 laukā bija vērtība 2.

vai arī divu tabulu transformācija vienā skatā:

transformāciju vienā skatā var izdarīt ar union tipa vaicājuma palīdzību.

Kuru tieši variantu pārveidojot no ER diagrammas uz reālo datubāzi izmantot nosaka paredzamais vaicājumu biežums. Ja datus vajadzēs apstrādāt sadalīti par lomām, tad pirmais variants, ja kopā tad otrais.

No visa šī var secināt, ka klasifikācija triviāli var iedomāties, kā vaicājums tabulai ar where nosacījumu un atkarībā no tā iegūstam skatu

Mantošana

Mantošana ir tad, kad no vienas realitātes, tiek mantotas kaut kādas vērtības.

Atšķirībā no klasifikācijas, kur lomām bija jābūt vienāda tipa atribūtiem(principā viena tabula), tad pie mantošanas atribūtu skaits(un arī tips) par realitātēm var atšķirties(katra realitā var būt pilnīgi savādāka, tā tikai no augšējās realitātes manto tās atribūtus)

Piemērs:

Realitātei R1 un divi atribūti L1 un L2

Realitātei R2 un četri atribūti L3 un L4 un L5 un L6

Realitātei R3 un trīs atribūti L7 un L8 un L9

Dzīvē tas varētu izskatīties šādi:

Ir divas dažādas tabulās, kurām pievieno klāt vēl vienu tabulu

Vai arī otrs variants apvienot to visu vienā tabulā, tikai tad, tā sastāvēs no 6 atribūtiem un rindiņā kura aprakstīs R1 un R2, būs tukši lauki L7,L8,L9 un otrādi, kuri aprakstīs R1 un R3 būs tukši lauki L3, L4,L5, L6

Arks

Pēc savas būtības ir līdzīgs mantošanai, tikai starp viņiem ir viena būtiska atšķirība:

Mantošanā R1 obligāti pieder arī realitātēm, kuras to manto, taču arka katra rindiņa var vai nu piederēt vienai realitātei vai otrai, abām vienlaicīgi piederēt nevar.

Vizuāli tā atšķirība ir attēlojama šādi:

Paskaidrojums:

Realitātes R1 eksemplārs mantošanas gadījumā pieder abām realitātēm, kas arī izriet no nosaukuma, viņu manto

Arka gadījumā R1 eksemplārs vai nu pieder R2 vai R3, bet abām vienlaicīgi piederēt nevar

Arku līdzīgi, kā mantošanā var iedomāties kā 3() tabulu apvienojumu ar skatu palīdzību

Un otrs variants, kā tabulu R2 un R3 un ar skatiem izgūst vērtības, kas pieder R1

Izvadīt no datubāzes rindiņas, lai katru reizi būtu savādākā secībā

Kaspars — Tue, 28 Oct 2008 14:29:13 +0000

Savajadzējās, lai uztaisītu vienu darbiņu:

Ideāls risinājums ar MySql(testēju uz 5 MySql uz citiem var neiet):

select * tabulas_nosaukums order by rand();

MsSql gadījumā gan būs jāraksta funkcija, piemērs te.

Datubāzes normālformas vai kā projektēt pareizi(papildināts)

Datubāzes normālformas vai kā projektēt pareizi(papildināts)

Kaspars — Sat, 18 Oct 2008 10:10:34 +0000

Kam tas vispar ir vajadzīgs?

Izveidojot datubāzi, kura atbilstu vismaz pirmajām trijām normālformā, mēs atrisinām problēmas, kuras ir saistītas ar informācijas dublēšanos, kā arī ar iespējamām loģiskām un strukturālām uzbūves problēmām, kuras mēdz dēvēt arī par datubāžu anomālijām.

Mīnus normalizācijai ir tāds, ka, tas prasa tabulu sadalīšanu vairākās citās tabulās. Tādēļ, lai pēc tam izgūtu datus no tās ir vajadzīgi vairāku tabulu apvienojumi ar vaicājumiem, kas var samazināt jautājumu izpildes ātrumu.

Anomālijas( problēmas) datubāzēs var būt šādas:

atjauninājuma anomālija
ievietošanas anomālija
dzēšanas anomālija

Atjauninājuma anomālijas piemērs:

Piemēram ir tabula, ar Lietotaja ID, Adresi un Auto. Gadījumā ja lietotājam ir divas vai vairāk automašīnas rodas problēmas:

Lietotaja ID	Adrese	Auto
1	Rīga, Brīvības 5	Audi
2	Rīga, Brīvības 55	BMW
2	Rīga, Brīvības 55	Audi
3	Dobele, kautkas	VW

veicot labošanu lietotāja adresē ir jāatjauno uzreiz divi ieraksti
ja labošanas rezultātā notiek kļūme un nomainās adrese tikai vienā ierakstā un otrā paliks vecā informācija, nebūs iespējams patteikt, kura adrese īsti ir: pirmajā vai otrajā rindiņā

Iespējamais kļūdainās tabulas izskats:

Lietotaja ID	Adrese	Auto
1	Rīga, Brīvības 5	Audi
2	Rīga, Brīvības 55	BMW
2	Rīga, Brīvības 40	Audi
3	Dobele, kautkas	VW

Ievietošanas anomālija:

Tā rodas gadījumos, kad kādu informāciju nevar vispār ievietot,

piemēram, tabula, kura satur datus par reģistrētiem auto(pieņemot, ka katram auto ir jābūt valsts nr. – visi lauki ir obligāti):

ID	Marka	Sasijas num	Valsts nummurzīme
1	Audi	12345	LV-1111
2	BMW	23456	LV-1112
3	VW	34567	LV-1113

Ievietošanas anomālija rodas, tad, kad ir jāievieto dati par vēl neriģestrētu auto, jo tam vēl nav piešķirts valsts nummurs, piemēram, pievienot:

ID	Marka	Sasijas num
4	VW	45678

Tādēļ šādā struktūrā, šādu irakstu ievietot nevar.

Dzēšanas anomālija:

Šāda veida nomālija rodas gadījumā, kad viena fakta dzēšanas rezultātā tiek pazaudēta informācija pa visma par citu faktu, piemēram, ja tiek dzēsta valsts numurzīme LV-1111no datubāzes(iepriekšējais piemērs)(delete from table where vn=lv-1111), tad automātiskie tik dzēsta informācija arī par reģistrēto pašu auto, kas nedrīkstētu notikt.

Normālformas :

1 NF

Tabula atbilst pirmajai normālformai tad un tikai tad, kad visi tās kolonas(domēni) satur atomāras(nedalāmas vērtības)

Ja vērtību var sadalī vairākās daļās un tai nezūd jēga tad vērtība ir neatomāra.

Bieži jebkura vērtība var būt gan atomāra, gan neatomāra, pimēram skaitlis: 1234 ir:

atomāra vērtība, ja ar to sparot pin kodu
neatomāra vērtība, ja ar to saprot atsevišķu skaitļu rindu no 1 līdz 4

Skaitļu rinda var būt gan 12 un 34, kā arī samainīta vietām 43 un 21, un skaitļu jēga no tā nemainīsies. Tur pretīm jā samainīs pinkoda skaitļus vietām jēga skaitļiem vairs nav.

Neatomāras bieži pielietojamas vērtības piemērs ir adrese, kuru glabā vienā laukā, piem,

Pilsēta, Iela, Māja

2NF:

tabulai jāatbilst 1 NF

Tabula atbilst otrajai normālformai, ja katrs neprimārais atslēgas lauks ir atkarīgs no visas primārās atslēgas. (Nevis no primārās atslēgas kādas daļās).

Otrajai normālformai nozīme ir tikai realitātēs, kurās ir sarežģīta primārā atslēga(piem, sastāv no diviem laukiem), ja tabulai ir viena konkrēta primārā atslēga, tad tāda tabula jau autmātiski atbilst 2. normālformai, vai vienkāršiem vārdiem- tabulā nedrīkstētu būt divi atribūti, kas varētu būt kā primārie lauki.

*EmployeeID	LastName	FirstName	*ProjectNumber	ProjectTitle
EN1-26	O’Brien	Sean	30-452-T3	STAR manual
EN1-26	O’Brien	Sean	30-457-T3	ISO procedures
EN1-26	O’Brien	Sean	31-124-T3	Employee handbook
EN1-33	Guya	Amy	30-452-T3	STAR manual
EN1-33	Guya	Amy	30-482-TC	Web Site
EN1-33	Guya	Amy	31-241-TC	New catalog

Lai atrisinātu šo problēmu ir jārīkojas sekojoši:

Identificēt atribūtus, kuri ir atkarīgi tikai no primārās atslēgas daļas
Izveidot jaunu realitāti
Ievietot identificētos atribūtus jaunajā realitātē
Izveidot sasaisti starp veco un jauno realitāti

Šinī gadījumā, pirmārā atslēga varētu būt EmployeelID un ProjectNumber, tādēļ tie ir jāsadala:

EMPLOYEES

*EmployeeID	Last Name	First Name
EN1-26	O’Brien	Sean
EN1-33	Guya	Amy
EN1-35	Baranco	Steven
EN1-36	Roslyn	Elizabeth

EMPLOYEES_PROJECTS

*EmployeeID	*ProjectNum
EN1-26	30-452-T3
EN1-26	30-457-T3
EN1-26	31-124-T3
EN1-33	30-328-TC
EN1-33	30-452-T3

PROJECTS

*ProjectNum	ProjectTitle
30-452-T3	STAR manual
30-457-T3	ISO procedures
30-482-TC	Web site
31-124-T3	Employee handbook
31-238-TC	STAR prototype

3NF

Tabula apmierina trešo normālformu, ja tā apmierina otro NF un katrs ne primārais atslēgas lauks ir ne tranzistīvi atkarīgs no primārās atslēgas.

No matemātikas viedokļa nedrīkstētu sanākt, ka x->x un z->x, jo sanāk ka z->y, jo z->x->y.

(Nedrīkst būt situācija, kad ir saikne(attiecības) starp diviem vai vairākiem neprimāriem laukiem)

Piemēram:

id	Vārds	Kabinets	Telefons
1	Kaspars	101	02
2	Jānis	102	03
3	Kaspars	102	03

Šinī situācijā, pieņem, ka:

viens telefona nummurs(nav primārā atslēga) var būt pieslēgts vienā kabinetā(nav primārā atslēga)
un viens cilvēks var atrasties vairākos kabinetos

Rezultātā sanāk, ka telefons ir atkarīgs ne tikai no primārās atslēgas, bet arī no kabineta, kas nav primārā atslēga

Lai atrisinātu šādas problēmas ir jārīkojas šādi:

Jāpārnes savā starpā saistītos noprimāros atribūtus uz jaunu realitāti(tabulu) saglabājot saikni viņu starpā
Izmantot lauku, kurš noteica atkarību kā primāro lauku
Izveidot sasaisti starp veco un jauno realitāti

Tādēļ, lai apmierinātu 3 NF vajadzētu sadaīt šādi

Vārds	Kabinets
Kaspars	101
Jānis	102
Kaspars	102

Kabinets	Telefons
101	02
102	03

Šinī tabulā kabineta nummurs, jau var būt par primāro atslēgu

Kā darbināt linux aplikācijas Windows vidē-andLinux