streamalism.org

1. Oversikt

Siden Hibernate håndterer samspillet med databasen for oss, kan vi raskt utvikle databaserelatert kode. Men dette kan gjøre feilsøking av databaserelaterte feil vanskelig.

Derfor kan det være nyttig å se samspillet mellom dvalemodus og databasen. For eksempel SQL generert av dvalemodus for å lese data fra en tabell.

I denne opplæringen ser vi de forskjellige nivåene av logging i dvalemodus som kan brukes til å oppnå dette.

2. Logging av SQL

På det mest grunnleggende nivået kan vi logge SQL-setningene generert av dvalemodus uten at de faktiske parameterverdiene sendes til det.

Dvalemodus bruker kategorien org.hibernate.SQL for å logge denne informasjonen. Så alt vi må gjøre er å sette loggningsnivået til denne kategorien til DEBUG.

I Log4J må vi legge til en logger element i konfigurasjonen XML:

På samme måte legger vi til en i Log4J2 Logger element:

Og i Logback vil vi legge til en logger element:

Vi skal nå se den genererte SQL i loggene:

2019-12-07 23:04:23 | DEBUG | [main] o.h.SQL: 127 - sett inn verdier for arbeidstaker (ansattNummer, navn, tittel, id) (?,?,?,?) 2019-12-07 23:04:23 | DEBUG | [hoved] o.h.SQL: 127 - velg ansatt0_.id som id1_0_, ansatt0_.medarbeiderNummer som ansatt2_0_, ansatt0_.navn som navn3_0_, ansatt0_.tittel som tittel4_0_ fra Ansatt ansatt0_

3. Parameterverdier for logging

Selv om den genererte SQL normalt er nok til å identifisere problemer, vil vi kanskje også se parametrene som blir sendt til SQL-setningen.

Dvalemodus logger inngangsparametrene og hentet resultatene ved hjelp av org.hibernate.type.descriptor.sql kategori med loggnivå på SPOR. La oss nå legge til denne kategorien i konfigurasjonsfilene våre.

I Log4J gjør vi:

I Log4J2:

Og til slutt, i Logback:

Derfor bør vi se parameterverdiene overført til SQL-setningen, så vel som resultatet av utførelsen:

2019-12-07 23:04:23 | DEBUG | [main] o.h.SQL: 127 - sett inn verdier for arbeidstaker (ansattNummer, navn, tittel, id) (?,?,?,?) 2019-12-07 23:04:23 | SPOR | [main] o.h.t.d.s.BasicBinder: 64 - binding parameter [1] as [VARCHAR] - [001] 2019-12-07 23:04:23 | SPOR | [main] o.h.t.d.s.BasicBinder: 64 - binding parameter [2] as [VARCHAR] - [John Smith] 2019-12-07 23:04:23 | SPOR | [main] o.h.t.d.s.BasicBinder: 52 - binding parameter [3] as [VARCHAR] - [null] 2019-12-07 23:04:23 | SPOR | [main] o.h.t.d.s.BasicBinder: 64 - binding parameter [4] as [BIGINT] - [1] 2019-12-07 23:04:23 | DEBUG | [hoved] o.h.SQL: 127 - velg ansatt0_.id som id1_0_, ansatt0_.medarbeiderNummer som ansatt2_0_, ansatt0_.navn som navn3_0_, ansatt0_.tittel som tittel4_0_ fra Ansatt ansatt0_ 2019-12-07 23:04:23 | SPOR | [hoved] o.h.t.d.s.BasicExtractor: 60 - utvunnet verdi ([id1_0_]: [BIGINT]) - [1] 2019-12-07 23:04:23 | SPOR | [hoved] o.h.t.d.s.BasicExtractor: 60 - utvunnet verdi ([ansatt2_0_]: [VARCHAR]) - [001] 2019-12-07 23:04:23 | SPOR | [main] o.h.t.d.s.BasicExtractor: 60 - utvunnet verdi ([name3_0_]: [VARCHAR]) - [John Smith] 2019-12-07 23:04:23 | SPOR | [main] o.h.t.d.s.BasicExtractor: 50 - utvunnet verdi ([title4_0_]: [VARCHAR]) - [null]

Det er verdt å merke seg at vi ikke trenger å aktivere org.hibernate.SQL kategori for å se informasjonen ovenfor. Vi kan aktivere og deaktivere de to kategoriene uavhengig.

Men, det er fornuftig å aktivere org.hibernate.SQL slik at vi vet hvilken SQL-setning parameterverdiene forholder seg til.

4. Aktiver dvalemodusstatistikk

Bortsett fra SQL- og JDBC-parameterverdiene, kan Hibernate også logge statistikk for hver SQL-setning. Dette kan være nyttig for å identifisere potensielle ytelsesproblemer.

Dvalemodus bruker kategorien org.hibernate.stat for å logge denne informasjonen. Men dvalemodus genererer ikke alltid denne statistikken fordi den kan ha dårlig innflytelse på ytelsen.

Først, Vi må fortelle dvalemodus å generere denne statistikken ved å sette konfigurasjonsegenskapen dvalemodus.generate_statistics til ekte.

For eksempel kan vi sette denne egenskapen i vår dvalemodus.cfg.xml fil:

ekte

Sammen med denne eiendommen, angi kategorien org.hibernate.stat til DEBUG logger en uttalelse med statistikken for hvert utførte spørsmål. Det vil også logge en loggoppgave med flere linjer på slutten av økten som vil ha oppsummert statistisk informasjon:

2019-12-07 23:25:18 | DEBUG | [main] o.h.s.i.StatisticsInitiator: 101 - Statistikk initialisert [aktivert = sann] 2019-12-07 23:25:19 | DEBUG | [hoved] o.h.s.i.StatisticsImpl: 729 - HHH000117: HQL: fra com.baeldung.hibernate.logging.Ansatt, tid: 22ms, rader: 1 2019-12-07 23:25:19 | INFO | [main] o.h.e.i.StatisticalLoggingSessionEventListener: 258 - Session Metrics {55600 nanosekunder brukt på å skaffe 1 JDBC-tilkobling; 178600 nanosekunder brukte på å frigjøre 1 JDBC-tilkoblinger; 2167200 nanosekunder brukte på å forberede 2 JDBC-uttalelser; 2426800 nanosekunder brukte på å utføre to JDBC-uttalelser; 0 nanosekunder brukt på å utføre 0 JDBC-batcher; 0 nanosekunder brukt på å utføre 0 L2C putter; 0 nanosekunder brukt på å utføre 0 L2C-treff; 0 nanosekunder brukt på å utføre 0 L2C-savner; 47098900 nanosekunder brukt på å utføre 1 spyling (spyling totalt 1 enheter og 0 samlinger); 0 nanosekunder brukt på å utføre 0 delvis skyllinger (spyler totalt 0 enheter og 0 samlinger)}

Legg merke til den første linjen i loggen som indikerer at statistikken er aktivert.

5. Logg all aktivitet

Å grave enda dypere inn i dvalemodusens interaksjon med databasen, vi må aktivere logging for kategorien org. dvale. Denne kategorien inneholder alle meldinger logget av dvalemodus.

Men vi må bruke denne kategorien med forsiktighet, da det kan skape mye loggutdata:

6. Konklusjon

I denne opplæringen så vi de forskjellige nivåene av logging i dvalemodus. Den loggede informasjonen kan være veldig nyttig under utviklingen. Men vi må være forsiktige når vi aktiverer dette i produksjon, da det kan påvirke applikasjonsytelsen negativt.

Og selvfølgelig kan koden som følger med denne opplæringen, bli funnet på GitHub.