[Met_help] [rt.rap.ucar.edu #87080] History for METviewer loading problem

Wed Jul 10 16:43:18 MDT 2019

----------------------------------------------------------------
  Initial Request
----------------------------------------------------------------

Hello.  I was loading some VSDB files into METviewer last night, 
starting around  23:17Z.  It took a long time - at 16:10Z today I killed 
the job (NCO wants us to reboot our workstations) thinking it probably 
finished a long time ago and just got stuck in the end.  But apparently 
it was still going, slowly, despite of a string of error messages.

Here's what I did to load the data after su to "metviewer":

cd /metviewer/staging/wd22yl

/usr1/metviewer/metviewer/bin/mv_load.sh load_late.xml > 
out.load/loadlog.20180920_mv_ylin_pcp

the 'loadlog' file was last updated at 15:57 today (13 minutes before I 
killed the job).    Could you tell me what's wrong? load_late.xml is the 
same job script that I use to add data every week or so.

Earlier yesterday I loaded some point_stat stat files (in 
/metviewer/staging/wd22yl/tmp.out, I did 
"/usr1/metviewer/metviewer/bin/mv_load.sh 
../scripts/load_new_point_stat.xml > load.out"), that took rather a long 
time too and had some "communications link failure", but the stats were 
apparently loaded into the database successfully.

Also - I have a cron job that loads one day's VSDB every day: 
/metviewer/staging/wd22yl/run_daily_erly.csh > 
/metviewer/staging/wd22yl/out.load/erly.out.  That one apparently took 2 
hours too (longer than normal) and erly.out also have lots of errors.

Thanks -

Ying

-- 
Ying Lin
NCEP/EMC/Verification, Post-processing and Product Generation Branch
NCWCP Cubicle No. 2015
Ying.Lin at noaa.gov

----------------------------------------------------------------
  Complete Ticket History
----------------------------------------------------------------

Subject: METviewer loading problem
From: Tatiana Burek
Time: Fri Sep 21 10:49:11 2018

Ying,
The issues you experience could be related to MySQL reaching it's size
limit.
Is there any way to check the disk space left value of the volume
where MySQL is installed?

Tatiana

On Fri Sep 21 10:32:16 2018, ying.lin at noaa.gov wrote:
> Hello.  I was loading some VSDB files into METviewer last night,
> starting around  23:17Z.  It took a long time - at 16:10Z today I
killed
> the job (NCO wants us to reboot our workstations) thinking it
probably
> finished a long time ago and just got stuck in the end.  But
apparently
> it was still going, slowly, despite of a string of error messages.
>
> Here's what I did to load the data after su to "metviewer":
>
> cd /metviewer/staging/wd22yl
>
> /usr1/metviewer/metviewer/bin/mv_load.sh load_late.xml >
> out.load/loadlog.20180920_mv_ylin_pcp
>
> the 'loadlog' file was last updated at 15:57 today (13 minutes
before I
> killed the job).    Could you tell me what's wrong? load_late.xml is
the
> same job script that I use to add data every week or so.
>
> Earlier yesterday I loaded some point_stat stat files (in
> /metviewer/staging/wd22yl/tmp.out, I did
> "/usr1/metviewer/metviewer/bin/mv_load.sh
> ../scripts/load_new_point_stat.xml > load.out"), that took rather a
long
> time too and had some "communications link failure", but the stats
were
> apparently loaded into the database successfully.
>
> Also - I have a cron job that loads one day's VSDB every day:
> /metviewer/staging/wd22yl/run_daily_erly.csh >
> /metviewer/staging/wd22yl/out.load/erly.out.  That one apparently
took 2
> hours too (longer than normal) and erly.out also have lots of
errors.
>
>
> Thanks -
>
> Ying
>
>
>

------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #87080] METviewer loading problem
From: Ying Lin
Time: Fri Sep 21 11:18:53 2018

Hi Tatiana,

     Thanks for the quick reply.  I found on
vm-lnx-metviewdev-db1.ncep.noaa.gov that /var/lib/mysql is 100% full. 
I
can't check which database under /var/lib/mysql though, and when I
attempted to "su -i -u metviewer" I got "wd22yl is not in the sudoers
file.  This incident will be reported."

     I dug through some old emails, and saw one from Kirk Holub from
Jun
2017 that "On mv-lnx-metviewdev-process1, the file '/tmp/mvDB_status'
shows usage by 'mv_' database."  I assume it's vm-lnx-metviewdev
(there's no mv-lnx...), but there isn't a /tmp/mvDB_status file.

     Can you, as superuser, find out which databases on /var/lib/mysql
are taking up too much space?

     Thanks -

Ying

On 09/21/2018 12:49 PM, Tatiana Burek via RT wrote:
> Ying,
> The issues you experience could be related to MySQL reaching it's
size limit.
> Is there any way to check the disk space left value of the volume
where MySQL is installed?
>
> Tatiana
>
> On Fri Sep 21 10:32:16 2018, ying.lin at noaa.gov wrote:
>> Hello.  I was loading some VSDB files into METviewer last night,
>> starting around  23:17Z.  It took a long time - at 16:10Z today I
killed
>> the job (NCO wants us to reboot our workstations) thinking it
probably
>> finished a long time ago and just got stuck in the end.  But
apparently
>> it was still going, slowly, despite of a string of error messages.
>>
>> Here's what I did to load the data after su to "metviewer":
>>
>> cd /metviewer/staging/wd22yl
>>
>> /usr1/metviewer/metviewer/bin/mv_load.sh load_late.xml >
>> out.load/loadlog.20180920_mv_ylin_pcp
>>
>> the 'loadlog' file was last updated at 15:57 today (13 minutes
before I
>> killed the job).    Could you tell me what's wrong? load_late.xml
is the
>> same job script that I use to add data every week or so.
>>
>> Earlier yesterday I loaded some point_stat stat files (in
>> /metviewer/staging/wd22yl/tmp.out, I did
>> "/usr1/metviewer/metviewer/bin/mv_load.sh
>> ../scripts/load_new_point_stat.xml > load.out"), that took rather a
long
>> time too and had some "communications link failure", but the stats
were
>> apparently loaded into the database successfully.
>>
>> Also - I have a cron job that loads one day's VSDB every day:
>> /metviewer/staging/wd22yl/run_daily_erly.csh >
>> /metviewer/staging/wd22yl/out.load/erly.out.  That one apparently
took 2
>> hours too (longer than normal) and erly.out also have lots of
errors.
>>
>>
>> Thanks -
>>
>> Ying
>>
>>
>>
>
>

--
Ying Lin
NCEP/EMC/Verification, Post-processing and Product Generation Branch
NCWCP Cubicle No. 2015
Ying.Lin at noaa.gov

------------------------------------------------
Subject: METviewer loading problem
From: perry.shafran at noaa.gov
Time: Fri Sep 21 11:20:57 2018

I'm pretty sure that mine is the largest one.

Perry

On Fri, Sep 21, 2018 at 1:18 PM Ying Lin <ying.lin at noaa.gov> wrote:

> Hi Tatiana,
>
>      Thanks for the quick reply.  I found on
> vm-lnx-metviewdev-db1.ncep.noaa.gov that /var/lib/mysql is 100%
full.  I
> can't check which database under /var/lib/mysql though, and when I
> attempted to "su -i -u metviewer" I got "wd22yl is not in the
sudoers
> file.  This incident will be reported."
>
>      I dug through some old emails, and saw one from Kirk Holub from
Jun
> 2017 that "On mv-lnx-metviewdev-process1, the file
'/tmp/mvDB_status'
> shows usage by 'mv_' database."  I assume it's vm-lnx-metviewdev
> (there's no mv-lnx...), but there isn't a /tmp/mvDB_status file.
>
>      Can you, as superuser, find out which databases on
/var/lib/mysql
> are taking up too much space?
>
>      Thanks -
>
> Ying
>
>
>
>
> On 09/21/2018 12:49 PM, Tatiana Burek via RT wrote:
> > Ying,
> > The issues you experience could be related to MySQL reaching it's
size
> limit.
> > Is there any way to check the disk space left value of the volume
where
> MySQL is installed?
> >
> > Tatiana
> >
> > On Fri Sep 21 10:32:16 2018, ying.lin at noaa.gov wrote:
> >> Hello.  I was loading some VSDB files into METviewer last night,
> >> starting around  23:17Z.  It took a long time - at 16:10Z today I
killed
> >> the job (NCO wants us to reboot our workstations) thinking it
probably
> >> finished a long time ago and just got stuck in the end.  But
apparently
> >> it was still going, slowly, despite of a string of error
messages.
> >>
> >> Here's what I did to load the data after su to "metviewer":
> >>
> >> cd /metviewer/staging/wd22yl
> >>
> >> /usr1/metviewer/metviewer/bin/mv_load.sh load_late.xml >
> >> out.load/loadlog.20180920_mv_ylin_pcp
> >>
> >> the 'loadlog' file was last updated at 15:57 today (13 minutes
before I
> >> killed the job).    Could you tell me what's wrong? load_late.xml
is the
> >> same job script that I use to add data every week or so.
> >>
> >> Earlier yesterday I loaded some point_stat stat files (in
> >> /metviewer/staging/wd22yl/tmp.out, I did
> >> "/usr1/metviewer/metviewer/bin/mv_load.sh
> >> ../scripts/load_new_point_stat.xml > load.out"), that took rather
a long
> >> time too and had some "communications link failure", but the
stats were
> >> apparently loaded into the database successfully.
> >>
> >> Also - I have a cron job that loads one day's VSDB every day:
> >> /metviewer/staging/wd22yl/run_daily_erly.csh >
> >> /metviewer/staging/wd22yl/out.load/erly.out.  That one apparently
took 2
> >> hours too (longer than normal) and erly.out also have lots of
errors.
> >>
> >>
> >> Thanks -
> >>
> >> Ying
> >>
> >>
> >>
> >
> >
>
> --
> Ying Lin
> NCEP/EMC/Verification, Post-processing and Product Generation Branch
> NCWCP Cubicle No. 2015
> Ying.Lin at noaa.gov
>
>
>

------------------------------------------------
Subject: METviewer loading problem
From: perry.shafran at noaa.gov
Time: Fri Sep 21 11:35:47 2018

I ran a mysql command that Kirk had demonstrated how to get the size
of
various mysql databases.  By *FAR*, the largest database is my
database
mv_emc_g2o, which I think will need to be cut to size.

I think that I want to delete all but the past, oh, say, 6 months
worth of
data from this database.  Before I do so, I'd like to ask Ben if I can
cut
all from this database except the past 3 months.  That would clear out
a
lot of room.

Can anyone advise me how to clear data from a database?  I'm sure it's
been
demonstrated, but I don't remember.

Perry

On Fri, Sep 21, 2018 at 1:18 PM Ying Lin <ying.lin at noaa.gov> wrote:

> Hi Tatiana,
>
>      Thanks for the quick reply.  I found on
> vm-lnx-metviewdev-db1.ncep.noaa.gov that /var/lib/mysql is 100%
full.  I
> can't check which database under /var/lib/mysql though, and when I
> attempted to "su -i -u metviewer" I got "wd22yl is not in the
sudoers
> file.  This incident will be reported."
>
>      I dug through some old emails, and saw one from Kirk Holub from
Jun
> 2017 that "On mv-lnx-metviewdev-process1, the file
'/tmp/mvDB_status'
> shows usage by 'mv_' database."  I assume it's vm-lnx-metviewdev
> (there's no mv-lnx...), but there isn't a /tmp/mvDB_status file.
>
>      Can you, as superuser, find out which databases on
/var/lib/mysql
> are taking up too much space?
>
>      Thanks -
>
> Ying
>
>
>
>
> On 09/21/2018 12:49 PM, Tatiana Burek via RT wrote:
> > Ying,
> > The issues you experience could be related to MySQL reaching it's
size
> limit.
> > Is there any way to check the disk space left value of the volume
where
> MySQL is installed?
> >
> > Tatiana
> >
> > On Fri Sep 21 10:32:16 2018, ying.lin at noaa.gov wrote:
> >> Hello.  I was loading some VSDB files into METviewer last night,
> >> starting around  23:17Z.  It took a long time - at 16:10Z today I
killed
> >> the job (NCO wants us to reboot our workstations) thinking it
probably
> >> finished a long time ago and just got stuck in the end.  But
apparently
> >> it was still going, slowly, despite of a string of error
messages.
> >>
> >> Here's what I did to load the data after su to "metviewer":
> >>
> >> cd /metviewer/staging/wd22yl
> >>
> >> /usr1/metviewer/metviewer/bin/mv_load.sh load_late.xml >
> >> out.load/loadlog.20180920_mv_ylin_pcp
> >>
> >> the 'loadlog' file was last updated at 15:57 today (13 minutes
before I
> >> killed the job).    Could you tell me what's wrong? load_late.xml
is the
> >> same job script that I use to add data every week or so.
> >>
> >> Earlier yesterday I loaded some point_stat stat files (in
> >> /metviewer/staging/wd22yl/tmp.out, I did
> >> "/usr1/metviewer/metviewer/bin/mv_load.sh
> >> ../scripts/load_new_point_stat.xml > load.out"), that took rather
a long
> >> time too and had some "communications link failure", but the
stats were
> >> apparently loaded into the database successfully.
> >>
> >> Also - I have a cron job that loads one day's VSDB every day:
> >> /metviewer/staging/wd22yl/run_daily_erly.csh >
> >> /metviewer/staging/wd22yl/out.load/erly.out.  That one apparently
took 2
> >> hours too (longer than normal) and erly.out also have lots of
errors.
> >>
> >>
> >> Thanks -
> >>
> >> Ying
> >>
> >>
> >>
> >
> >
>
> --
> Ying Lin
> NCEP/EMC/Verification, Post-processing and Product Generation Branch
> NCWCP Cubicle No. 2015
> Ying.Lin at noaa.gov
>
>
>

------------------------------------------------
Subject: METviewer loading problem
From: Tatiana Burek
Time: Fri Sep 21 11:37:03 2018

These are the largest databases:
| table_schema               | Data Base Size in MB |
| mv_jah_emc_g2o             |       11977.49656487 |
| mv_emc_g2o2                |       12275.60431862 |
| mv_ylin_pcp                |       14404.04145241 |
| mv_met_dl2rw               |       15345.15241528 |
| mv_g2g_vsdb_ens            |       16617.03862095 |
| mv_emc_metvsvsdb           |       21196.60622025 |
| mv_emc_g2o                 |      248886.72011662 |

Tatiana

On Fri Sep 21 11:20:57 2018, perry.shafran at noaa.gov wrote:
> I'm pretty sure that mine is the largest one.
>
> Perry
>
> On Fri, Sep 21, 2018 at 1:18 PM Ying Lin <ying.lin at noaa.gov> wrote:
>
> > Hi Tatiana,
> >
> > Thanks for the quick reply.  I found on
> > vm-lnx-metviewdev-db1.ncep.noaa.gov that /var/lib/mysql is 100%
full.
> > I
> > can't check which database under /var/lib/mysql though, and when I
> > attempted to "su -i -u metviewer" I got "wd22yl is not in the
sudoers
> > file.  This incident will be reported."
> >
> > I dug through some old emails, and saw one from Kirk Holub from
Jun
> > 2017 that "On mv-lnx-metviewdev-process1, the file
'/tmp/mvDB_status'
> > shows usage by 'mv_' database."  I assume it's vm-lnx-metviewdev
> > (there's no mv-lnx...), but there isn't a /tmp/mvDB_status file.
> >
> > Can you, as superuser, find out which databases on /var/lib/mysql
> > are taking up too much space?
> >
> > Thanks -
> >
> > Ying
> >
> >
> >
> >
> > On 09/21/2018 12:49 PM, Tatiana Burek via RT wrote:
> > > Ying,
> > > The issues you experience could be related to MySQL reaching
it's
> > > size
> > limit.
> > > Is there any way to check the disk space left value of the
volume
> > > where
> > MySQL is installed?
> > >
> > > Tatiana
> > >
> > > On Fri Sep 21 10:32:16 2018, ying.lin at noaa.gov wrote:
> > >> Hello.  I was loading some VSDB files into METviewer last
night,
> > >> starting around  23:17Z.  It took a long time - at 16:10Z today
I
> > >> killed
> > >> the job (NCO wants us to reboot our workstations) thinking it
> > >> probably
> > >> finished a long time ago and just got stuck in the end.  But
> > >> apparently
> > >> it was still going, slowly, despite of a string of error
messages.
> > >>
> > >> Here's what I did to load the data after su to "metviewer":
> > >>
> > >> cd /metviewer/staging/wd22yl
> > >>
> > >> /usr1/metviewer/metviewer/bin/mv_load.sh load_late.xml >
> > >> out.load/loadlog.20180920_mv_ylin_pcp
> > >>
> > >> the 'loadlog' file was last updated at 15:57 today (13 minutes
> > >> before I
> > >> killed the job).    Could you tell me what's wrong?
load_late.xml
> > >> is the
> > >> same job script that I use to add data every week or so.
> > >>
> > >> Earlier yesterday I loaded some point_stat stat files (in
> > >> /metviewer/staging/wd22yl/tmp.out, I did
> > >> "/usr1/metviewer/metviewer/bin/mv_load.sh
> > >> ../scripts/load_new_point_stat.xml > load.out"), that took
rather
> > >> a long
> > >> time too and had some "communications link failure", but the
stats
> > >> were
> > >> apparently loaded into the database successfully.
> > >>
> > >> Also - I have a cron job that loads one day's VSDB every day:
> > >> /metviewer/staging/wd22yl/run_daily_erly.csh >
> > >> /metviewer/staging/wd22yl/out.load/erly.out.  That one
apparently
> > >> took 2
> > >> hours too (longer than normal) and erly.out also have lots of
> > >> errors.
> > >>
> > >>
> > >> Thanks -
> > >>
> > >> Ying
> > >>
> > >>
> > >>
> > >
> > >
> >
> > --
> > Ying Lin
> > NCEP/EMC/Verification, Post-processing and Product Generation
Branch
> > NCWCP Cubicle No. 2015
> > Ying.Lin at noaa.gov
> >
> >
> >

------------------------------------------------
Subject: METviewer loading problem
From: Tatiana Burek
Time: Fri Sep 21 11:42:00 2018

Perry,
To trim database data you can use mv_prune module.
Here you can find the instruction how to use it:
http://www.dtcenter.org/met/metviewer/doc/database_scrubbing.html

Tatiana

On Fri Sep 21 11:35:47 2018, perry.shafran at noaa.gov wrote:
> I ran a mysql command that Kirk had demonstrated how to get the size
> of
> various mysql databases.  By *FAR*, the largest database is my
> database
> mv_emc_g2o, which I think will need to be cut to size.
>
> I think that I want to delete all but the past, oh, say, 6 months
> worth of
> data from this database.  Before I do so, I'd like to ask Ben if I
can
> cut
> all from this database except the past 3 months.  That would clear
out
> a
> lot of room.
>
> Can anyone advise me how to clear data from a database?  I'm sure
it's
> been
> demonstrated, but I don't remember.
>
> Perry
>
> On Fri, Sep 21, 2018 at 1:18 PM Ying Lin <ying.lin at noaa.gov> wrote:
>
> > Hi Tatiana,
> >
> > Thanks for the quick reply.  I found on
> > vm-lnx-metviewdev-db1.ncep.noaa.gov that /var/lib/mysql is 100%
full.
> > I
> > can't check which database under /var/lib/mysql though, and when I
> > attempted to "su -i -u metviewer" I got "wd22yl is not in the
sudoers
> > file.  This incident will be reported."
> >
> > I dug through some old emails, and saw one from Kirk Holub from
Jun
> > 2017 that "On mv-lnx-metviewdev-process1, the file
'/tmp/mvDB_status'
> > shows usage by 'mv_' database."  I assume it's vm-lnx-metviewdev
> > (there's no mv-lnx...), but there isn't a /tmp/mvDB_status file.
> >
> > Can you, as superuser, find out which databases on /var/lib/mysql
> > are taking up too much space?
> >
> > Thanks -
> >
> > Ying
> >
> >
> >
> >
> > On 09/21/2018 12:49 PM, Tatiana Burek via RT wrote:
> > > Ying,
> > > The issues you experience could be related to MySQL reaching
it's
> > > size
> > limit.
> > > Is there any way to check the disk space left value of the
volume
> > > where
> > MySQL is installed?
> > >
> > > Tatiana
> > >
> > > On Fri Sep 21 10:32:16 2018, ying.lin at noaa.gov wrote:
> > >> Hello.  I was loading some VSDB files into METviewer last
night,
> > >> starting around  23:17Z.  It took a long time - at 16:10Z today
I
> > >> killed
> > >> the job (NCO wants us to reboot our workstations) thinking it
> > >> probably
> > >> finished a long time ago and just got stuck in the end.  But
> > >> apparently
> > >> it was still going, slowly, despite of a string of error
messages.
> > >>
> > >> Here's what I did to load the data after su to "metviewer":
> > >>
> > >> cd /metviewer/staging/wd22yl
> > >>
> > >> /usr1/metviewer/metviewer/bin/mv_load.sh load_late.xml >
> > >> out.load/loadlog.20180920_mv_ylin_pcp
> > >>
> > >> the 'loadlog' file was last updated at 15:57 today (13 minutes
> > >> before I
> > >> killed the job).    Could you tell me what's wrong?
load_late.xml
> > >> is the
> > >> same job script that I use to add data every week or so.
> > >>
> > >> Earlier yesterday I loaded some point_stat stat files (in
> > >> /metviewer/staging/wd22yl/tmp.out, I did
> > >> "/usr1/metviewer/metviewer/bin/mv_load.sh
> > >> ../scripts/load_new_point_stat.xml > load.out"), that took
rather
> > >> a long
> > >> time too and had some "communications link failure", but the
stats
> > >> were
> > >> apparently loaded into the database successfully.
> > >>
> > >> Also - I have a cron job that loads one day's VSDB every day:
> > >> /metviewer/staging/wd22yl/run_daily_erly.csh >
> > >> /metviewer/staging/wd22yl/out.load/erly.out.  That one
apparently
> > >> took 2
> > >> hours too (longer than normal) and erly.out also have lots of
> > >> errors.
> > >>
> > >>
> > >> Thanks -
> > >>
> > >> Ying
> > >>
> > >>
> > >>
> > >
> > >
> >
> > --
> > Ying Lin
> > NCEP/EMC/Verification, Post-processing and Product Generation
Branch
> > NCWCP Cubicle No. 2015
> > Ying.Lin at noaa.gov
> >
> >
> >

------------------------------------------------
Subject: METviewer loading problem
From: Benjamin Blake - NOAA Affiliate
Time: Fri Sep 21 11:45:07 2018

Hi Perry,

That's fine with me if you want to clear out old data from the
mv_emc_g2o
database.

I haven't tried doing this in a while but I was able to do it in the
past.
I think the command for removing data is the following:
/usr1/metviewer/metviewer/bin/mv_prune.sh prune_db_spec_file

There is an example prune_db_spec_file in the /usr1/metviewer/shared
directory and here's a link with more information which may help:
http://www.dtcenter.org/met/metviewer/doc/database_scrubbing.html

Thanks,
Ben

On Fri, Sep 21, 2018 at 1:35 PM, Perry Shafran - NOAA Affiliate <
perry.shafran at noaa.gov> wrote:

> I ran a mysql command that Kirk had demonstrated how to get the size
of
> various mysql databases.  By *FAR*, the largest database is my
database
> mv_emc_g2o, which I think will need to be cut to size.
>
> I think that I want to delete all but the past, oh, say, 6 months
worth of
> data from this database.  Before I do so, I'd like to ask Ben if I
can cut
> all from this database except the past 3 months.  That would clear
out a
> lot of room.
>
> Can anyone advise me how to clear data from a database?  I'm sure
it's
> been demonstrated, but I don't remember.
>
> Perry
>
> On Fri, Sep 21, 2018 at 1:18 PM Ying Lin <ying.lin at noaa.gov> wrote:
>
>> Hi Tatiana,
>>
>>      Thanks for the quick reply.  I found on
>> vm-lnx-metviewdev-db1.ncep.noaa.gov that /var/lib/mysql is 100%
full.  I
>> can't check which database under /var/lib/mysql though, and when I
>> attempted to "su -i -u metviewer" I got "wd22yl is not in the
sudoers
>> file.  This incident will be reported."
>>
>>      I dug through some old emails, and saw one from Kirk Holub
from Jun
>> 2017 that "On mv-lnx-metviewdev-process1, the file
'/tmp/mvDB_status'
>> shows usage by 'mv_' database."  I assume it's vm-lnx-metviewdev
>> (there's no mv-lnx...), but there isn't a /tmp/mvDB_status file.
>>
>>      Can you, as superuser, find out which databases on
/var/lib/mysql
>> are taking up too much space?
>>
>>      Thanks -
>>
>> Ying
>>
>>
>>
>>
>> On 09/21/2018 12:49 PM, Tatiana Burek via RT wrote:
>> > Ying,
>> > The issues you experience could be related to MySQL reaching it's
size
>> limit.
>> > Is there any way to check the disk space left value of the volume
where
>> MySQL is installed?
>> >
>> > Tatiana
>> >
>> > On Fri Sep 21 10:32:16 2018, ying.lin at noaa.gov wrote:
>> >> Hello.  I was loading some VSDB files into METviewer last night,
>> >> starting around  23:17Z.  It took a long time - at 16:10Z today
I
>> killed
>> >> the job (NCO wants us to reboot our workstations) thinking it
probably
>> >> finished a long time ago and just got stuck in the end.  But
apparently
>> >> it was still going, slowly, despite of a string of error
messages.
>> >>
>> >> Here's what I did to load the data after su to "metviewer":
>> >>
>> >> cd /metviewer/staging/wd22yl
>> >>
>> >> /usr1/metviewer/metviewer/bin/mv_load.sh load_late.xml >
>> >> out.load/loadlog.20180920_mv_ylin_pcp
>> >>
>> >> the 'loadlog' file was last updated at 15:57 today (13 minutes
before I
>> >> killed the job).    Could you tell me what's wrong?
load_late.xml is
>> the
>> >> same job script that I use to add data every week or so.
>> >>
>> >> Earlier yesterday I loaded some point_stat stat files (in
>> >> /metviewer/staging/wd22yl/tmp.out, I did
>> >> "/usr1/metviewer/metviewer/bin/mv_load.sh
>> >> ../scripts/load_new_point_stat.xml > load.out"), that took
rather a
>> long
>> >> time too and had some "communications link failure", but the
stats were
>> >> apparently loaded into the database successfully.
>> >>
>> >> Also - I have a cron job that loads one day's VSDB every day:
>> >> /metviewer/staging/wd22yl/run_daily_erly.csh >
>> >> /metviewer/staging/wd22yl/out.load/erly.out.  That one
apparently
>> took 2
>> >> hours too (longer than normal) and erly.out also have lots of
errors.
>> >>
>> >>
>> >> Thanks -
>> >>
>> >> Ying
>> >>
>> >>
>> >>
>> >
>> >
>>
>> --
>> Ying Lin
>> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
>> NCWCP Cubicle No. 2015
>> Ying.Lin at noaa.gov
>>
>>
>>

------------------------------------------------
Subject: METviewer loading problem
From: perry.shafran at noaa.gov
Time: Fri Sep 21 11:47:46 2018

OK, that should help.  I'll prune my database.

Perry

On Fri, Sep 21, 2018 at 1:45 PM Benjamin Blake - NOAA Affiliate <
benjamin.blake at noaa.gov> wrote:

> Hi Perry,
>
> That's fine with me if you want to clear out old data from the
mv_emc_g2o
> database.
>
> I haven't tried doing this in a while but I was able to do it in the
> past.  I think the command for removing data is the following:
> /usr1/metviewer/metviewer/bin/mv_prune.sh prune_db_spec_file
>
> There is an example prune_db_spec_file in the /usr1/metviewer/shared
> directory and here's a link with more information which may help:
> http://www.dtcenter.org/met/metviewer/doc/database_scrubbing.html
>
> Thanks,
> Ben
>
> On Fri, Sep 21, 2018 at 1:35 PM, Perry Shafran - NOAA Affiliate <
> perry.shafran at noaa.gov> wrote:
>
>> I ran a mysql command that Kirk had demonstrated how to get the
size of
>> various mysql databases.  By *FAR*, the largest database is my
database
>> mv_emc_g2o, which I think will need to be cut to size.
>>
>> I think that I want to delete all but the past, oh, say, 6 months
worth
>> of data from this database.  Before I do so, I'd like to ask Ben if
I can
>> cut all from this database except the past 3 months.  That would
clear out
>> a lot of room.
>>
>> Can anyone advise me how to clear data from a database?  I'm sure
it's
>> been demonstrated, but I don't remember.
>>
>> Perry
>>
>> On Fri, Sep 21, 2018 at 1:18 PM Ying Lin <ying.lin at noaa.gov> wrote:
>>
>>> Hi Tatiana,
>>>
>>>      Thanks for the quick reply.  I found on
>>> vm-lnx-metviewdev-db1.ncep.noaa.gov that /var/lib/mysql is 100%
full.
>>> I
>>> can't check which database under /var/lib/mysql though, and when I
>>> attempted to "su -i -u metviewer" I got "wd22yl is not in the
sudoers
>>> file.  This incident will be reported."
>>>
>>>      I dug through some old emails, and saw one from Kirk Holub
from Jun
>>> 2017 that "On mv-lnx-metviewdev-process1, the file
'/tmp/mvDB_status'
>>> shows usage by 'mv_' database."  I assume it's vm-lnx-metviewdev
>>> (there's no mv-lnx...), but there isn't a /tmp/mvDB_status file.
>>>
>>>      Can you, as superuser, find out which databases on
/var/lib/mysql
>>> are taking up too much space?
>>>
>>>      Thanks -
>>>
>>> Ying
>>>
>>>
>>>
>>>
>>> On 09/21/2018 12:49 PM, Tatiana Burek via RT wrote:
>>> > Ying,
>>> > The issues you experience could be related to MySQL reaching
it's size
>>> limit.
>>> > Is there any way to check the disk space left value of the
volume
>>> where MySQL is installed?
>>> >
>>> > Tatiana
>>> >
>>> > On Fri Sep 21 10:32:16 2018, ying.lin at noaa.gov wrote:
>>> >> Hello.  I was loading some VSDB files into METviewer last
night,
>>> >> starting around  23:17Z.  It took a long time - at 16:10Z today
I
>>> killed
>>> >> the job (NCO wants us to reboot our workstations) thinking it
probably
>>> >> finished a long time ago and just got stuck in the end.  But
>>> apparently
>>> >> it was still going, slowly, despite of a string of error
messages.
>>> >>
>>> >> Here's what I did to load the data after su to "metviewer":
>>> >>
>>> >> cd /metviewer/staging/wd22yl
>>> >>
>>> >> /usr1/metviewer/metviewer/bin/mv_load.sh load_late.xml >
>>> >> out.load/loadlog.20180920_mv_ylin_pcp
>>> >>
>>> >> the 'loadlog' file was last updated at 15:57 today (13 minutes
before
>>> I
>>> >> killed the job).    Could you tell me what's wrong?
load_late.xml is
>>> the
>>> >> same job script that I use to add data every week or so.
>>> >>
>>> >> Earlier yesterday I loaded some point_stat stat files (in
>>> >> /metviewer/staging/wd22yl/tmp.out, I did
>>> >> "/usr1/metviewer/metviewer/bin/mv_load.sh
>>> >> ../scripts/load_new_point_stat.xml > load.out"), that took
rather a
>>> long
>>> >> time too and had some "communications link failure", but the
stats
>>> were
>>> >> apparently loaded into the database successfully.
>>> >>
>>> >> Also - I have a cron job that loads one day's VSDB every day:
>>> >> /metviewer/staging/wd22yl/run_daily_erly.csh >
>>> >> /metviewer/staging/wd22yl/out.load/erly.out.  That one
apparently
>>> took 2
>>> >> hours too (longer than normal) and erly.out also have lots of
errors.
>>> >>
>>> >>
>>> >> Thanks -
>>> >>
>>> >> Ying
>>> >>
>>> >>
>>> >>
>>> >
>>> >
>>>
>>> --
>>> Ying Lin
>>> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
>>> NCWCP Cubicle No. 2015
>>> Ying.Lin at noaa.gov
>>>
>>>
>>>
>

------------------------------------------------
Subject: METviewer loading problem
From: perry.shafran at noaa.gov
Time: Fri Sep 21 11:58:39 2018

It looks like the prune script is running but I guess I'll have to
wait to
find out.

Perry

On Fri, Sep 21, 2018 at 1:47 PM Perry Shafran - NOAA Affiliate <
perry.shafran at noaa.gov> wrote:

> OK, that should help.  I'll prune my database.
>
> Perry
>
> On Fri, Sep 21, 2018 at 1:45 PM Benjamin Blake - NOAA Affiliate <
> benjamin.blake at noaa.gov> wrote:
>
>> Hi Perry,
>>
>> That's fine with me if you want to clear out old data from the
mv_emc_g2o
>> database.
>>
>> I haven't tried doing this in a while but I was able to do it in
the
>> past.  I think the command for removing data is the following:
>> /usr1/metviewer/metviewer/bin/mv_prune.sh prune_db_spec_file
>>
>> There is an example prune_db_spec_file in the
/usr1/metviewer/shared
>> directory and here's a link with more information which may help:
>> http://www.dtcenter.org/met/metviewer/doc/database_scrubbing.html
>>
>> Thanks,
>> Ben
>>
>> On Fri, Sep 21, 2018 at 1:35 PM, Perry Shafran - NOAA Affiliate <
>> perry.shafran at noaa.gov> wrote:
>>
>>> I ran a mysql command that Kirk had demonstrated how to get the
size of
>>> various mysql databases.  By *FAR*, the largest database is my
database
>>> mv_emc_g2o, which I think will need to be cut to size.
>>>
>>> I think that I want to delete all but the past, oh, say, 6 months
worth
>>> of data from this database.  Before I do so, I'd like to ask Ben
if I can
>>> cut all from this database except the past 3 months.  That would
clear out
>>> a lot of room.
>>>
>>> Can anyone advise me how to clear data from a database?  I'm sure
it's
>>> been demonstrated, but I don't remember.
>>>
>>> Perry
>>>
>>> On Fri, Sep 21, 2018 at 1:18 PM Ying Lin <ying.lin at noaa.gov>
wrote:
>>>
>>>> Hi Tatiana,
>>>>
>>>>      Thanks for the quick reply.  I found on
>>>> vm-lnx-metviewdev-db1.ncep.noaa.gov that /var/lib/mysql is 100%
full.
>>>> I
>>>> can't check which database under /var/lib/mysql though, and when
I
>>>> attempted to "su -i -u metviewer" I got "wd22yl is not in the
sudoers
>>>> file.  This incident will be reported."
>>>>
>>>>      I dug through some old emails, and saw one from Kirk Holub
from
>>>> Jun
>>>> 2017 that "On mv-lnx-metviewdev-process1, the file
'/tmp/mvDB_status'
>>>> shows usage by 'mv_' database."  I assume it's vm-lnx-metviewdev
>>>> (there's no mv-lnx...), but there isn't a /tmp/mvDB_status file.
>>>>
>>>>      Can you, as superuser, find out which databases on
/var/lib/mysql
>>>> are taking up too much space?
>>>>
>>>>      Thanks -
>>>>
>>>> Ying
>>>>
>>>>
>>>>
>>>>
>>>> On 09/21/2018 12:49 PM, Tatiana Burek via RT wrote:
>>>> > Ying,
>>>> > The issues you experience could be related to MySQL reaching
it's
>>>> size limit.
>>>> > Is there any way to check the disk space left value of the
volume
>>>> where MySQL is installed?
>>>> >
>>>> > Tatiana
>>>> >
>>>> > On Fri Sep 21 10:32:16 2018, ying.lin at noaa.gov wrote:
>>>> >> Hello.  I was loading some VSDB files into METviewer last
night,
>>>> >> starting around  23:17Z.  It took a long time - at 16:10Z
today I
>>>> killed
>>>> >> the job (NCO wants us to reboot our workstations) thinking it
>>>> probably
>>>> >> finished a long time ago and just got stuck in the end.  But
>>>> apparently
>>>> >> it was still going, slowly, despite of a string of error
messages.
>>>> >>
>>>> >> Here's what I did to load the data after su to "metviewer":
>>>> >>
>>>> >> cd /metviewer/staging/wd22yl
>>>> >>
>>>> >> /usr1/metviewer/metviewer/bin/mv_load.sh load_late.xml >
>>>> >> out.load/loadlog.20180920_mv_ylin_pcp
>>>> >>
>>>> >> the 'loadlog' file was last updated at 15:57 today (13 minutes
>>>> before I
>>>> >> killed the job).    Could you tell me what's wrong?
load_late.xml is
>>>> the
>>>> >> same job script that I use to add data every week or so.
>>>> >>
>>>> >> Earlier yesterday I loaded some point_stat stat files (in
>>>> >> /metviewer/staging/wd22yl/tmp.out, I did
>>>> >> "/usr1/metviewer/metviewer/bin/mv_load.sh
>>>> >> ../scripts/load_new_point_stat.xml > load.out"), that took
rather a
>>>> long
>>>> >> time too and had some "communications link failure", but the
stats
>>>> were
>>>> >> apparently loaded into the database successfully.
>>>> >>
>>>> >> Also - I have a cron job that loads one day's VSDB every day:
>>>> >> /metviewer/staging/wd22yl/run_daily_erly.csh >
>>>> >> /metviewer/staging/wd22yl/out.load/erly.out.  That one
apparently
>>>> took 2
>>>> >> hours too (longer than normal) and erly.out also have lots of
errors.
>>>> >>
>>>> >>
>>>> >> Thanks -
>>>> >>
>>>> >> Ying
>>>> >>
>>>> >>
>>>> >>
>>>> >
>>>> >
>>>>
>>>> --
>>>> Ying Lin
>>>> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
>>>> NCWCP Cubicle No. 2015
>>>> Ying.Lin at noaa.gov
>>>>
>>>>
>>>>
>>

------------------------------------------------
Subject: METviewer loading problem
From: perry.shafran at noaa.gov
Time: Fri Sep 21 12:18:44 2018

I don't think it worked for whatever reason.
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException:
Communications
link failure

Last packet sent to the server was 16 ms ago.
>From table data_file deleted 0 records.
java.sql.SQLException: Connection has already been closed.
>From table line_data_cnt deleted 0 records.
java.sql.SQLException: Connection has already been closed.
>From table line_data_ctc deleted 0 records.
java.sql.SQLException: Connection has already been closed.
>From table line_data_cts deleted 0 records.
java.sql.SQLException: Connection has already been closed.
>From tables line_data_eclv and line_data_eclv_pnt deleted 0 records.
java.sql.SQLException: Connection has already been closed.
>From table line_data_enscnt deleted 0 records.
java.sql.SQLException: Connection has already been closed.
>From table line_data_fho deleted 0 records.
java.sql.SQLException: Connection has already been closed.
>From table line_data_isc deleted 0 records.
java.sql.SQLException: Connection has already been closed.
>From tables line_data_mctc and line_data_mctc_cnt deleted 0 records.
java.sql.SQLException: Connection has already been closed.
>From table line_data_mcts deleted 0 records.
java.sql.SQLException: Connection has already been closed.
>From table line_data_mpr deleted 0 records.
java.sql.SQLException: Connection has already been closed.
>From table line_data_nbrcnt deleted 0 records.
java.sql.SQLException: Connection has already been closed.
>From table line_data_nbrctc deleted 0 records.
java.sql.SQLException: Connection has already been closed.
>From table line_data_nbrcts deleted 0 records.
java.sql.SQLException: Connection has already been closed.
>From tables line_data_orank and line_data_orank_ens deleted 0 records.
java.sql.SQLException: Connection has already been closed.
>From tables line_data_pct and line_data_pct_thresh deleted 0 records.
java.sql.SQLException: Connection has already been closed.
>From tables line_data_phist and line_data_phist_bin deleted 0 records.
java.sql.SQLException: Connection has already been closed.
>From tables line_data_pjc and line_data_pjc_thresh deleted 0 records.
java.sql.SQLException: Connection has already been closed.
>From tables line_data_prc and line_data_prc_thresh deleted 0 records.
java.sql.SQLException: Connection has already been closed.
>From tables line_data_pstd and line_data_pstd_thresh deleted 0
records.
java.sql.SQLException: Connection has already been closed.
>From tables line_data_relp and line_data_relp_ens deleted 0 records.
java.sql.SQLException: Connection has already been closed.
>From tables line_data_rhist and line_data_rhist_rank deleted 0
records.
java.sql.SQLException: Connection has already been closed.
>From table line_data_sal1l2 deleted 0 records.
java.sql.SQLException: Connection has already been closed.
>From table line_data_sl1l2 deleted 0 records.
java.sql.SQLException: Connection has already been closed.
>From table line_data_ssvar deleted 0 records.
java.sql.SQLException: Connection has already been closed.
>From table line_data_val1l2 deleted 0 records.
java.sql.SQLException: Connection has already been closed.
>From table line_data_vl1l2 deleted 0 records.
java.sql.SQLException: Connection has already been closed.
>From table mode_cts deleted 0 records.
java.sql.SQLException: Connection has already been closed.
>From table mode_obj_pair deleted 0 records.
java.sql.SQLException: Connection has already been closed.
>From table mode_obj_single deleted 0 records.
Total deleted 0 records
java.sql.SQLException: Connection has already been closed.
>From stat_header table was deleted  0 records
java.sql.SQLException: Connection has already been closed.
>From mode_header table was deleted  0 records
----  MVPruneDB Done  ----
[metviewer at vm-lnx-metviewdev-process1 ~]$

Can someone please help?  My prune script is
prune_db_spec_file_wd20ps.  Is
there a problem with this?  I just want to remove using certain dates.

Thanks!

Perry

On Fri, Sep 21, 2018 at 1:58 PM Perry Shafran - NOAA Affiliate <
perry.shafran at noaa.gov> wrote:

> It looks like the prune script is running but I guess I'll have to
wait to
> find out.
>
> Perry
>
> On Fri, Sep 21, 2018 at 1:47 PM Perry Shafran - NOAA Affiliate <
> perry.shafran at noaa.gov> wrote:
>
>> OK, that should help.  I'll prune my database.
>>
>> Perry
>>
>> On Fri, Sep 21, 2018 at 1:45 PM Benjamin Blake - NOAA Affiliate <
>> benjamin.blake at noaa.gov> wrote:
>>
>>> Hi Perry,
>>>
>>> That's fine with me if you want to clear out old data from the
>>> mv_emc_g2o database.
>>>
>>> I haven't tried doing this in a while but I was able to do it in
the
>>> past.  I think the command for removing data is the following:
>>> /usr1/metviewer/metviewer/bin/mv_prune.sh prune_db_spec_file
>>>
>>> There is an example prune_db_spec_file in the
/usr1/metviewer/shared
>>> directory and here's a link with more information which may help:
>>> http://www.dtcenter.org/met/metviewer/doc/database_scrubbing.html
>>>
>>> Thanks,
>>> Ben
>>>
>>> On Fri, Sep 21, 2018 at 1:35 PM, Perry Shafran - NOAA Affiliate <
>>> perry.shafran at noaa.gov> wrote:
>>>
>>>> I ran a mysql command that Kirk had demonstrated how to get the
size of
>>>> various mysql databases.  By *FAR*, the largest database is my
database
>>>> mv_emc_g2o, which I think will need to be cut to size.
>>>>
>>>> I think that I want to delete all but the past, oh, say, 6 months
worth
>>>> of data from this database.  Before I do so, I'd like to ask Ben
if I can
>>>> cut all from this database except the past 3 months.  That would
clear out
>>>> a lot of room.
>>>>
>>>> Can anyone advise me how to clear data from a database?  I'm sure
it's
>>>> been demonstrated, but I don't remember.
>>>>
>>>> Perry
>>>>
>>>> On Fri, Sep 21, 2018 at 1:18 PM Ying Lin <ying.lin at noaa.gov>
wrote:
>>>>
>>>>> Hi Tatiana,
>>>>>
>>>>>      Thanks for the quick reply.  I found on
>>>>> vm-lnx-metviewdev-db1.ncep.noaa.gov that /var/lib/mysql is 100%
>>>>> full.  I
>>>>> can't check which database under /var/lib/mysql though, and when
I
>>>>> attempted to "su -i -u metviewer" I got "wd22yl is not in the
sudoers
>>>>> file.  This incident will be reported."
>>>>>
>>>>>      I dug through some old emails, and saw one from Kirk Holub
from
>>>>> Jun
>>>>> 2017 that "On mv-lnx-metviewdev-process1, the file
'/tmp/mvDB_status'
>>>>> shows usage by 'mv_' database."  I assume it's vm-lnx-metviewdev
>>>>> (there's no mv-lnx...), but there isn't a /tmp/mvDB_status file.
>>>>>
>>>>>      Can you, as superuser, find out which databases on
/var/lib/mysql
>>>>> are taking up too much space?
>>>>>
>>>>>      Thanks -
>>>>>
>>>>> Ying
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 09/21/2018 12:49 PM, Tatiana Burek via RT wrote:
>>>>> > Ying,
>>>>> > The issues you experience could be related to MySQL reaching
it's
>>>>> size limit.
>>>>> > Is there any way to check the disk space left value of the
volume
>>>>> where MySQL is installed?
>>>>> >
>>>>> > Tatiana
>>>>> >
>>>>> > On Fri Sep 21 10:32:16 2018, ying.lin at noaa.gov wrote:
>>>>> >> Hello.  I was loading some VSDB files into METviewer last
night,
>>>>> >> starting around  23:17Z.  It took a long time - at 16:10Z
today I
>>>>> killed
>>>>> >> the job (NCO wants us to reboot our workstations) thinking it
>>>>> probably
>>>>> >> finished a long time ago and just got stuck in the end.  But
>>>>> apparently
>>>>> >> it was still going, slowly, despite of a string of error
messages.
>>>>> >>
>>>>> >> Here's what I did to load the data after su to "metviewer":
>>>>> >>
>>>>> >> cd /metviewer/staging/wd22yl
>>>>> >>
>>>>> >> /usr1/metviewer/metviewer/bin/mv_load.sh load_late.xml >
>>>>> >> out.load/loadlog.20180920_mv_ylin_pcp
>>>>> >>
>>>>> >> the 'loadlog' file was last updated at 15:57 today (13
minutes
>>>>> before I
>>>>> >> killed the job).    Could you tell me what's wrong?
load_late.xml
>>>>> is the
>>>>> >> same job script that I use to add data every week or so.
>>>>> >>
>>>>> >> Earlier yesterday I loaded some point_stat stat files (in
>>>>> >> /metviewer/staging/wd22yl/tmp.out, I did
>>>>> >> "/usr1/metviewer/metviewer/bin/mv_load.sh
>>>>> >> ../scripts/load_new_point_stat.xml > load.out"), that took
rather a
>>>>> long
>>>>> >> time too and had some "communications link failure", but the
stats
>>>>> were
>>>>> >> apparently loaded into the database successfully.
>>>>> >>
>>>>> >> Also - I have a cron job that loads one day's VSDB every day:
>>>>> >> /metviewer/staging/wd22yl/run_daily_erly.csh >
>>>>> >> /metviewer/staging/wd22yl/out.load/erly.out.  That one
apparently
>>>>> took 2
>>>>> >> hours too (longer than normal) and erly.out also have lots of
>>>>> errors.
>>>>> >>
>>>>> >>
>>>>> >> Thanks -
>>>>> >>
>>>>> >> Ying
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >
>>>>> >
>>>>>
>>>>> --
>>>>> Ying Lin
>>>>> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
>>>>> NCWCP Cubicle No. 2015
>>>>> Ying.Lin at noaa.gov
>>>>>
>>>>>
>>>>>
>>>

------------------------------------------------
Subject: METviewer loading problem
From: Benjamin Blake - NOAA Affiliate
Time: Fri Sep 21 12:29:01 2018

Hi Perry,

I found my old xml file in /metviewer/staging/bblake
(prune_test.xml_bblake), here are the contents:

<prune_spec>
  <connection>
    <host>vm-lnx-metviewdev-db1.ncep.noaa.gov:3306</host>
    <database>mv_met_probexp</database>
    <user>metviewer</user>
    <password>@&R8M%x5_U~rXa</password>
  </connection>
  <info_only>false</info_only>

  <fields>
    <field name="fcst_init_beg">
      <value_range>
        <start>2016-10-05 00:00:00</start>
        <end>2016-10-31 12:00:00</end>
      </value_range>
    </field>
    <field name="model">
      <value_list>
        <value>HREF-AAS</value>
      </value_list>
    </field>
  </fields>
</prune_spec>

My xml file does not have a <management_system> tag, and I selected
the
fields to delete with "fcst_init_beg" and "model".  I used this xml
with an
older version of METviewer though so Tatiana may know better than me
as to
why yours didn't work.

Thanks,
Ben

On Fri, Sep 21, 2018 at 2:18 PM, Perry Shafran - NOAA Affiliate <
perry.shafran at noaa.gov> wrote:

> I don't think it worked for whatever reason.
> com.mysql.jdbc.exceptions.jdbc4.CommunicationsException:
Communications
> link failure
>
> Last packet sent to the server was 16 ms ago.
> From table data_file deleted 0 records.
> java.sql.SQLException: Connection has already been closed.
> From table line_data_cnt deleted 0 records.
> java.sql.SQLException: Connection has already been closed.
> From table line_data_ctc deleted 0 records.
> java.sql.SQLException: Connection has already been closed.
> From table line_data_cts deleted 0 records.
> java.sql.SQLException: Connection has already been closed.
> From tables line_data_eclv and line_data_eclv_pnt deleted 0 records.
> java.sql.SQLException: Connection has already been closed.
> From table line_data_enscnt deleted 0 records.
> java.sql.SQLException: Connection has already been closed.
> From table line_data_fho deleted 0 records.
> java.sql.SQLException: Connection has already been closed.
> From table line_data_isc deleted 0 records.
> java.sql.SQLException: Connection has already been closed.
> From tables line_data_mctc and line_data_mctc_cnt deleted 0 records.
> java.sql.SQLException: Connection has already been closed.
> From table line_data_mcts deleted 0 records.
> java.sql.SQLException: Connection has already been closed.
> From table line_data_mpr deleted 0 records.
> java.sql.SQLException: Connection has already been closed.
> From table line_data_nbrcnt deleted 0 records.
> java.sql.SQLException: Connection has already been closed.
> From table line_data_nbrctc deleted 0 records.
> java.sql.SQLException: Connection has already been closed.
> From table line_data_nbrcts deleted 0 records.
> java.sql.SQLException: Connection has already been closed.
> From tables line_data_orank and line_data_orank_ens deleted 0
records.
> java.sql.SQLException: Connection has already been closed.
> From tables line_data_pct and line_data_pct_thresh deleted 0
records.
> java.sql.SQLException: Connection has already been closed.
> From tables line_data_phist and line_data_phist_bin deleted 0
records.
> java.sql.SQLException: Connection has already been closed.
> From tables line_data_pjc and line_data_pjc_thresh deleted 0
records.
> java.sql.SQLException: Connection has already been closed.
> From tables line_data_prc and line_data_prc_thresh deleted 0
records.
> java.sql.SQLException: Connection has already been closed.
> From tables line_data_pstd and line_data_pstd_thresh deleted 0
records.
> java.sql.SQLException: Connection has already been closed.
> From tables line_data_relp and line_data_relp_ens deleted 0 records.
> java.sql.SQLException: Connection has already been closed.
> From tables line_data_rhist and line_data_rhist_rank deleted 0
records.
> java.sql.SQLException: Connection has already been closed.
> From table line_data_sal1l2 deleted 0 records.
> java.sql.SQLException: Connection has already been closed.
> From table line_data_sl1l2 deleted 0 records.
> java.sql.SQLException: Connection has already been closed.
> From table line_data_ssvar deleted 0 records.
> java.sql.SQLException: Connection has already been closed.
> From table line_data_val1l2 deleted 0 records.
> java.sql.SQLException: Connection has already been closed.
> From table line_data_vl1l2 deleted 0 records.
> java.sql.SQLException: Connection has already been closed.
> From table mode_cts deleted 0 records.
> java.sql.SQLException: Connection has already been closed.
> From table mode_obj_pair deleted 0 records.
> java.sql.SQLException: Connection has already been closed.
> From table mode_obj_single deleted 0 records.
> Total deleted 0 records
> java.sql.SQLException: Connection has already been closed.
> From stat_header table was deleted  0 records
> java.sql.SQLException: Connection has already been closed.
> From mode_header table was deleted  0 records
> ----  MVPruneDB Done  ----
> [metviewer at vm-lnx-metviewdev-process1 ~]$
>
> Can someone please help?  My prune script is
prune_db_spec_file_wd20ps.
> Is there a problem with this?  I just want to remove using certain
dates.
>
> Thanks!
>
> Perry
>
>
>
> On Fri, Sep 21, 2018 at 1:58 PM Perry Shafran - NOAA Affiliate <
> perry.shafran at noaa.gov> wrote:
>
>> It looks like the prune script is running but I guess I'll have to
wait
>> to find out.
>>
>> Perry
>>
>> On Fri, Sep 21, 2018 at 1:47 PM Perry Shafran - NOAA Affiliate <
>> perry.shafran at noaa.gov> wrote:
>>
>>> OK, that should help.  I'll prune my database.
>>>
>>> Perry
>>>
>>> On Fri, Sep 21, 2018 at 1:45 PM Benjamin Blake - NOAA Affiliate <
>>> benjamin.blake at noaa.gov> wrote:
>>>
>>>> Hi Perry,
>>>>
>>>> That's fine with me if you want to clear out old data from the
>>>> mv_emc_g2o database.
>>>>
>>>> I haven't tried doing this in a while but I was able to do it in
the
>>>> past.  I think the command for removing data is the following:
>>>> /usr1/metviewer/metviewer/bin/mv_prune.sh prune_db_spec_file
>>>>
>>>> There is an example prune_db_spec_file in the
/usr1/metviewer/shared
>>>> directory and here's a link with more information which may help:
>>>> http://www.dtcenter.org/met/metviewer/doc/database_scrubbing.html
>>>>
>>>> Thanks,
>>>> Ben
>>>>
>>>> On Fri, Sep 21, 2018 at 1:35 PM, Perry Shafran - NOAA Affiliate <
>>>> perry.shafran at noaa.gov> wrote:
>>>>
>>>>> I ran a mysql command that Kirk had demonstrated how to get the
size
>>>>> of various mysql databases.  By *FAR*, the largest database is
my database
>>>>> mv_emc_g2o, which I think will need to be cut to size.
>>>>>
>>>>> I think that I want to delete all but the past, oh, say, 6
months
>>>>> worth of data from this database.  Before I do so, I'd like to
ask Ben if I
>>>>> can cut all from this database except the past 3 months.  That
would clear
>>>>> out a lot of room.
>>>>>
>>>>> Can anyone advise me how to clear data from a database?  I'm
sure it's
>>>>> been demonstrated, but I don't remember.
>>>>>
>>>>> Perry
>>>>>
>>>>> On Fri, Sep 21, 2018 at 1:18 PM Ying Lin <ying.lin at noaa.gov>
wrote:
>>>>>
>>>>>> Hi Tatiana,
>>>>>>
>>>>>>      Thanks for the quick reply.  I found on
>>>>>> vm-lnx-metviewdev-db1.ncep.noaa.gov that /var/lib/mysql is 100%
>>>>>> full.  I
>>>>>> can't check which database under /var/lib/mysql though, and
when I
>>>>>> attempted to "su -i -u metviewer" I got "wd22yl is not in the
sudoers
>>>>>> file.  This incident will be reported."
>>>>>>
>>>>>>      I dug through some old emails, and saw one from Kirk Holub
from
>>>>>> Jun
>>>>>> 2017 that "On mv-lnx-metviewdev-process1, the file
'/tmp/mvDB_status'
>>>>>> shows usage by 'mv_' database."  I assume it's vm-lnx-
metviewdev
>>>>>> (there's no mv-lnx...), but there isn't a /tmp/mvDB_status
file.
>>>>>>
>>>>>>      Can you, as superuser, find out which databases on
>>>>>> /var/lib/mysql
>>>>>> are taking up too much space?
>>>>>>
>>>>>>      Thanks -
>>>>>>
>>>>>> Ying
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 09/21/2018 12:49 PM, Tatiana Burek via RT wrote:
>>>>>> > Ying,
>>>>>> > The issues you experience could be related to MySQL reaching
it's
>>>>>> size limit.
>>>>>> > Is there any way to check the disk space left value of the
volume
>>>>>> where MySQL is installed?
>>>>>> >
>>>>>> > Tatiana
>>>>>> >
>>>>>> > On Fri Sep 21 10:32:16 2018, ying.lin at noaa.gov wrote:
>>>>>> >> Hello.  I was loading some VSDB files into METviewer last
night,
>>>>>> >> starting around  23:17Z.  It took a long time - at 16:10Z
today I
>>>>>> killed
>>>>>> >> the job (NCO wants us to reboot our workstations) thinking
it
>>>>>> probably
>>>>>> >> finished a long time ago and just got stuck in the end.  But
>>>>>> apparently
>>>>>> >> it was still going, slowly, despite of a string of error
messages.
>>>>>> >>
>>>>>> >> Here's what I did to load the data after su to "metviewer":
>>>>>> >>
>>>>>> >> cd /metviewer/staging/wd22yl
>>>>>> >>
>>>>>> >> /usr1/metviewer/metviewer/bin/mv_load.sh load_late.xml >
>>>>>> >> out.load/loadlog.20180920_mv_ylin_pcp
>>>>>> >>
>>>>>> >> the 'loadlog' file was last updated at 15:57 today (13
minutes
>>>>>> before I
>>>>>> >> killed the job).    Could you tell me what's wrong?
load_late.xml
>>>>>> is the
>>>>>> >> same job script that I use to add data every week or so.
>>>>>> >>
>>>>>> >> Earlier yesterday I loaded some point_stat stat files (in
>>>>>> >> /metviewer/staging/wd22yl/tmp.out, I did
>>>>>> >> "/usr1/metviewer/metviewer/bin/mv_load.sh
>>>>>> >> ../scripts/load_new_point_stat.xml > load.out"), that took
rather
>>>>>> a long
>>>>>> >> time too and had some "communications link failure", but the
stats
>>>>>> were
>>>>>> >> apparently loaded into the database successfully.
>>>>>> >>
>>>>>> >> Also - I have a cron job that loads one day's VSDB every
day:
>>>>>> >> /metviewer/staging/wd22yl/run_daily_erly.csh >
>>>>>> >> /metviewer/staging/wd22yl/out.load/erly.out.  That one
apparently
>>>>>> took 2
>>>>>> >> hours too (longer than normal) and erly.out also have lots
of
>>>>>> errors.
>>>>>> >>
>>>>>> >>
>>>>>> >> Thanks -
>>>>>> >>
>>>>>> >> Ying
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >
>>>>>> >
>>>>>>
>>>>>> --
>>>>>> Ying Lin
>>>>>> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
>>>>>> NCWCP Cubicle No. 2015
>>>>>> Ying.Lin at noaa.gov
>>>>>>
>>>>>>
>>>>>>
>>>>

------------------------------------------------
Subject: METviewer loading problem
From: perry.shafran at noaa.gov
Time: Fri Sep 21 13:18:28 2018

It's still not working.  Tatiana, can you assist in helping me prune
the
data in the mv_emc_g2o database?  I am using the
prune_db_spec_file_wd20ps
file, using the command mv_prune.sh prune_db_spec_file_wd20ps to
execute,
and it seems to be failing.  If you are able to prune data, Tatiana,
for
2016 and 2017, you have my permission.

Thanks!

Perry

On Fri, Sep 21, 2018 at 1:18 PM Ying Lin <ying.lin at noaa.gov> wrote:

> Hi Tatiana,
>
>      Thanks for the quick reply.  I found on
> vm-lnx-metviewdev-db1.ncep.noaa.gov that /var/lib/mysql is 100%
full.  I
> can't check which database under /var/lib/mysql though, and when I
> attempted to "su -i -u metviewer" I got "wd22yl is not in the
sudoers
> file.  This incident will be reported."
>
>      I dug through some old emails, and saw one from Kirk Holub from
Jun
> 2017 that "On mv-lnx-metviewdev-process1, the file
'/tmp/mvDB_status'
> shows usage by 'mv_' database."  I assume it's vm-lnx-metviewdev
> (there's no mv-lnx...), but there isn't a /tmp/mvDB_status file.
>
>      Can you, as superuser, find out which databases on
/var/lib/mysql
> are taking up too much space?
>
>      Thanks -
>
> Ying
>
>
>
>
> On 09/21/2018 12:49 PM, Tatiana Burek via RT wrote:
> > Ying,
> > The issues you experience could be related to MySQL reaching it's
size
> limit.
> > Is there any way to check the disk space left value of the volume
where
> MySQL is installed?
> >
> > Tatiana
> >
> > On Fri Sep 21 10:32:16 2018, ying.lin at noaa.gov wrote:
> >> Hello.  I was loading some VSDB files into METviewer last night,
> >> starting around  23:17Z.  It took a long time - at 16:10Z today I
killed
> >> the job (NCO wants us to reboot our workstations) thinking it
probably
> >> finished a long time ago and just got stuck in the end.  But
apparently
> >> it was still going, slowly, despite of a string of error
messages.
> >>
> >> Here's what I did to load the data after su to "metviewer":
> >>
> >> cd /metviewer/staging/wd22yl
> >>
> >> /usr1/metviewer/metviewer/bin/mv_load.sh load_late.xml >
> >> out.load/loadlog.20180920_mv_ylin_pcp
> >>
> >> the 'loadlog' file was last updated at 15:57 today (13 minutes
before I
> >> killed the job).    Could you tell me what's wrong? load_late.xml
is the
> >> same job script that I use to add data every week or so.
> >>
> >> Earlier yesterday I loaded some point_stat stat files (in
> >> /metviewer/staging/wd22yl/tmp.out, I did
> >> "/usr1/metviewer/metviewer/bin/mv_load.sh
> >> ../scripts/load_new_point_stat.xml > load.out"), that took rather
a long
> >> time too and had some "communications link failure", but the
stats were
> >> apparently loaded into the database successfully.
> >>
> >> Also - I have a cron job that loads one day's VSDB every day:
> >> /metviewer/staging/wd22yl/run_daily_erly.csh >
> >> /metviewer/staging/wd22yl/out.load/erly.out.  That one apparently
took 2
> >> hours too (longer than normal) and erly.out also have lots of
errors.
> >>
> >>
> >> Thanks -
> >>
> >> Ying
> >>
> >>
> >>
> >
> >
>
> --
> Ying Lin
> NCEP/EMC/Verification, Post-processing and Product Generation Branch
> NCWCP Cubicle No. 2015
> Ying.Lin at noaa.gov
>
>
>

------------------------------------------------
Subject: METviewer loading problem
From: Howard Soh
Time: Fri Sep 21 13:21:57 2018

Comment:

When the disk is full, many problems can happen with mysql client (for
example, too many connections and others).

The first step will be manually logging in the MySQL with mysql
command. If you can log in to mysql database, you can execute the
scrub script. From the previous email, it worked couple hours ago, but
did not 40 minutes later.

Cheers,
Howard

PS:

If you can not login to mysql, one option is deleting some files
physically after logging in to the mysql host machine (via ssh).

If you can not log in to msqyl host machine, it requires mysql root
account. Log in mysql using the mysql root account and delete some
binary log files (with PURGE BINARY LOGS command). After making room
for mysql, you can execute scripts to scrub databases.

<mysql command to check binary log files>
show binary logs\G

<mysql command to delete binary log files>

PURGE BINARY LOGS TO 'mysql-bin.XXXX';
PURGE BINARY LOGS BEFORE '2018-09-DD HH:MM:SS';

On Fri Sep 21 13:18:28 2018, perry.shafran at noaa.gov wrote:
> It's still not working.  Tatiana, can you assist in helping me prune
> the
> data in the mv_emc_g2o database?  I am using the
> prune_db_spec_file_wd20ps
> file, using the command mv_prune.sh prune_db_spec_file_wd20ps to
> execute,
> and it seems to be failing.  If you are able to prune data, Tatiana,
> for
> 2016 and 2017, you have my permission.
>
> Thanks!
>
> Perry
>
> On Fri, Sep 21, 2018 at 1:18 PM Ying Lin <ying.lin at noaa.gov> wrote:
>
> > Hi Tatiana,
> >
> > Thanks for the quick reply.  I found on
> > vm-lnx-metviewdev-db1.ncep.noaa.gov that /var/lib/mysql is 100%
full.
> > I
> > can't check which database under /var/lib/mysql though, and when I
> > attempted to "su -i -u metviewer" I got "wd22yl is not in the
sudoers
> > file.  This incident will be reported."
> >
> > I dug through some old emails, and saw one from Kirk Holub from
Jun
> > 2017 that "On mv-lnx-metviewdev-process1, the file
'/tmp/mvDB_status'
> > shows usage by 'mv_' database."  I assume it's vm-lnx-metviewdev
> > (there's no mv-lnx...), but there isn't a /tmp/mvDB_status file.
> >
> > Can you, as superuser, find out which databases on /var/lib/mysql
> > are taking up too much space?
> >
> > Thanks -
> >
> > Ying
> >
> >
> >
> >
> > On 09/21/2018 12:49 PM, Tatiana Burek via RT wrote:
> > > Ying,
> > > The issues you experience could be related to MySQL reaching
it's
> > > size
> > limit.
> > > Is there any way to check the disk space left value of the
volume
> > > where
> > MySQL is installed?
> > >
> > > Tatiana
> > >
> > > On Fri Sep 21 10:32:16 2018, ying.lin at noaa.gov wrote:
> > >> Hello.  I was loading some VSDB files into METviewer last
night,
> > >> starting around  23:17Z.  It took a long time - at 16:10Z today
I
> > >> killed
> > >> the job (NCO wants us to reboot our workstations) thinking it
> > >> probably
> > >> finished a long time ago and just got stuck in the end.  But
> > >> apparently
> > >> it was still going, slowly, despite of a string of error
messages.
> > >>
> > >> Here's what I did to load the data after su to "metviewer":
> > >>
> > >> cd /metviewer/staging/wd22yl
> > >>
> > >> /usr1/metviewer/metviewer/bin/mv_load.sh load_late.xml >
> > >> out.load/loadlog.20180920_mv_ylin_pcp
> > >>
> > >> the 'loadlog' file was last updated at 15:57 today (13 minutes
> > >> before I
> > >> killed the job).    Could you tell me what's wrong?
load_late.xml
> > >> is the
> > >> same job script that I use to add data every week or so.
> > >>
> > >> Earlier yesterday I loaded some point_stat stat files (in
> > >> /metviewer/staging/wd22yl/tmp.out, I did
> > >> "/usr1/metviewer/metviewer/bin/mv_load.sh
> > >> ../scripts/load_new_point_stat.xml > load.out"), that took
rather
> > >> a long
> > >> time too and had some "communications link failure", but the
stats
> > >> were
> > >> apparently loaded into the database successfully.
> > >>
> > >> Also - I have a cron job that loads one day's VSDB every day:
> > >> /metviewer/staging/wd22yl/run_daily_erly.csh >
> > >> /metviewer/staging/wd22yl/out.load/erly.out.  That one
apparently
> > >> took 2
> > >> hours too (longer than normal) and erly.out also have lots of
> > >> errors.
> > >>
> > >>
> > >> Thanks -
> > >>
> > >> Ying
> > >>
> > >>
> > >>
> > >
> > >
> >
> > --
> > Ying Lin
> > NCEP/EMC/Verification, Post-processing and Product Generation
Branch
> > NCWCP Cubicle No. 2015
> > Ying.Lin at noaa.gov
> >
> >
> >

------------------------------------------------
Subject: METviewer loading problem
From: Tatiana Burek
Time: Fri Sep 21 14:02:34 2018

Perry,

I fixed pruning XML file and restarted the process.

Tatiana

On Fri Sep 21 13:21:57 2018, hsoh wrote:
> Comment:
>
> When the disk is full, many problems can happen with mysql client
(for
> example, too many connections and others).
>
> The first step will be manually logging in the MySQL with mysql
> command. If you can log in to mysql database, you can execute the
> scrub script. From the previous email, it worked couple hours ago,
but
> did not 40 minutes later.
>
> Cheers,
> Howard
>
> PS:
>
> If you can not login to mysql, one option is deleting some files
> physically after logging in to the mysql host machine (via ssh).
>
> If you can not log in to msqyl host machine, it requires mysql root
> account. Log in mysql using the mysql root account and delete some
> binary log files (with PURGE BINARY LOGS command). After making room
> for mysql, you can execute scripts to scrub databases.
>
> <mysql command to check binary log files>
> show binary logs\G
>
> <mysql command to delete binary log files>
>
> PURGE BINARY LOGS TO 'mysql-bin.XXXX';
> PURGE BINARY LOGS BEFORE '2018-09-DD HH:MM:SS';
>
>
> On Fri Sep 21 13:18:28 2018, perry.shafran at noaa.gov wrote:
> > It's still not working.  Tatiana, can you assist in helping me
prune
> > the
> > data in the mv_emc_g2o database?  I am using the
> > prune_db_spec_file_wd20ps
> > file, using the command mv_prune.sh prune_db_spec_file_wd20ps to
> > execute,
> > and it seems to be failing.  If you are able to prune data,
Tatiana,
> > for
> > 2016 and 2017, you have my permission.
> >
> > Thanks!
> >
> > Perry
> >
> > On Fri, Sep 21, 2018 at 1:18 PM Ying Lin <ying.lin at noaa.gov>
wrote:
> >
> > > Hi Tatiana,
> > >
> > > Thanks for the quick reply.  I found on
> > > vm-lnx-metviewdev-db1.ncep.noaa.gov that /var/lib/mysql is 100%
> > > full.
> > > I
> > > can't check which database under /var/lib/mysql though, and when
I
> > > attempted to "su -i -u metviewer" I got "wd22yl is not in the
> > > sudoers
> > > file.  This incident will be reported."
> > >
> > > I dug through some old emails, and saw one from Kirk Holub from
Jun
> > > 2017 that "On mv-lnx-metviewdev-process1, the file
> > > '/tmp/mvDB_status'
> > > shows usage by 'mv_' database."  I assume it's vm-lnx-metviewdev
> > > (there's no mv-lnx...), but there isn't a /tmp/mvDB_status file.
> > >
> > > Can you, as superuser, find out which databases on
/var/lib/mysql
> > > are taking up too much space?
> > >
> > > Thanks -
> > >
> > > Ying
> > >
> > >
> > >
> > >
> > > On 09/21/2018 12:49 PM, Tatiana Burek via RT wrote:
> > > > Ying,
> > > > The issues you experience could be related to MySQL reaching
it's
> > > > size
> > > limit.
> > > > Is there any way to check the disk space left value of the
volume
> > > > where
> > > MySQL is installed?
> > > >
> > > > Tatiana
> > > >
> > > > On Fri Sep 21 10:32:16 2018, ying.lin at noaa.gov wrote:
> > > >> Hello.  I was loading some VSDB files into METviewer last
night,
> > > >> starting around  23:17Z.  It took a long time - at 16:10Z
today
> > > >> I
> > > >> killed
> > > >> the job (NCO wants us to reboot our workstations) thinking it
> > > >> probably
> > > >> finished a long time ago and just got stuck in the end.  But
> > > >> apparently
> > > >> it was still going, slowly, despite of a string of error
> > > >> messages.
> > > >>
> > > >> Here's what I did to load the data after su to "metviewer":
> > > >>
> > > >> cd /metviewer/staging/wd22yl
> > > >>
> > > >> /usr1/metviewer/metviewer/bin/mv_load.sh load_late.xml >
> > > >> out.load/loadlog.20180920_mv_ylin_pcp
> > > >>
> > > >> the 'loadlog' file was last updated at 15:57 today (13
minutes
> > > >> before I
> > > >> killed the job).    Could you tell me what's wrong?
> > > >> load_late.xml
> > > >> is the
> > > >> same job script that I use to add data every week or so.
> > > >>
> > > >> Earlier yesterday I loaded some point_stat stat files (in
> > > >> /metviewer/staging/wd22yl/tmp.out, I did
> > > >> "/usr1/metviewer/metviewer/bin/mv_load.sh
> > > >> ../scripts/load_new_point_stat.xml > load.out"), that took
> > > >> rather
> > > >> a long
> > > >> time too and had some "communications link failure", but the
> > > >> stats
> > > >> were
> > > >> apparently loaded into the database successfully.
> > > >>
> > > >> Also - I have a cron job that loads one day's VSDB every day:
> > > >> /metviewer/staging/wd22yl/run_daily_erly.csh >
> > > >> /metviewer/staging/wd22yl/out.load/erly.out.  That one
> > > >> apparently
> > > >> took 2
> > > >> hours too (longer than normal) and erly.out also have lots of
> > > >> errors.
> > > >>
> > > >>
> > > >> Thanks -
> > > >>
> > > >> Ying
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
> > > --
> > > Ying Lin
> > > NCEP/EMC/Verification, Post-processing and Product Generation
> > > Branch
> > > NCWCP Cubicle No. 2015
> > > Ying.Lin at noaa.gov
> > >
> > >
> > >

------------------------------------------------
Subject: METviewer loading problem
From: Tatiana Burek
Time: Mon Sep 24 08:08:45 2018

MySQL has a lot of locked and waiting INSERT queries and needs to be
restarted. Inserts are made into mv_emc_g2o and mv_ylin_pcp_erly
databases.
I would recommend not to load more data to the databases until the
space issue is solved.

Tatiana

On Fri Sep 21 14:02:34 2018, tatiana wrote:
> Perry,
>
> I fixed pruning XML file and restarted the process.
>
> Tatiana
>
> On Fri Sep 21 13:21:57 2018, hsoh wrote:
> > Comment:
> >
> > When the disk is full, many problems can happen with mysql client
(for
> > example, too many connections and others).
> >
> > The first step will be manually logging in the MySQL with mysql
> > command. If you can log in to mysql database, you can execute the
> > scrub script. From the previous email, it worked couple hours ago,
but
> > did not 40 minutes later.
> >
> > Cheers,
> > Howard
> >
> > PS:
> >
> > If you can not login to mysql, one option is deleting some files
> > physically after logging in to the mysql host machine (via ssh).
> >
> > If you can not log in to msqyl host machine, it requires mysql
root
> > account. Log in mysql using the mysql root account and delete some
> > binary log files (with PURGE BINARY LOGS command). After making
room
> > for mysql, you can execute scripts to scrub databases.
> >
> > <mysql command to check binary log files>
> > show binary logs\G
> >
> > <mysql command to delete binary log files>
> >
> > PURGE BINARY LOGS TO 'mysql-bin.XXXX';
> > PURGE BINARY LOGS BEFORE '2018-09-DD HH:MM:SS';
> >
> >
> > On Fri Sep 21 13:18:28 2018, perry.shafran at noaa.gov wrote:
> > > It's still not working.  Tatiana, can you assist in helping me
prune
> > > the
> > > data in the mv_emc_g2o database?  I am using the
> > > prune_db_spec_file_wd20ps
> > > file, using the command mv_prune.sh prune_db_spec_file_wd20ps to
> > > execute,
> > > and it seems to be failing.  If you are able to prune data,
Tatiana,
> > > for
> > > 2016 and 2017, you have my permission.
> > >
> > > Thanks!
> > >
> > > Perry
> > >
> > > On Fri, Sep 21, 2018 at 1:18 PM Ying Lin <ying.lin at noaa.gov>
wrote:
> > >
> > > > Hi Tatiana,
> > > >
> > > > Thanks for the quick reply.  I found on
> > > > vm-lnx-metviewdev-db1.ncep.noaa.gov that /var/lib/mysql is
100%
> > > > full.
> > > > I
> > > > can't check which database under /var/lib/mysql though, and
when I
> > > > attempted to "su -i -u metviewer" I got "wd22yl is not in the
> > > > sudoers
> > > > file.  This incident will be reported."
> > > >
> > > > I dug through some old emails, and saw one from Kirk Holub
from Jun
> > > > 2017 that "On mv-lnx-metviewdev-process1, the file
> > > > '/tmp/mvDB_status'
> > > > shows usage by 'mv_' database."  I assume it's vm-lnx-
metviewdev
> > > > (there's no mv-lnx...), but there isn't a /tmp/mvDB_status
file.
> > > >
> > > > Can you, as superuser, find out which databases on
/var/lib/mysql
> > > > are taking up too much space?
> > > >
> > > > Thanks -
> > > >
> > > > Ying
> > > >
> > > >
> > > >
> > > >
> > > > On 09/21/2018 12:49 PM, Tatiana Burek via RT wrote:
> > > > > Ying,
> > > > > The issues you experience could be related to MySQL reaching
it's
> > > > > size
> > > > limit.
> > > > > Is there any way to check the disk space left value of the
volume
> > > > > where
> > > > MySQL is installed?
> > > > >
> > > > > Tatiana
> > > > >
> > > > > On Fri Sep 21 10:32:16 2018, ying.lin at noaa.gov wrote:
> > > > >> Hello.  I was loading some VSDB files into METviewer last
night,
> > > > >> starting around  23:17Z.  It took a long time - at 16:10Z
today
> > > > >> I
> > > > >> killed
> > > > >> the job (NCO wants us to reboot our workstations) thinking
it
> > > > >> probably
> > > > >> finished a long time ago and just got stuck in the end.
But
> > > > >> apparently
> > > > >> it was still going, slowly, despite of a string of error
> > > > >> messages.
> > > > >>
> > > > >> Here's what I did to load the data after su to "metviewer":
> > > > >>
> > > > >> cd /metviewer/staging/wd22yl
> > > > >>
> > > > >> /usr1/metviewer/metviewer/bin/mv_load.sh load_late.xml >
> > > > >> out.load/loadlog.20180920_mv_ylin_pcp
> > > > >>
> > > > >> the 'loadlog' file was last updated at 15:57 today (13
minutes
> > > > >> before I
> > > > >> killed the job).    Could you tell me what's wrong?
> > > > >> load_late.xml
> > > > >> is the
> > > > >> same job script that I use to add data every week or so.
> > > > >>
> > > > >> Earlier yesterday I loaded some point_stat stat files (in
> > > > >> /metviewer/staging/wd22yl/tmp.out, I did
> > > > >> "/usr1/metviewer/metviewer/bin/mv_load.sh
> > > > >> ../scripts/load_new_point_stat.xml > load.out"), that took
> > > > >> rather
> > > > >> a long
> > > > >> time too and had some "communications link failure", but
the
> > > > >> stats
> > > > >> were
> > > > >> apparently loaded into the database successfully.
> > > > >>
> > > > >> Also - I have a cron job that loads one day's VSDB every
day:
> > > > >> /metviewer/staging/wd22yl/run_daily_erly.csh >
> > > > >> /metviewer/staging/wd22yl/out.load/erly.out.  That one
> > > > >> apparently
> > > > >> took 2
> > > > >> hours too (longer than normal) and erly.out also have lots
of
> > > > >> errors.
> > > > >>
> > > > >>
> > > > >> Thanks -
> > > > >>
> > > > >> Ying
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > >
> > > > --
> > > > Ying Lin
> > > > NCEP/EMC/Verification, Post-processing and Product Generation
> > > > Branch
> > > > NCWCP Cubicle No. 2015
> > > > Ying.Lin at noaa.gov
> > > >
> > > >
> > > >
>
>

------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #87080] METviewer loading problem
From: Ying Lin
Time: Mon Sep 24 09:55:59 2018

Hi Tatiana,

     Could you tell me what you used to get your listing of databases
by
side below (mysql query?)  I found Kirk's

mysql> select ISS.SCHEMA_NAME as DBNAME, CREATE_TIME, format(
sum(DATA_LENGTH)
     -> / (1024*1024), 1 ) as data_length_Mb, format(
sum(INDEX_LENGTH) /
     -> (1024*1024), 1 ) as index_length_Mb from
information_schema.TABLES as
     -> IST, information_schema.SCHEMATA as ISS where IST.TABLE_SCHEMA
=
     -> ISS.SCHEMA_NAME and ISS.SCHEMA_NAME like "mv_%" GROUP BY
ISS.SCHEMA_NAME;

which gives data_length_Mb & index_length_Mb which is useful but not
quite direct as your listing below.  Does your Data  Base Size include
both of "data" and "index"?

btw about your email/recommendation this morning  - I disabled my
daily
load cron now (should've done so Friday night).  Thanks.

Ying

On 09/21/2018 01:37 PM, Tatiana Burek via RT wrote:
> These are the largest databases:
> | table_schema               | Data Base Size in MB |
> | mv_jah_emc_g2o             |       11977.49656487 |
> | mv_emc_g2o2                |       12275.60431862 |
> | mv_ylin_pcp                |       14404.04145241 |
> | mv_met_dl2rw               |       15345.15241528 |
> | mv_g2g_vsdb_ens            |       16617.03862095 |
> | mv_emc_metvsvsdb           |       21196.60622025 |
> | mv_emc_g2o                 |      248886.72011662 |
>
> Tatiana
>
> On Fri Sep 21 11:20:57 2018, perry.shafran at noaa.gov wrote:
>> I'm pretty sure that mine is the largest one.
>>
>> Perry
>>
>> On Fri, Sep 21, 2018 at 1:18 PM Ying Lin <ying.lin at noaa.gov> wrote:
>>
>>> Hi Tatiana,
>>>
>>> Thanks for the quick reply.  I found on
>>> vm-lnx-metviewdev-db1.ncep.noaa.gov that /var/lib/mysql is 100%
full.
>>> I
>>> can't check which database under /var/lib/mysql though, and when I
>>> attempted to "su -i -u metviewer" I got "wd22yl is not in the
sudoers
>>> file.  This incident will be reported."
>>>
>>> I dug through some old emails, and saw one from Kirk Holub from
Jun
>>> 2017 that "On mv-lnx-metviewdev-process1, the file
'/tmp/mvDB_status'
>>> shows usage by 'mv_' database."  I assume it's vm-lnx-metviewdev
>>> (there's no mv-lnx...), but there isn't a /tmp/mvDB_status file.
>>>
>>> Can you, as superuser, find out which databases on /var/lib/mysql
>>> are taking up too much space?
>>>
>>> Thanks -
>>>
>>> Ying
>>>
>>>
>>>
>>>
>>> On 09/21/2018 12:49 PM, Tatiana Burek via RT wrote:
>>>> Ying,
>>>> The issues you experience could be related to MySQL reaching it's
>>>> size
>>> limit.
>>>> Is there any way to check the disk space left value of the volume
>>>> where
>>> MySQL is installed?
>>>> Tatiana
>>>>
>>>> On Fri Sep 21 10:32:16 2018, ying.lin at noaa.gov wrote:
>>>>> Hello.  I was loading some VSDB files into METviewer last night,
>>>>> starting around  23:17Z.  It took a long time - at 16:10Z today
I
>>>>> killed
>>>>> the job (NCO wants us to reboot our workstations) thinking it
>>>>> probably
>>>>> finished a long time ago and just got stuck in the end.  But
>>>>> apparently
>>>>> it was still going, slowly, despite of a string of error
messages.
>>>>>
>>>>> Here's what I did to load the data after su to "metviewer":
>>>>>
>>>>> cd /metviewer/staging/wd22yl
>>>>>
>>>>> /usr1/metviewer/metviewer/bin/mv_load.sh load_late.xml >
>>>>> out.load/loadlog.20180920_mv_ylin_pcp
>>>>>
>>>>> the 'loadlog' file was last updated at 15:57 today (13 minutes
>>>>> before I
>>>>> killed the job).    Could you tell me what's wrong?
load_late.xml
>>>>> is the
>>>>> same job script that I use to add data every week or so.
>>>>>
>>>>> Earlier yesterday I loaded some point_stat stat files (in
>>>>> /metviewer/staging/wd22yl/tmp.out, I did
>>>>> "/usr1/metviewer/metviewer/bin/mv_load.sh
>>>>> ../scripts/load_new_point_stat.xml > load.out"), that took
rather
>>>>> a long
>>>>> time too and had some "communications link failure", but the
stats
>>>>> were
>>>>> apparently loaded into the database successfully.
>>>>>
>>>>> Also - I have a cron job that loads one day's VSDB every day:
>>>>> /metviewer/staging/wd22yl/run_daily_erly.csh >
>>>>> /metviewer/staging/wd22yl/out.load/erly.out.  That one
apparently
>>>>> took 2
>>>>> hours too (longer than normal) and erly.out also have lots of
>>>>> errors.
>>>>>
>>>>>
>>>>> Thanks -
>>>>>
>>>>> Ying
>>>>>
>>>>>
>>>>>
>>>>
>>> --
>>> Ying Lin
>>> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
>>> NCWCP Cubicle No. 2015
>>> Ying.Lin at noaa.gov
>>>
>>>
>>>
>
>

--
Ying Lin
NCEP/EMC/Verification, Post-processing and Product Generation Branch
NCWCP Cubicle No. 2015
Ying.Lin at noaa.gov

------------------------------------------------
Subject: METviewer loading problem
From: Tatiana Burek
Time: Mon Sep 24 11:16:39 2018

Ying,

I use this query to get the size of all databases:
SELECT table_schema , SUM( data_length + index_length) / 1024 / 1024
"Data Base Size in MB" FROM information_schema.TABLES GROUP BY
table_schema ;

Tatiana
On Mon Sep 24 09:55:59 2018, ying.lin at noaa.gov wrote:
> Hi Tatiana,
>
>      Could you tell me what you used to get your listing of
databases by
> side below (mysql query?)  I found Kirk's
>
> mysql> select ISS.SCHEMA_NAME as DBNAME, CREATE_TIME, format(
> sum(DATA_LENGTH)
>      -> / (1024*1024), 1 ) as data_length_Mb, format(
sum(INDEX_LENGTH) /
>      -> (1024*1024), 1 ) as index_length_Mb from
> information_schema.TABLES as
>      -> IST, information_schema.SCHEMATA as ISS where
IST.TABLE_SCHEMA =
>      -> ISS.SCHEMA_NAME and ISS.SCHEMA_NAME like "mv_%" GROUP BY
> ISS.SCHEMA_NAME;
>
> which gives data_length_Mb & index_length_Mb which is useful but not
> quite direct as your listing below.  Does your Data  Base Size
include
> both of "data" and "index"?
>
> btw about your email/recommendation this morning  - I disabled my
daily
> load cron now (should've done so Friday night).  Thanks.
>
> Ying
>
> On 09/21/2018 01:37 PM, Tatiana Burek via RT wrote:
> > These are the largest databases:
> > | table_schema               | Data Base Size in MB |
> > | mv_jah_emc_g2o             |       11977.49656487 |
> > | mv_emc_g2o2                |       12275.60431862 |
> > | mv_ylin_pcp                |       14404.04145241 |
> > | mv_met_dl2rw               |       15345.15241528 |
> > | mv_g2g_vsdb_ens            |       16617.03862095 |
> > | mv_emc_metvsvsdb           |       21196.60622025 |
> > | mv_emc_g2o                 |      248886.72011662 |
> >
> > Tatiana
> >
> > On Fri Sep 21 11:20:57 2018, perry.shafran at noaa.gov wrote:
> >> I'm pretty sure that mine is the largest one.
> >>
> >> Perry
> >>
> >> On Fri, Sep 21, 2018 at 1:18 PM Ying Lin <ying.lin at noaa.gov>
wrote:
> >>
> >>> Hi Tatiana,
> >>>
> >>> Thanks for the quick reply.  I found on
> >>> vm-lnx-metviewdev-db1.ncep.noaa.gov that /var/lib/mysql is 100%
full.
> >>> I
> >>> can't check which database under /var/lib/mysql though, and when
I
> >>> attempted to "su -i -u metviewer" I got "wd22yl is not in the
sudoers
> >>> file.  This incident will be reported."
> >>>
> >>> I dug through some old emails, and saw one from Kirk Holub from
Jun
> >>> 2017 that "On mv-lnx-metviewdev-process1, the file
'/tmp/mvDB_status'
> >>> shows usage by 'mv_' database."  I assume it's vm-lnx-metviewdev
> >>> (there's no mv-lnx...), but there isn't a /tmp/mvDB_status file.
> >>>
> >>> Can you, as superuser, find out which databases on
/var/lib/mysql
> >>> are taking up too much space?
> >>>
> >>> Thanks -
> >>>
> >>> Ying
> >>>
> >>>
> >>>
> >>>
> >>> On 09/21/2018 12:49 PM, Tatiana Burek via RT wrote:
> >>>> Ying,
> >>>> The issues you experience could be related to MySQL reaching
it's
> >>>> size
> >>> limit.
> >>>> Is there any way to check the disk space left value of the
volume
> >>>> where
> >>> MySQL is installed?
> >>>> Tatiana
> >>>>
> >>>> On Fri Sep 21 10:32:16 2018, ying.lin at noaa.gov wrote:
> >>>>> Hello.  I was loading some VSDB files into METviewer last
night,
> >>>>> starting around  23:17Z.  It took a long time - at 16:10Z
today I
> >>>>> killed
> >>>>> the job (NCO wants us to reboot our workstations) thinking it
> >>>>> probably
> >>>>> finished a long time ago and just got stuck in the end.  But
> >>>>> apparently
> >>>>> it was still going, slowly, despite of a string of error
messages.
> >>>>>
> >>>>> Here's what I did to load the data after su to "metviewer":
> >>>>>
> >>>>> cd /metviewer/staging/wd22yl
> >>>>>
> >>>>> /usr1/metviewer/metviewer/bin/mv_load.sh load_late.xml >
> >>>>> out.load/loadlog.20180920_mv_ylin_pcp
> >>>>>
> >>>>> the 'loadlog' file was last updated at 15:57 today (13 minutes
> >>>>> before I
> >>>>> killed the job).    Could you tell me what's wrong?
load_late.xml
> >>>>> is the
> >>>>> same job script that I use to add data every week or so.
> >>>>>
> >>>>> Earlier yesterday I loaded some point_stat stat files (in
> >>>>> /metviewer/staging/wd22yl/tmp.out, I did
> >>>>> "/usr1/metviewer/metviewer/bin/mv_load.sh
> >>>>> ../scripts/load_new_point_stat.xml > load.out"), that took
rather
> >>>>> a long
> >>>>> time too and had some "communications link failure", but the
stats
> >>>>> were
> >>>>> apparently loaded into the database successfully.
> >>>>>
> >>>>> Also - I have a cron job that loads one day's VSDB every day:
> >>>>> /metviewer/staging/wd22yl/run_daily_erly.csh >
> >>>>> /metviewer/staging/wd22yl/out.load/erly.out.  That one
apparently
> >>>>> took 2
> >>>>> hours too (longer than normal) and erly.out also have lots of
> >>>>> errors.
> >>>>>
> >>>>>
> >>>>> Thanks -
> >>>>>
> >>>>> Ying
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>> --
> >>> Ying Lin
> >>> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
> >>> NCWCP Cubicle No. 2015
> >>> Ying.Lin at noaa.gov
> >>>
> >>>
> >>>
> >
> >
>

------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #87080] METviewer loading problem
From: Ying Lin
Time: Mon Sep 24 12:30:56 2018

Thank you very much Tatiana!   I like your query the best - sums up
the
data&index lengths.  It took quite a while but it worked.

Ying

On 09/24/2018 01:16 PM, Tatiana Burek via RT wrote:
> Ying,
>
> I use this query to get the size of all databases:
> SELECT table_schema , SUM( data_length + index_length) / 1024 / 1024
"Data Base Size in MB" FROM information_schema.TABLES GROUP BY
table_schema ;
>
> Tatiana
> On Mon Sep 24 09:55:59 2018, ying.lin at noaa.gov wrote:
>> Hi Tatiana,
>>
>>       Could you tell me what you used to get your listing of
databases by
>> side below (mysql query?)  I found Kirk's
>>
>> mysql> select ISS.SCHEMA_NAME as DBNAME, CREATE_TIME, format(
>> sum(DATA_LENGTH)
>>       -> / (1024*1024), 1 ) as data_length_Mb, format(
sum(INDEX_LENGTH) /
>>       -> (1024*1024), 1 ) as index_length_Mb from
>> information_schema.TABLES as
>>       -> IST, information_schema.SCHEMATA as ISS where
IST.TABLE_SCHEMA =
>>       -> ISS.SCHEMA_NAME and ISS.SCHEMA_NAME like "mv_%" GROUP BY
>> ISS.SCHEMA_NAME;
>>
>> which gives data_length_Mb & index_length_Mb which is useful but
not
>> quite direct as your listing below.  Does your Data  Base Size
include
>> both of "data" and "index"?
>>
>> btw about your email/recommendation this morning  - I disabled my
daily
>> load cron now (should've done so Friday night).  Thanks.
>>
>> Ying
>>
>> On 09/21/2018 01:37 PM, Tatiana Burek via RT wrote:
>>> These are the largest databases:
>>> | table_schema               | Data Base Size in MB |
>>> | mv_jah_emc_g2o             |       11977.49656487 |
>>> | mv_emc_g2o2                |       12275.60431862 |
>>> | mv_ylin_pcp                |       14404.04145241 |
>>> | mv_met_dl2rw               |       15345.15241528 |
>>> | mv_g2g_vsdb_ens            |       16617.03862095 |
>>> | mv_emc_metvsvsdb           |       21196.60622025 |
>>> | mv_emc_g2o                 |      248886.72011662 |
>>>
>>> Tatiana
>>>
>>> On Fri Sep 21 11:20:57 2018, perry.shafran at noaa.gov wrote:
>>>> I'm pretty sure that mine is the largest one.
>>>>
>>>> Perry
>>>>
>>>> On Fri, Sep 21, 2018 at 1:18 PM Ying Lin <ying.lin at noaa.gov>
wrote:
>>>>
>>>>> Hi Tatiana,
>>>>>
>>>>> Thanks for the quick reply.  I found on
>>>>> vm-lnx-metviewdev-db1.ncep.noaa.gov that /var/lib/mysql is 100%
full.
>>>>> I
>>>>> can't check which database under /var/lib/mysql though, and when
I
>>>>> attempted to "su -i -u metviewer" I got "wd22yl is not in the
sudoers
>>>>> file.  This incident will be reported."
>>>>>
>>>>> I dug through some old emails, and saw one from Kirk Holub from
Jun
>>>>> 2017 that "On mv-lnx-metviewdev-process1, the file
'/tmp/mvDB_status'
>>>>> shows usage by 'mv_' database."  I assume it's vm-lnx-metviewdev
>>>>> (there's no mv-lnx...), but there isn't a /tmp/mvDB_status file.
>>>>>
>>>>> Can you, as superuser, find out which databases on
/var/lib/mysql
>>>>> are taking up too much space?
>>>>>
>>>>> Thanks -
>>>>>
>>>>> Ying
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 09/21/2018 12:49 PM, Tatiana Burek via RT wrote:
>>>>>> Ying,
>>>>>> The issues you experience could be related to MySQL reaching
it's
>>>>>> size
>>>>> limit.
>>>>>> Is there any way to check the disk space left value of the
volume
>>>>>> where
>>>>> MySQL is installed?
>>>>>> Tatiana
>>>>>>
>>>>>> On Fri Sep 21 10:32:16 2018, ying.lin at noaa.gov wrote:
>>>>>>> Hello.  I was loading some VSDB files into METviewer last
night,
>>>>>>> starting around  23:17Z.  It took a long time - at 16:10Z
today I
>>>>>>> killed
>>>>>>> the job (NCO wants us to reboot our workstations) thinking it
>>>>>>> probably
>>>>>>> finished a long time ago and just got stuck in the end.  But
>>>>>>> apparently
>>>>>>> it was still going, slowly, despite of a string of error
messages.
>>>>>>>
>>>>>>> Here's what I did to load the data after su to "metviewer":
>>>>>>>
>>>>>>> cd /metviewer/staging/wd22yl
>>>>>>>
>>>>>>> /usr1/metviewer/metviewer/bin/mv_load.sh load_late.xml >
>>>>>>> out.load/loadlog.20180920_mv_ylin_pcp
>>>>>>>
>>>>>>> the 'loadlog' file was last updated at 15:57 today (13 minutes
>>>>>>> before I
>>>>>>> killed the job).    Could you tell me what's wrong?
load_late.xml
>>>>>>> is the
>>>>>>> same job script that I use to add data every week or so.
>>>>>>>
>>>>>>> Earlier yesterday I loaded some point_stat stat files (in
>>>>>>> /metviewer/staging/wd22yl/tmp.out, I did
>>>>>>> "/usr1/metviewer/metviewer/bin/mv_load.sh
>>>>>>> ../scripts/load_new_point_stat.xml > load.out"), that took
rather
>>>>>>> a long
>>>>>>> time too and had some "communications link failure", but the
stats
>>>>>>> were
>>>>>>> apparently loaded into the database successfully.
>>>>>>>
>>>>>>> Also - I have a cron job that loads one day's VSDB every day:
>>>>>>> /metviewer/staging/wd22yl/run_daily_erly.csh >
>>>>>>> /metviewer/staging/wd22yl/out.load/erly.out.  That one
apparently
>>>>>>> took 2
>>>>>>> hours too (longer than normal) and erly.out also have lots of
>>>>>>> errors.
>>>>>>>
>>>>>>>
>>>>>>> Thanks -
>>>>>>>
>>>>>>> Ying
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> --
>>>>> Ying Lin
>>>>> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
>>>>> NCWCP Cubicle No. 2015
>>>>> Ying.Lin at noaa.gov
>>>>>
>>>>>
>>>>>
>>>
>
>

--
Ying Lin
NCEP/EMC/Verification, Post-processing and Product Generation Branch
NCWCP Cubicle No. 2015
Ying.Lin at noaa.gov

------------------------------------------------