Recently, I discovered that somehow the tablespace for the system
catalog tables was dropped (SQL1008N) on list tablespace containers
for 0.
The error message also says that the use of the database be
discontinued (I assume this is because the catalog tables are
corrupt). Why then allow the database to be operational, shouldn't the
database manager mark the database as bad and forcibly prevent
connections?
Otherwise, what is the danger is continuing operations? 6 1399
"JS" <fy***@hotmail.com> wrote in message
news:e9**************************@posting.google.c om... Recently, I discovered that somehow the tablespace for the system catalog tables was dropped (SQL1008N) on list tablespace containers for 0. The error message also says that the use of the database be discontinued (I assume this is because the catalog tables are corrupt). Why then allow the database to be operational, shouldn't the database manager mark the database as bad and forcibly prevent connections? Otherwise, what is the danger is continuing operations?
Although the database was not be marked as 'BAD', and you still can connect
to the database. But once you can't access system tables, that means you
couldn't run any sql stmt, any db2 commands. You can't cause more hurt to
the current database.
"Fan Ruo Xin" <fa*****@sbcglobal.net> wrote in message news:<Rj****************@newssvr17.news.prodigy.co m>... "JS" <fy***@hotmail.com> wrote in message news:e9**************************@posting.google.c om... Recently, I discovered that somehow the tablespace for the system catalog tables was dropped (SQL1008N) on list tablespace containers for 0. The error message also says that the use of the database be discontinued (I assume this is because the catalog tables are corrupt). Why then allow the database to be operational, shouldn't the database manager mark the database as bad and forcibly prevent connections? Otherwise, what is the danger is continuing operations?
Although the database was not be marked as 'BAD', and you still can connect to the database. But once you can't access system tables, that means you couldn't run any sql stmt, any db2 commands. You can't cause more hurt to the current database.
No, I'm afarid that is incorrect. The database is entirely useable.
The fact that the tablespace has been dropped does not prevent
querying the syscat or sysibm tables, nor does it prevent application
connects and sql statements. The only difference is that the database
snapshot show the "Catalog database partition number" =1, (this is on
multi node system). So this looks like serious 'bug' in my opinion.
"JS" <fy***@hotmail.com> wrote in message
news:e9**************************@posting.google.c om... "Fan Ruo Xin" <fa*****@sbcglobal.net> wrote in message
news:<Rj****************@newssvr17.news.prodigy.co m>... "JS" <fy***@hotmail.com> wrote in message news:e9**************************@posting.google.c om... Recently, I discovered that somehow the tablespace for the system catalog tables was dropped (SQL1008N) on list tablespace containers for 0. The error message also says that the use of the database be discontinued (I assume this is because the catalog tables are corrupt). Why then allow the database to be operational, shouldn't the database manager mark the database as bad and forcibly prevent connections? Otherwise, what is the danger is continuing operations?
Although the database was not be marked as 'BAD', and you still can
connect to the database. But once you can't access system tables, that means you couldn't run any sql stmt, any db2 commands. You can't cause more hurt
to the current database. No, I'm afarid that is incorrect. The database is entirely useable. The fact that the tablespace has been dropped does not prevent querying the syscat or sysibm tables, nor does it prevent application connects and sql statements.
==========
Well, I really got confused. Did I miss something? Are you going to tell me
for whatever reason cause the system catalog
tablespace was dropped. But the system tables are still available. And they
are still allowed to access?
You can create new tables/indexes? You can run query? You can run runstats,
....?
The only difference is that the database snapshot show the "Catalog database partition number" =1, (this is on multi node system). So this looks like serious 'bug' in my opinion.
================
The catalog tablespace can be built on the db partition #1. What do you mean
it is the only difference here?
Is that you try to run "list tablespace containers for 0" on a none-catalog
db partition. You can only
find the system catalog tablespace on catalog node.
Fan Ruo Xin wrote: "JS" <fy***@hotmail.com> wrote in message news:e9**************************@posting.google.c om... "Fan Ruo Xin" <fa*****@sbcglobal.net> wrote in message news:<Rj****************@newssvr17.news.prodigy.co m>... > "JS" <fy***@hotmail.com> wrote in message > news:e9**************************@posting.google.c om... > > Recently, I discovered that somehow the tablespace for the system > > catalog tables was dropped (SQL1008N) on list tablespace containers > > for 0. > > The error message also says that the use of the database be > > discontinued (I assume this is because the catalog tables are > > corrupt). Why then allow the database to be operational, shouldn't > > the database manager mark the database as bad and forcibly prevent > > connections? > > Otherwise, what is the danger is continuing operations? > > Although the database was not be marked as 'BAD', and you still can connect > to the database. But once you can't access system tables, that means > you couldn't run any sql stmt, any db2 commands. You can't cause more > hurt to > the current database. No, I'm afarid that is incorrect. The database is entirely useable. The fact that the tablespace has been dropped does not prevent querying the syscat or sysibm tables, nor does it prevent application connects and sql statements.
========== Well, I really got confused. Did I miss something? Are you going to tell me for whatever reason cause the system catalog tablespace was dropped. But the system tables are still available. And they are still allowed to access? You can create new tables/indexes? You can run query? You can run runstats, ...?
The only thing I can imagine here is that the container was deleted
physically, i.e. not via ALTER TABLESPACE or something and, in addition,
DB2 still has some data in the buffer pool. So the queries against the
catalog can be answered with the buffer pool only. After recycling the
system the error messages should pop up right away.
Summarized, I think it's completely unclear what really happened for the
damage to occur.
--
Knut Stolze
Information Integration
IBM Germany / University of Jena
"Fan Ruo Xin" <fa*****@sbcglobal.net> wrote in message news:<Pu****************@newssvr17.news.prodigy.co m>... "JS" <fy***@hotmail.com> wrote in message news:e9**************************@posting.google.c om... "Fan Ruo Xin" <fa*****@sbcglobal.net> wrote in message news:<Rj****************@newssvr17.news.prodigy.co m>... "JS" <fy***@hotmail.com> wrote in message news:e9**************************@posting.google.c om... > Recently, I discovered that somehow the tablespace for the system > catalog tables was dropped (SQL1008N) on list tablespace containers > for 0. > The error message also says that the use of the database be > discontinued (I assume this is because the catalog tables are > corrupt). Why then allow the database to be operational, shouldn't the > database manager mark the database as bad and forcibly prevent > connections? > Otherwise, what is the danger is continuing operations?
Although the database was not be marked as 'BAD', and you still can connect to the database. But once you can't access system tables, that means you couldn't run any sql stmt, any db2 commands. You can't cause more hurt to the current database. No, I'm afarid that is incorrect. The database is entirely useable. The fact that the tablespace has been dropped does not prevent querying the syscat or sysibm tables, nor does it prevent application connects and sql statements.
========== Well, I really got confused. Did I miss something? Are you going to tell me for whatever reason cause the system catalog tablespace was dropped. But the system tables are still available. And they are still allowed to access? You can create new tables/indexes? You can run query? You can run runstats, ...?
The only difference is that the database snapshot show the "Catalog database partition number" =1, (this is on multi node system). So this looks like serious 'bug' in my opinion. ================ The catalog tablespace can be built on the db partition #1. What do you mean it is the only difference here? Is that you try to run "list tablespace containers for 0" on a none-catalog db partition. You can only find the system catalog tablespace on catalog node.
Yup, my mistake. Somehow, the catalog tablespace was created on node
1, the confusion results from the error message which says
'discontinue use of the database'. But you are right, the catalog can
be created on any node, I got further confused because
syscat.tablespaces doesn't say which node the tablespace is on, it
just gives the container id number, which of course doesnt exits on
node 0, but does exist on node 1.
Thanks for your help in clearing this up. fy***@hotmail.com (JS) wrote in message news:<e9**************************@posting.google. com>... "Fan Ruo Xin" <fa*****@sbcglobal.net> wrote in message news:<Pu****************@newssvr17.news.prodigy.co m>... "JS" <fy***@hotmail.com> wrote in message news:e9**************************@posting.google.c om... "Fan Ruo Xin" <fa*****@sbcglobal.net> wrote in message news:<Rj****************@newssvr17.news.prodigy.co m>... > "JS" <fy***@hotmail.com> wrote in message > news:e9**************************@posting.google.c om... > > Recently, I discovered that somehow the tablespace for the system > > catalog tables was dropped (SQL1008N) on list tablespace containers > > for 0. > > The error message also says that the use of the database be > > discontinued (I assume this is because the catalog tables are > > corrupt). Why then allow the database to be operational, shouldn't the > > database manager mark the database as bad and forcibly prevent > > connections? > > Otherwise, what is the danger is continuing operations? > > Although the database was not be marked as 'BAD', and you still can connect > to the database. But once you can't access system tables, that means you > couldn't run any sql stmt, any db2 commands. You can't cause more hurt to > the current database. No, I'm afarid that is incorrect. The database is entirely useable. The fact that the tablespace has been dropped does not prevent querying the syscat or sysibm tables, nor does it prevent application connects and sql statements. ========== Well, I really got confused. Did I miss something? Are you going to tell me for whatever reason cause the system catalog tablespace was dropped. But the system tables are still available. And they are still allowed to access? You can create new tables/indexes? You can run query? You can run runstats, ...?
The only difference is that the database snapshot show the "Catalog database partition number" =1, (this is on multi node system). So this looks like serious 'bug' in my opinion. ================ The catalog tablespace can be built on the db partition #1. What do you mean it is the only difference here? Is that you try to run "list tablespace containers for 0" on a none-catalog db partition. You can only find the system catalog tablespace on catalog node. Yup, my mistake. Somehow, the catalog tablespace was created on node 1, the confusion results from the error message which says 'discontinue use of the database'. But you are right, the catalog can be created on any node, I got further confused because syscat.tablespaces doesn't say which node the tablespace is on, it just gives the container id number, which of course doesnt exits on node 0, but does exist on node 1. Thanks for your help in clearing this up.
Kurt
My only point now is that this error message sql1008 is somewhat
misleading, because there really is no need to discontinue use of the
database, it is just that the catalog tables were not where I was
expecting them to be, so perhaps that error message could be re
written This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Neal D. Becker |
last post by:
optparse is great. I have one small suggestion for an improvement.
optparse supports boolean switches, with action=store_false/store_true. It
would be handy if one specification would...
|
by: dba2adm |
last post by:
I have a view which references two different tables at different times
say t_1 on certain days and t_2 on certain other days.
In oracle I have many many ways of doing this without having much...
|
by: Lloyd Sheen |
last post by:
I am out of my mind fighting with the IDE HTML editor. Beyond the fact that
reformatting the text is brain dead (and I am not just talking about the
switching from design to HTML). I am putting...
|
by: =?Utf-8?B?cm9kY2hhcg==?= |
last post by:
hey all,
in regards to the visual studio code editor (for any language), and in
additon to auto outlining it would be nice if we could hide our own lines of
code at the same time.
i know you...
|
by: somenath |
last post by:
Hi All,
I was trying to write a function which will read one line from a
specified file and return the line. It is currently working fine.
But it would be very much helpful for me if some one...
|
by: Nickolai Leschov |
last post by:
Hello all,
I am programming an embedded controller that has a 'C' library for using
its system functions (I/O, timers, all the specific devices). The
supplied library has .LIB and .H files.
...
|
by: DolphinDB |
last post by:
Tired of spending countless mintues downsampling your data? Look no further!
In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: Vimpel783 |
last post by:
Hello!
Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: Defcon1945 |
last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
|
by: af34tf |
last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
| |