Hi,
the size of the tempDB increased drastically all of a sudden.
How do i find out the cause for the same
thnks
anu
It could be just about anything. You can have a Profiler trace running and correlate what happened
at the time the size increased, but I don't know of a way to determine this after the fact (without
that profiler trace).
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
news:49F0462F-7925-45B0-B02A-6F22A520BD8F@.microsoft.com...
> Hi,
> the size of the tempDB increased drastically all of a sudden.
> How do i find out the cause for the same
> thnks
> anu
|||thnks tibor...
im new to sql dba works...
can you help me out with some url / link / info on how i can reset the
size... itz grown to arond 130 GB now...
thnks in advance
anu
"Tibor Karaszi" wrote:
> It could be just about anything. You can have a Profiler trace running and correlate what happened
> at the time the size increased, but I don't know of a way to determine this after the fact (without
> that profiler trace).
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
> news:49F0462F-7925-45B0-B02A-6F22A520BD8F@.microsoft.com...
>
>
|||Ahuradha
The reason for growing temdbd database might be a long running query / lots
of sort operations that have done by the query
I think Aaron has written a great article at his site
"Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
news:49F0462F-7925-45B0-B02A-6F22A520BD8F@.microsoft.com...
> Hi,
> the size of the tempDB increased drastically all of a sudden.
> How do i find out the cause for the same
> thnks
> anu
|||Easiest way is to restart SQL Server, as tempdb is re-created each time SQL server starts (size for
tempdb at startup is drawn from master..sysaltfiles, which you can set using ALTER DATABASE)
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
news:C415A0D1-6EDF-4D91-B878-205CE63A03F5@.microsoft.com...[vbcol=seagreen]
> thnks tibor...
> im new to sql dba works...
> can you help me out with some url / link / info on how i can reset the
> size... itz grown to arond 130 GB now...
>
> thnks in advance
> anu
> "Tibor Karaszi" wrote:
happened[vbcol=seagreen]
(without[vbcol=seagreen]
|||thnks uri,
can u pls mail me the url ?
"Uri Dimant" wrote:
> Ahuradha
> The reason for growing temdbd database might be a long running query / lots
> of sort operations that have done by the query
> I think Aaron has written a great article at his site
>
> "Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
> news:49F0462F-7925-45B0-B02A-6F22A520BD8F@.microsoft.com...
>
>
|||http://www.aspfaq.com/show.asp?id=2446
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
news:780932A8-2D49-4092-9D91-5C24E0D6AA43@.microsoft.com...[vbcol=seagreen]
> thnks uri,
> can u pls mail me the url ?
>
> "Uri Dimant" wrote:
Showing posts with label tempdb. Show all posts
Showing posts with label tempdb. Show all posts
Friday, March 30, 2012
increase in the size of tempDB
Hi,
the size of the tempDB increased drastically all of a sudden.
How do i find out the cause for the same
thnks
anuIt could be just about anything. You can have a Profiler trace running and c
orrelate what happened
at the time the size increased, but I don't know of a way to determine this
after the fact (without
that profiler trace).
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
news:49F0462F-7925-45B0-B02A-6F22A520BD8F@.microsoft.com...
> Hi,
> the size of the tempDB increased drastically all of a sudden.
> How do i find out the cause for the same
> thnks
> anu|||thnks tibor...
im new to sql dba works...
can you help me out with some url / link / info on how i can reset the
size... itz grown to arond 130 GB now...
thnks in advance
anu
"Tibor Karaszi" wrote:
> It could be just about anything. You can have a Profiler trace running and
correlate what happened
> at the time the size increased, but I don't know of a way to determine thi
s after the fact (without
> that profiler trace).
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
> news:49F0462F-7925-45B0-B02A-6F22A520BD8F@.microsoft.com...
>
>|||Ahuradha
The reason for growing temdbd database might be a long running query / lots
of sort operations that have done by the query
I think Aaron has written a great article at his site
"Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
news:49F0462F-7925-45B0-B02A-6F22A520BD8F@.microsoft.com...
> Hi,
> the size of the tempDB increased drastically all of a sudden.
> How do i find out the cause for the same
> thnks
> anu|||Easiest way is to restart SQL Server, as tempdb is re-created each time SQL
server starts (size for
tempdb at startup is drawn from master..sysaltfiles, which you can set using
ALTER DATABASE)
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
news:C415A0D1-6EDF-4D91-B878-205CE63A03F5@.microsoft.com...[vbcol=seagreen]
> thnks tibor...
> im new to sql dba works...
> can you help me out with some url / link / info on how i can reset the
> size... itz grown to arond 130 GB now...
>
> thnks in advance
> anu
> "Tibor Karaszi" wrote:
>
happened[vbcol=seagreen]
(without[vbcol=seagreen]|||thnks uri,
can u pls mail me the url ?
"Uri Dimant" wrote:
> Ahuradha
> The reason for growing temdbd database might be a long running query / lot
s
> of sort operations that have done by the query
> I think Aaron has written a great article at his site
>
> "Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
> news:49F0462F-7925-45B0-B02A-6F22A520BD8F@.microsoft.com...
>
>|||http://www.aspfaq.com/show.asp?id=2446
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
news:780932A8-2D49-4092-9D91-5C24E0D6AA43@.microsoft.com...[vbcol=seagreen]
> thnks uri,
> can u pls mail me the url ?
>
> "Uri Dimant" wrote:
>
the size of the tempDB increased drastically all of a sudden.
How do i find out the cause for the same
thnks
anuIt could be just about anything. You can have a Profiler trace running and c
orrelate what happened
at the time the size increased, but I don't know of a way to determine this
after the fact (without
that profiler trace).
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
news:49F0462F-7925-45B0-B02A-6F22A520BD8F@.microsoft.com...
> Hi,
> the size of the tempDB increased drastically all of a sudden.
> How do i find out the cause for the same
> thnks
> anu|||thnks tibor...
im new to sql dba works...
can you help me out with some url / link / info on how i can reset the
size... itz grown to arond 130 GB now...
thnks in advance
anu
"Tibor Karaszi" wrote:
> It could be just about anything. You can have a Profiler trace running and
correlate what happened
> at the time the size increased, but I don't know of a way to determine thi
s after the fact (without
> that profiler trace).
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
> news:49F0462F-7925-45B0-B02A-6F22A520BD8F@.microsoft.com...
>
>|||Ahuradha
The reason for growing temdbd database might be a long running query / lots
of sort operations that have done by the query
I think Aaron has written a great article at his site
"Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
news:49F0462F-7925-45B0-B02A-6F22A520BD8F@.microsoft.com...
> Hi,
> the size of the tempDB increased drastically all of a sudden.
> How do i find out the cause for the same
> thnks
> anu|||Easiest way is to restart SQL Server, as tempdb is re-created each time SQL
server starts (size for
tempdb at startup is drawn from master..sysaltfiles, which you can set using
ALTER DATABASE)
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
news:C415A0D1-6EDF-4D91-B878-205CE63A03F5@.microsoft.com...[vbcol=seagreen]
> thnks tibor...
> im new to sql dba works...
> can you help me out with some url / link / info on how i can reset the
> size... itz grown to arond 130 GB now...
>
> thnks in advance
> anu
> "Tibor Karaszi" wrote:
>
happened[vbcol=seagreen]
(without[vbcol=seagreen]|||thnks uri,
can u pls mail me the url ?
"Uri Dimant" wrote:
> Ahuradha
> The reason for growing temdbd database might be a long running query / lot
s
> of sort operations that have done by the query
> I think Aaron has written a great article at his site
>
> "Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
> news:49F0462F-7925-45B0-B02A-6F22A520BD8F@.microsoft.com...
>
>|||http://www.aspfaq.com/show.asp?id=2446
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
news:780932A8-2D49-4092-9D91-5C24E0D6AA43@.microsoft.com...[vbcol=seagreen]
> thnks uri,
> can u pls mail me the url ?
>
> "Uri Dimant" wrote:
>
increase in the size of tempDB
Hi,
the size of the tempDB increased drastically all of a sudden.
How do i find out the cause for the same
thnks
anuIt could be just about anything. You can have a Profiler trace running and correlate what happened
at the time the size increased, but I don't know of a way to determine this after the fact (without
that profiler trace).
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
news:49F0462F-7925-45B0-B02A-6F22A520BD8F@.microsoft.com...
> Hi,
> the size of the tempDB increased drastically all of a sudden.
> How do i find out the cause for the same
> thnks
> anu|||thnks tibor...
im new to sql dba works...
can you help me out with some url / link / info on how i can reset the
size... itz grown to arond 130 GB now...
thnks in advance
anu
"Tibor Karaszi" wrote:
> It could be just about anything. You can have a Profiler trace running and correlate what happened
> at the time the size increased, but I don't know of a way to determine this after the fact (without
> that profiler trace).
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
> news:49F0462F-7925-45B0-B02A-6F22A520BD8F@.microsoft.com...
> > Hi,
> >
> > the size of the tempDB increased drastically all of a sudden.
> >
> > How do i find out the cause for the same
> >
> > thnks
> >
> > anu
>
>|||Ahuradha
The reason for growing temdbd database might be a long running query / lots
of sort operations that have done by the query
I think Aaron has written a great article at his site
"Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
news:49F0462F-7925-45B0-B02A-6F22A520BD8F@.microsoft.com...
> Hi,
> the size of the tempDB increased drastically all of a sudden.
> How do i find out the cause for the same
> thnks
> anu|||Easiest way is to restart SQL Server, as tempdb is re-created each time SQL server starts (size for
tempdb at startup is drawn from master..sysaltfiles, which you can set using ALTER DATABASE)
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
news:C415A0D1-6EDF-4D91-B878-205CE63A03F5@.microsoft.com...
> thnks tibor...
> im new to sql dba works...
> can you help me out with some url / link / info on how i can reset the
> size... itz grown to arond 130 GB now...
>
> thnks in advance
> anu
> "Tibor Karaszi" wrote:
> > It could be just about anything. You can have a Profiler trace running and correlate what
happened
> > at the time the size increased, but I don't know of a way to determine this after the fact
(without
> > that profiler trace).
> >
> > --
> > Tibor Karaszi, SQL Server MVP
> > http://www.karaszi.com/sqlserver/default.asp
> > http://www.solidqualitylearning.com/
> >
> >
> > "Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
> > news:49F0462F-7925-45B0-B02A-6F22A520BD8F@.microsoft.com...
> > > Hi,
> > >
> > > the size of the tempDB increased drastically all of a sudden.
> > >
> > > How do i find out the cause for the same
> > >
> > > thnks
> > >
> > > anu
> >
> >
> >|||thnks uri,
can u pls mail me the url ?
"Uri Dimant" wrote:
> Ahuradha
> The reason for growing temdbd database might be a long running query / lots
> of sort operations that have done by the query
> I think Aaron has written a great article at his site
>
> "Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
> news:49F0462F-7925-45B0-B02A-6F22A520BD8F@.microsoft.com...
> > Hi,
> >
> > the size of the tempDB increased drastically all of a sudden.
> >
> > How do i find out the cause for the same
> >
> > thnks
> >
> > anu
>
>|||http://www.aspfaq.com/show.asp?id=2446
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
news:780932A8-2D49-4092-9D91-5C24E0D6AA43@.microsoft.com...
> thnks uri,
> can u pls mail me the url ?
>
> "Uri Dimant" wrote:
> > Ahuradha
> > The reason for growing temdbd database might be a long running query / lots
> > of sort operations that have done by the query
> > I think Aaron has written a great article at his site
> >
> >
> >
> > "Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
> > news:49F0462F-7925-45B0-B02A-6F22A520BD8F@.microsoft.com...
> > > Hi,
> > >
> > > the size of the tempDB increased drastically all of a sudden.
> > >
> > > How do i find out the cause for the same
> > >
> > > thnks
> > >
> > > anu
> >
> >
> >
the size of the tempDB increased drastically all of a sudden.
How do i find out the cause for the same
thnks
anuIt could be just about anything. You can have a Profiler trace running and correlate what happened
at the time the size increased, but I don't know of a way to determine this after the fact (without
that profiler trace).
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
news:49F0462F-7925-45B0-B02A-6F22A520BD8F@.microsoft.com...
> Hi,
> the size of the tempDB increased drastically all of a sudden.
> How do i find out the cause for the same
> thnks
> anu|||thnks tibor...
im new to sql dba works...
can you help me out with some url / link / info on how i can reset the
size... itz grown to arond 130 GB now...
thnks in advance
anu
"Tibor Karaszi" wrote:
> It could be just about anything. You can have a Profiler trace running and correlate what happened
> at the time the size increased, but I don't know of a way to determine this after the fact (without
> that profiler trace).
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
> news:49F0462F-7925-45B0-B02A-6F22A520BD8F@.microsoft.com...
> > Hi,
> >
> > the size of the tempDB increased drastically all of a sudden.
> >
> > How do i find out the cause for the same
> >
> > thnks
> >
> > anu
>
>|||Ahuradha
The reason for growing temdbd database might be a long running query / lots
of sort operations that have done by the query
I think Aaron has written a great article at his site
"Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
news:49F0462F-7925-45B0-B02A-6F22A520BD8F@.microsoft.com...
> Hi,
> the size of the tempDB increased drastically all of a sudden.
> How do i find out the cause for the same
> thnks
> anu|||Easiest way is to restart SQL Server, as tempdb is re-created each time SQL server starts (size for
tempdb at startup is drawn from master..sysaltfiles, which you can set using ALTER DATABASE)
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
news:C415A0D1-6EDF-4D91-B878-205CE63A03F5@.microsoft.com...
> thnks tibor...
> im new to sql dba works...
> can you help me out with some url / link / info on how i can reset the
> size... itz grown to arond 130 GB now...
>
> thnks in advance
> anu
> "Tibor Karaszi" wrote:
> > It could be just about anything. You can have a Profiler trace running and correlate what
happened
> > at the time the size increased, but I don't know of a way to determine this after the fact
(without
> > that profiler trace).
> >
> > --
> > Tibor Karaszi, SQL Server MVP
> > http://www.karaszi.com/sqlserver/default.asp
> > http://www.solidqualitylearning.com/
> >
> >
> > "Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
> > news:49F0462F-7925-45B0-B02A-6F22A520BD8F@.microsoft.com...
> > > Hi,
> > >
> > > the size of the tempDB increased drastically all of a sudden.
> > >
> > > How do i find out the cause for the same
> > >
> > > thnks
> > >
> > > anu
> >
> >
> >|||thnks uri,
can u pls mail me the url ?
"Uri Dimant" wrote:
> Ahuradha
> The reason for growing temdbd database might be a long running query / lots
> of sort operations that have done by the query
> I think Aaron has written a great article at his site
>
> "Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
> news:49F0462F-7925-45B0-B02A-6F22A520BD8F@.microsoft.com...
> > Hi,
> >
> > the size of the tempDB increased drastically all of a sudden.
> >
> > How do i find out the cause for the same
> >
> > thnks
> >
> > anu
>
>|||http://www.aspfaq.com/show.asp?id=2446
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
news:780932A8-2D49-4092-9D91-5C24E0D6AA43@.microsoft.com...
> thnks uri,
> can u pls mail me the url ?
>
> "Uri Dimant" wrote:
> > Ahuradha
> > The reason for growing temdbd database might be a long running query / lots
> > of sort operations that have done by the query
> > I think Aaron has written a great article at his site
> >
> >
> >
> > "Anuradha" <Anuradha@.discussions.microsoft.com> wrote in message
> > news:49F0462F-7925-45B0-B02A-6F22A520BD8F@.microsoft.com...
> > > Hi,
> > >
> > > the size of the tempDB increased drastically all of a sudden.
> > >
> > > How do i find out the cause for the same
> > >
> > > thnks
> > >
> > > anu
> >
> >
> >
Increase Default Tlog size of Tempdb
Hello,
When we start the SQL Server default size of temp db is 8 MB. I would like
to make the default tempdb Data 200 MB and Tlog 100 MB.
For Data we can increase the size of model database and it works fine. But
the same is not working in case of Tlog.
Can anybody have idea how to do the set up? I don't want to use startup
script for Alter tempdb database.
Thanks in advance.
MB
Just use ALTER DATABASE tempdb MODIFY FILE. Or use the GUI to specify the desired size. The
specified file size will be persisted and used upon following startups.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"MB" <MB@.MB.com> wrote in message news:uXUN2MZrHHA.3228@.TK2MSFTNGP03.phx.gbl...
> Hello,
> When we start the SQL Server default size of temp db is 8 MB. I would like to make the default
> tempdb Data 200 MB and Tlog 100 MB.
> For Data we can increase the size of model database and it works fine. But the same is not working
> in case of Tlog.
> Can anybody have idea how to do the set up? I don't want to use startup script for Alter tempdb
> database.
> Thanks in advance.
> MB
>
When we start the SQL Server default size of temp db is 8 MB. I would like
to make the default tempdb Data 200 MB and Tlog 100 MB.
For Data we can increase the size of model database and it works fine. But
the same is not working in case of Tlog.
Can anybody have idea how to do the set up? I don't want to use startup
script for Alter tempdb database.
Thanks in advance.
MB
Just use ALTER DATABASE tempdb MODIFY FILE. Or use the GUI to specify the desired size. The
specified file size will be persisted and used upon following startups.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"MB" <MB@.MB.com> wrote in message news:uXUN2MZrHHA.3228@.TK2MSFTNGP03.phx.gbl...
> Hello,
> When we start the SQL Server default size of temp db is 8 MB. I would like to make the default
> tempdb Data 200 MB and Tlog 100 MB.
> For Data we can increase the size of model database and it works fine. But the same is not working
> in case of Tlog.
> Can anybody have idea how to do the set up? I don't want to use startup script for Alter tempdb
> database.
> Thanks in advance.
> MB
>
Increase Default Tlog size of Tempdb
Hello,
When we start the SQL Server default size of temp db is 8 MB. I would like
to make the default tempdb Data 200 MB and Tlog 100 MB.
For Data we can increase the size of model database and it works fine. But
the same is not working in case of Tlog.
Can anybody have idea how to do the set up? I don't want to use startup
script for Alter tempdb database.
Thanks in advance.
MBJust use ALTER DATABASE tempdb MODIFY FILE. Or use the GUI to specify the de
sired size. The
specified file size will be persisted and used upon following startups.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"MB" <MB@.MB.com> wrote in message news:uXUN2MZrHHA.3228@.TK2MSFTNGP03.phx.gbl...en">
> Hello,
> When we start the SQL Server default size of temp db is 8 MB. I would like
to make the default
> tempdb Data 200 MB and Tlog 100 MB.
> For Data we can increase the size of model database and it works fine. But
the same is not working
> in case of Tlog.
> Can anybody have idea how to do the set up? I don't want to use startup sc
ript for Alter tempdb
> database.
> Thanks in advance.
> MB
>
When we start the SQL Server default size of temp db is 8 MB. I would like
to make the default tempdb Data 200 MB and Tlog 100 MB.
For Data we can increase the size of model database and it works fine. But
the same is not working in case of Tlog.
Can anybody have idea how to do the set up? I don't want to use startup
script for Alter tempdb database.
Thanks in advance.
MBJust use ALTER DATABASE tempdb MODIFY FILE. Or use the GUI to specify the de
sired size. The
specified file size will be persisted and used upon following startups.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"MB" <MB@.MB.com> wrote in message news:uXUN2MZrHHA.3228@.TK2MSFTNGP03.phx.gbl...en">
> Hello,
> When we start the SQL Server default size of temp db is 8 MB. I would like
to make the default
> tempdb Data 200 MB and Tlog 100 MB.
> For Data we can increase the size of model database and it works fine. But
the same is not working
> in case of Tlog.
> Can anybody have idea how to do the set up? I don't want to use startup sc
ript for Alter tempdb
> database.
> Thanks in advance.
> MB
>
Increase Default Tlog size of Tempdb
Hello,
When we start the SQL Server default size of temp db is 8 MB. I would like
to make the default tempdb Data 200 MB and Tlog 100 MB.
For Data we can increase the size of model database and it works fine. But
the same is not working in case of Tlog.
Can anybody have idea how to do the set up? I don't want to use startup
script for Alter tempdb database.
Thanks in advance.
MBJust use ALTER DATABASE tempdb MODIFY FILE. Or use the GUI to specify the desired size. The
specified file size will be persisted and used upon following startups.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"MB" <MB@.MB.com> wrote in message news:uXUN2MZrHHA.3228@.TK2MSFTNGP03.phx.gbl...
> Hello,
> When we start the SQL Server default size of temp db is 8 MB. I would like to make the default
> tempdb Data 200 MB and Tlog 100 MB.
> For Data we can increase the size of model database and it works fine. But the same is not working
> in case of Tlog.
> Can anybody have idea how to do the set up? I don't want to use startup script for Alter tempdb
> database.
> Thanks in advance.
> MB
>
When we start the SQL Server default size of temp db is 8 MB. I would like
to make the default tempdb Data 200 MB and Tlog 100 MB.
For Data we can increase the size of model database and it works fine. But
the same is not working in case of Tlog.
Can anybody have idea how to do the set up? I don't want to use startup
script for Alter tempdb database.
Thanks in advance.
MBJust use ALTER DATABASE tempdb MODIFY FILE. Or use the GUI to specify the desired size. The
specified file size will be persisted and used upon following startups.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"MB" <MB@.MB.com> wrote in message news:uXUN2MZrHHA.3228@.TK2MSFTNGP03.phx.gbl...
> Hello,
> When we start the SQL Server default size of temp db is 8 MB. I would like to make the default
> tempdb Data 200 MB and Tlog 100 MB.
> For Data we can increase the size of model database and it works fine. But the same is not working
> in case of Tlog.
> Can anybody have idea how to do the set up? I don't want to use startup script for Alter tempdb
> database.
> Thanks in advance.
> MB
>
Monday, March 19, 2012
Incorrect data in sysdatabases compatability level column
Hello,
I've noticed that if you have model and tempdb to different compatability
levels and restart the sql instance, the value in sysdatabases (cmptlevel)
does not get changed correctly.
Here's how to reproduce:
1. set model compatability to one level, say 9.0
2. set tempdb compatability to diff. level, say 8.0
3. verify in SSMS db -> properties -> options
or select * from master..sysdatabases
4. run an old join query from tempdb to show it is actually in 8.0
compatability
-> select * from sysobjects o, syscolumn c where o.id *= c.id
if it runs, the compatability is set to 8.0
5. now restart your db instance
6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
8.0 compatability, but you get an error message when running the query which
means the database is in 9.0
Can anyone explain? or is it possible this is a bug?
thanksPlease ignore this one, I resubmitted this same ticket the to SQL Server
category of threads.
"paul" wrote:
> Hello,
> I've noticed that if you have model and tempdb to different compatability
> levels and restart the sql instance, the value in sysdatabases (cmptlevel)
> does not get changed correctly.
> Here's how to reproduce:
> 1. set model compatability to one level, say 9.0
> 2. set tempdb compatability to diff. level, say 8.0
> 3. verify in SSMS db -> properties -> options
> or select * from master..sysdatabases
> 4. run an old join query from tempdb to show it is actually in 8.0
> compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
> 5. now restart your db instance
> 6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is
in
> 8.0 compatability, but you get an error message when running the query whi
ch
> means the database is in 9.0
> Can anyone explain? or is it possible this is a bug?
> thanks
>
>
I've noticed that if you have model and tempdb to different compatability
levels and restart the sql instance, the value in sysdatabases (cmptlevel)
does not get changed correctly.
Here's how to reproduce:
1. set model compatability to one level, say 9.0
2. set tempdb compatability to diff. level, say 8.0
3. verify in SSMS db -> properties -> options
or select * from master..sysdatabases
4. run an old join query from tempdb to show it is actually in 8.0
compatability
-> select * from sysobjects o, syscolumn c where o.id *= c.id
if it runs, the compatability is set to 8.0
5. now restart your db instance
6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
8.0 compatability, but you get an error message when running the query which
means the database is in 9.0
Can anyone explain? or is it possible this is a bug?
thanksPlease ignore this one, I resubmitted this same ticket the to SQL Server
category of threads.
"paul" wrote:
> Hello,
> I've noticed that if you have model and tempdb to different compatability
> levels and restart the sql instance, the value in sysdatabases (cmptlevel)
> does not get changed correctly.
> Here's how to reproduce:
> 1. set model compatability to one level, say 9.0
> 2. set tempdb compatability to diff. level, say 8.0
> 3. verify in SSMS db -> properties -> options
> or select * from master..sysdatabases
> 4. run an old join query from tempdb to show it is actually in 8.0
> compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
> 5. now restart your db instance
> 6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is
in
> 8.0 compatability, but you get an error message when running the query whi
ch
> means the database is in 9.0
> Can anyone explain? or is it possible this is a bug?
> thanks
>
>
Incorrect data in sysdatabases compatability level column
Hello,
I've noticed that if you have model and tempdb to different compatability
levels and restart the sql instance, the value in sysdatabases (cmptlevel)
does not get changed correctly.
Here's how to reproduce:
1. set model compatability to one level, say 9.0
2. set tempdb compatability to diff. level, say 8.0
3. verify in SSMS db -> properties -> options
or select * from master..sysdatabases
4. run an old join query from tempdb to show it is actually in 8.0
compatability
-> select * from sysobjects o, syscolumn c where o.id *= c.id
if it runs, the compatability is set to 8.0
5. now restart your db instance
6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
8.0 compatability, but you get an error message when running the query which
means the database is in 9.0
Can anyone explain? or is it possible this is a bug?
thanks
Sorry, I forgot to tell you to run the test query below from the tempdb to
either produce an error message or not. The connection's current db
determines compatability level.
"paul" wrote:
> Hello,
>
> I've noticed that if you have model and tempdb to different compatability
> levels and restart the sql instance, the value in sysdatabases (cmptlevel)
> does not get changed correctly.
> Here's how to reproduce:
> 1. set model compatability to one level, say 9.0
> 2. set tempdb compatability to diff. level, say 8.0
> 3. verify in SSMS db -> properties -> options
> or select * from master..sysdatabases
> 4. run an old join query from tempdb to show it is actually in 8.0
> compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
> 5. now restart your db instance
> 6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
> 8.0 compatability, but you get an error message when running the query which
> means the database is in 9.0
> Can anyone explain? or is it possible this is a bug?
> thanks
>
>
|||For what it is worth, I would not mess with the compatibilty level of
either tempdb or model. I know the idea is that you can set model to
match what you want from a new database, but as tempdb is effectively
recreated from model each time SQL Server starts it sounds like asking
for trouble.
Roy Harvey
Beacon Falls, CT
On Mon, 16 Jul 2007 11:14:08 -0700, paul
<paul@.discussions.microsoft.com> wrote:
>Hello,
>
>I've noticed that if you have model and tempdb to different compatability
>levels and restart the sql instance, the value in sysdatabases (cmptlevel)
>does not get changed correctly.
>Here's how to reproduce:
>1. set model compatability to one level, say 9.0
>2. set tempdb compatability to diff. level, say 8.0
>3. verify in SSMS db -> properties -> options
>or select * from master..sysdatabases
>4. run an old join query from tempdb to show it is actually in 8.0
>compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
>5. now restart your db instance
>6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
>8.0 compatability, but you get an error message when running the query which
>means the database is in 9.0
>Can anyone explain? or is it possible this is a bug?
>thanks
>
I've noticed that if you have model and tempdb to different compatability
levels and restart the sql instance, the value in sysdatabases (cmptlevel)
does not get changed correctly.
Here's how to reproduce:
1. set model compatability to one level, say 9.0
2. set tempdb compatability to diff. level, say 8.0
3. verify in SSMS db -> properties -> options
or select * from master..sysdatabases
4. run an old join query from tempdb to show it is actually in 8.0
compatability
-> select * from sysobjects o, syscolumn c where o.id *= c.id
if it runs, the compatability is set to 8.0
5. now restart your db instance
6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
8.0 compatability, but you get an error message when running the query which
means the database is in 9.0
Can anyone explain? or is it possible this is a bug?
thanks
Sorry, I forgot to tell you to run the test query below from the tempdb to
either produce an error message or not. The connection's current db
determines compatability level.
"paul" wrote:
> Hello,
>
> I've noticed that if you have model and tempdb to different compatability
> levels and restart the sql instance, the value in sysdatabases (cmptlevel)
> does not get changed correctly.
> Here's how to reproduce:
> 1. set model compatability to one level, say 9.0
> 2. set tempdb compatability to diff. level, say 8.0
> 3. verify in SSMS db -> properties -> options
> or select * from master..sysdatabases
> 4. run an old join query from tempdb to show it is actually in 8.0
> compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
> 5. now restart your db instance
> 6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
> 8.0 compatability, but you get an error message when running the query which
> means the database is in 9.0
> Can anyone explain? or is it possible this is a bug?
> thanks
>
>
|||For what it is worth, I would not mess with the compatibilty level of
either tempdb or model. I know the idea is that you can set model to
match what you want from a new database, but as tempdb is effectively
recreated from model each time SQL Server starts it sounds like asking
for trouble.
Roy Harvey
Beacon Falls, CT
On Mon, 16 Jul 2007 11:14:08 -0700, paul
<paul@.discussions.microsoft.com> wrote:
>Hello,
>
>I've noticed that if you have model and tempdb to different compatability
>levels and restart the sql instance, the value in sysdatabases (cmptlevel)
>does not get changed correctly.
>Here's how to reproduce:
>1. set model compatability to one level, say 9.0
>2. set tempdb compatability to diff. level, say 8.0
>3. verify in SSMS db -> properties -> options
>or select * from master..sysdatabases
>4. run an old join query from tempdb to show it is actually in 8.0
>compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
>5. now restart your db instance
>6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
>8.0 compatability, but you get an error message when running the query which
>means the database is in 9.0
>Can anyone explain? or is it possible this is a bug?
>thanks
>
Incorrect data in sysdatabases compatability level column
Hello,
I've noticed that if you have model and tempdb to different compatability
levels and restart the sql instance, the value in sysdatabases (cmptlevel)
does not get changed correctly.
Here's how to reproduce:
1. set model compatability to one level, say 9.0
2. set tempdb compatability to diff. level, say 8.0
3. verify in SSMS db -> properties -> options
or select * from master..sysdatabases
4. run an old join query from tempdb to show it is actually in 8.0
compatability
-> select * from sysobjects o, syscolumn c where o.id *= c.id
if it runs, the compatability is set to 8.0
5. now restart your db instance
6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
8.0 compatability, but you get an error message when running the query which
means the database is in 9.0
Can anyone explain? or is it possible this is a bug?
thanks
Please ignore this one, I resubmitted this same ticket the to SQL Server
category of threads.
"paul" wrote:
> Hello,
> I've noticed that if you have model and tempdb to different compatability
> levels and restart the sql instance, the value in sysdatabases (cmptlevel)
> does not get changed correctly.
> Here's how to reproduce:
> 1. set model compatability to one level, say 9.0
> 2. set tempdb compatability to diff. level, say 8.0
> 3. verify in SSMS db -> properties -> options
> or select * from master..sysdatabases
> 4. run an old join query from tempdb to show it is actually in 8.0
> compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
> 5. now restart your db instance
> 6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
> 8.0 compatability, but you get an error message when running the query which
> means the database is in 9.0
> Can anyone explain? or is it possible this is a bug?
> thanks
>
>
I've noticed that if you have model and tempdb to different compatability
levels and restart the sql instance, the value in sysdatabases (cmptlevel)
does not get changed correctly.
Here's how to reproduce:
1. set model compatability to one level, say 9.0
2. set tempdb compatability to diff. level, say 8.0
3. verify in SSMS db -> properties -> options
or select * from master..sysdatabases
4. run an old join query from tempdb to show it is actually in 8.0
compatability
-> select * from sysobjects o, syscolumn c where o.id *= c.id
if it runs, the compatability is set to 8.0
5. now restart your db instance
6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
8.0 compatability, but you get an error message when running the query which
means the database is in 9.0
Can anyone explain? or is it possible this is a bug?
thanks
Please ignore this one, I resubmitted this same ticket the to SQL Server
category of threads.
"paul" wrote:
> Hello,
> I've noticed that if you have model and tempdb to different compatability
> levels and restart the sql instance, the value in sysdatabases (cmptlevel)
> does not get changed correctly.
> Here's how to reproduce:
> 1. set model compatability to one level, say 9.0
> 2. set tempdb compatability to diff. level, say 8.0
> 3. verify in SSMS db -> properties -> options
> or select * from master..sysdatabases
> 4. run an old join query from tempdb to show it is actually in 8.0
> compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
> 5. now restart your db instance
> 6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
> 8.0 compatability, but you get an error message when running the query which
> means the database is in 9.0
> Can anyone explain? or is it possible this is a bug?
> thanks
>
>
Incorrect data in sysdatabases compatability level column
Hello,
I've noticed that if you have model and tempdb to different compatability
levels and restart the sql instance, the value in sysdatabases (cmptlevel)
does not get changed correctly.
Here's how to reproduce:
1. set model compatability to one level, say 9.0
2. set tempdb compatability to diff. level, say 8.0
3. verify in SSMS db -> properties -> options
or select * from master..sysdatabases
4. run an old join query from tempdb to show it is actually in 8.0
compatability
-> select * from sysobjects o, syscolumn c where o.id *= c.id
if it runs, the compatability is set to 8.0
5. now restart your db instance
6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
8.0 compatability, but you get an error message when running the query which
means the database is in 9.0
Can anyone explain? or is it possible this is a bug?
thanksSorry, I forgot to tell you to run the test query below from the tempdb to
either produce an error message or not. The connection's current db
determines compatability level.
"paul" wrote:
> Hello,
>
> I've noticed that if you have model and tempdb to different compatability
> levels and restart the sql instance, the value in sysdatabases (cmptlevel)
> does not get changed correctly.
> Here's how to reproduce:
> 1. set model compatability to one level, say 9.0
> 2. set tempdb compatability to diff. level, say 8.0
> 3. verify in SSMS db -> properties -> options
> or select * from master..sysdatabases
> 4. run an old join query from tempdb to show it is actually in 8.0
> compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
> 5. now restart your db instance
> 6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
> 8.0 compatability, but you get an error message when running the query which
> means the database is in 9.0
> Can anyone explain? or is it possible this is a bug?
> thanks
>
>|||For what it is worth, I would not mess with the compatibilty level of
either tempdb or model. I know the idea is that you can set model to
match what you want from a new database, but as tempdb is effectively
recreated from model each time SQL Server starts it sounds like asking
for trouble.
Roy Harvey
Beacon Falls, CT
On Mon, 16 Jul 2007 11:14:08 -0700, paul
<paul@.discussions.microsoft.com> wrote:
>Hello,
>
>I've noticed that if you have model and tempdb to different compatability
>levels and restart the sql instance, the value in sysdatabases (cmptlevel)
>does not get changed correctly.
>Here's how to reproduce:
>1. set model compatability to one level, say 9.0
>2. set tempdb compatability to diff. level, say 8.0
>3. verify in SSMS db -> properties -> options
>or select * from master..sysdatabases
>4. run an old join query from tempdb to show it is actually in 8.0
>compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
>5. now restart your db instance
>6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
>8.0 compatability, but you get an error message when running the query which
>means the database is in 9.0
>Can anyone explain? or is it possible this is a bug?
>thanks
>
I've noticed that if you have model and tempdb to different compatability
levels and restart the sql instance, the value in sysdatabases (cmptlevel)
does not get changed correctly.
Here's how to reproduce:
1. set model compatability to one level, say 9.0
2. set tempdb compatability to diff. level, say 8.0
3. verify in SSMS db -> properties -> options
or select * from master..sysdatabases
4. run an old join query from tempdb to show it is actually in 8.0
compatability
-> select * from sysobjects o, syscolumn c where o.id *= c.id
if it runs, the compatability is set to 8.0
5. now restart your db instance
6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
8.0 compatability, but you get an error message when running the query which
means the database is in 9.0
Can anyone explain? or is it possible this is a bug?
thanksSorry, I forgot to tell you to run the test query below from the tempdb to
either produce an error message or not. The connection's current db
determines compatability level.
"paul" wrote:
> Hello,
>
> I've noticed that if you have model and tempdb to different compatability
> levels and restart the sql instance, the value in sysdatabases (cmptlevel)
> does not get changed correctly.
> Here's how to reproduce:
> 1. set model compatability to one level, say 9.0
> 2. set tempdb compatability to diff. level, say 8.0
> 3. verify in SSMS db -> properties -> options
> or select * from master..sysdatabases
> 4. run an old join query from tempdb to show it is actually in 8.0
> compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
> 5. now restart your db instance
> 6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
> 8.0 compatability, but you get an error message when running the query which
> means the database is in 9.0
> Can anyone explain? or is it possible this is a bug?
> thanks
>
>|||For what it is worth, I would not mess with the compatibilty level of
either tempdb or model. I know the idea is that you can set model to
match what you want from a new database, but as tempdb is effectively
recreated from model each time SQL Server starts it sounds like asking
for trouble.
Roy Harvey
Beacon Falls, CT
On Mon, 16 Jul 2007 11:14:08 -0700, paul
<paul@.discussions.microsoft.com> wrote:
>Hello,
>
>I've noticed that if you have model and tempdb to different compatability
>levels and restart the sql instance, the value in sysdatabases (cmptlevel)
>does not get changed correctly.
>Here's how to reproduce:
>1. set model compatability to one level, say 9.0
>2. set tempdb compatability to diff. level, say 8.0
>3. verify in SSMS db -> properties -> options
>or select * from master..sysdatabases
>4. run an old join query from tempdb to show it is actually in 8.0
>compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
>5. now restart your db instance
>6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
>8.0 compatability, but you get an error message when running the query which
>means the database is in 9.0
>Can anyone explain? or is it possible this is a bug?
>thanks
>
Incorrect data in sysdatabases compatability level column
Hello,
I've noticed that if you have model and tempdb to different compatability
levels and restart the sql instance, the value in sysdatabases (cmptlevel)
does not get changed correctly.
Here's how to reproduce:
1. set model compatability to one level, say 9.0
2. set tempdb compatability to diff. level, say 8.0
3. verify in SSMS db -> properties -> options
or select * from master..sysdatabases
4. run an old join query from tempdb to show it is actually in 8.0
compatability
-> select * from sysobjects o, syscolumn c where o.id *= c.id
if it runs, the compatability is set to 8.0
5. now restart your db instance
6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
8.0 compatability, but you get an error message when running the query which
means the database is in 9.0
Can anyone explain? or is it possible this is a bug?
thanksSorry, I forgot to tell you to run the test query below from the tempdb to
either produce an error message or not. The connection's current db
determines compatability level.
"paul" wrote:
> Hello,
>
> I've noticed that if you have model and tempdb to different compatability
> levels and restart the sql instance, the value in sysdatabases (cmptlevel)
> does not get changed correctly.
> Here's how to reproduce:
> 1. set model compatability to one level, say 9.0
> 2. set tempdb compatability to diff. level, say 8.0
> 3. verify in SSMS db -> properties -> options
> or select * from master..sysdatabases
> 4. run an old join query from tempdb to show it is actually in 8.0
> compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
> 5. now restart your db instance
> 6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is
in
> 8.0 compatability, but you get an error message when running the query whi
ch
> means the database is in 9.0
> Can anyone explain? or is it possible this is a bug?
> thanks
>
>|||For what it is worth, I would not mess with the compatibilty level of
either tempdb or model. I know the idea is that you can set model to
match what you want from a new database, but as tempdb is effectively
recreated from model each time SQL Server starts it sounds like asking
for trouble.
Roy Harvey
Beacon Falls, CT
On Mon, 16 Jul 2007 11:14:08 -0700, paul
<paul@.discussions.microsoft.com> wrote:
>Hello,
>
>I've noticed that if you have model and tempdb to different compatability
>levels and restart the sql instance, the value in sysdatabases (cmptlevel)
>does not get changed correctly.
>Here's how to reproduce:
>1. set model compatability to one level, say 9.0
>2. set tempdb compatability to diff. level, say 8.0
>3. verify in SSMS db -> properties -> options
>or select * from master..sysdatabases
>4. run an old join query from tempdb to show it is actually in 8.0
>compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
>5. now restart your db instance
>6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is i
n
>8.0 compatability, but you get an error message when running the query whic
h
>means the database is in 9.0
>Can anyone explain? or is it possible this is a bug?
>thanks
>
I've noticed that if you have model and tempdb to different compatability
levels and restart the sql instance, the value in sysdatabases (cmptlevel)
does not get changed correctly.
Here's how to reproduce:
1. set model compatability to one level, say 9.0
2. set tempdb compatability to diff. level, say 8.0
3. verify in SSMS db -> properties -> options
or select * from master..sysdatabases
4. run an old join query from tempdb to show it is actually in 8.0
compatability
-> select * from sysobjects o, syscolumn c where o.id *= c.id
if it runs, the compatability is set to 8.0
5. now restart your db instance
6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
8.0 compatability, but you get an error message when running the query which
means the database is in 9.0
Can anyone explain? or is it possible this is a bug?
thanksSorry, I forgot to tell you to run the test query below from the tempdb to
either produce an error message or not. The connection's current db
determines compatability level.
"paul" wrote:
> Hello,
>
> I've noticed that if you have model and tempdb to different compatability
> levels and restart the sql instance, the value in sysdatabases (cmptlevel)
> does not get changed correctly.
> Here's how to reproduce:
> 1. set model compatability to one level, say 9.0
> 2. set tempdb compatability to diff. level, say 8.0
> 3. verify in SSMS db -> properties -> options
> or select * from master..sysdatabases
> 4. run an old join query from tempdb to show it is actually in 8.0
> compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
> 5. now restart your db instance
> 6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is
in
> 8.0 compatability, but you get an error message when running the query whi
ch
> means the database is in 9.0
> Can anyone explain? or is it possible this is a bug?
> thanks
>
>|||For what it is worth, I would not mess with the compatibilty level of
either tempdb or model. I know the idea is that you can set model to
match what you want from a new database, but as tempdb is effectively
recreated from model each time SQL Server starts it sounds like asking
for trouble.
Roy Harvey
Beacon Falls, CT
On Mon, 16 Jul 2007 11:14:08 -0700, paul
<paul@.discussions.microsoft.com> wrote:
>Hello,
>
>I've noticed that if you have model and tempdb to different compatability
>levels and restart the sql instance, the value in sysdatabases (cmptlevel)
>does not get changed correctly.
>Here's how to reproduce:
>1. set model compatability to one level, say 9.0
>2. set tempdb compatability to diff. level, say 8.0
>3. verify in SSMS db -> properties -> options
>or select * from master..sysdatabases
>4. run an old join query from tempdb to show it is actually in 8.0
>compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
>5. now restart your db instance
>6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is i
n
>8.0 compatability, but you get an error message when running the query whic
h
>means the database is in 9.0
>Can anyone explain? or is it possible this is a bug?
>thanks
>
Friday, March 9, 2012
Inconsistencies in tempdb
Hi folks
have been getting this error recently. We've swapped-out a disk which
looked to be faulty but this hasn't done the trick so we think that it
may not be a hardware issue but may be due to a problem in tempdb
itself. I have read elsewhere that if the server is restarted, that
the temp db will be recreated, but having done this, the mdf and ldf
still have Craeted dates from way before the restart happened, so that
can't have worked, so I guess my questions are...
1) Is there any way that I can check if the temp db is corrupt?
2) Should the tempdb be recreated from scratch by restarting the
server and if not how should I do this?
any further comments/suggestions would be very welcome
Event Type: Error
Event Source: MSSQLSERVER
Event Category: (2)
Event ID: 5242
Description:
An inconsistency was detected during an internal operation in database
'tempdb'(ID:2) on page (1:5193). Please contact technical support.
Reference number 3.
many thanks
LTHi
Restart SQL Server. TempDB is rebuilt from scratch each time you restart sql
server.
"LaurenceT" <laurencetruman@.gmail.com> wrote in message
news:1178618605.338639.275140@.w5g2000hsg.googlegroups.com...
> Hi folks
> have been getting this error recently. We've swapped-out a disk which
> looked to be faulty but this hasn't done the trick so we think that it
> may not be a hardware issue but may be due to a problem in tempdb
> itself. I have read elsewhere that if the server is restarted, that
> the temp db will be recreated, but having done this, the mdf and ldf
> still have Craeted dates from way before the restart happened, so that
> can't have worked, so I guess my questions are...
> 1) Is there any way that I can check if the temp db is corrupt?
> 2) Should the tempdb be recreated from scratch by restarting the
> server and if not how should I do this?
> any further comments/suggestions would be very welcome
> Event Type: Error
> Event Source: MSSQLSERVER
> Event Category: (2)
> Event ID: 5242
> Description:
> An inconsistency was detected during an internal operation in database
> 'tempdb'(ID:2) on page (1:5193). Please contact technical support.
> Reference number 3.
> many thanks
> LT
>|||If you look at the tempdb files in the file system, the Date Modified
property should reflect the date/time when the instance is recycled. You can
run DBCC CHECKDB on tempdb.
Linchi
"LaurenceT" wrote:
> Hi folks
> have been getting this error recently. We've swapped-out a disk which
> looked to be faulty but this hasn't done the trick so we think that it
> may not be a hardware issue but may be due to a problem in tempdb
> itself. I have read elsewhere that if the server is restarted, that
> the temp db will be recreated, but having done this, the mdf and ldf
> still have Craeted dates from way before the restart happened, so that
> can't have worked, so I guess my questions are...
> 1) Is there any way that I can check if the temp db is corrupt?
> 2) Should the tempdb be recreated from scratch by restarting the
> server and if not how should I do this?
> any further comments/suggestions would be very welcome
> Event Type: Error
> Event Source: MSSQLSERVER
> Event Category: (2)
> Event ID: 5242
> Description:
> An inconsistency was detected during an internal operation in database
> 'tempdb'(ID:2) on page (1:5193). Please contact technical support.
> Reference number 3.
> many thanks
> LT
>
have been getting this error recently. We've swapped-out a disk which
looked to be faulty but this hasn't done the trick so we think that it
may not be a hardware issue but may be due to a problem in tempdb
itself. I have read elsewhere that if the server is restarted, that
the temp db will be recreated, but having done this, the mdf and ldf
still have Craeted dates from way before the restart happened, so that
can't have worked, so I guess my questions are...
1) Is there any way that I can check if the temp db is corrupt?
2) Should the tempdb be recreated from scratch by restarting the
server and if not how should I do this?
any further comments/suggestions would be very welcome
Event Type: Error
Event Source: MSSQLSERVER
Event Category: (2)
Event ID: 5242
Description:
An inconsistency was detected during an internal operation in database
'tempdb'(ID:2) on page (1:5193). Please contact technical support.
Reference number 3.
many thanks
LTHi
Restart SQL Server. TempDB is rebuilt from scratch each time you restart sql
server.
"LaurenceT" <laurencetruman@.gmail.com> wrote in message
news:1178618605.338639.275140@.w5g2000hsg.googlegroups.com...
> Hi folks
> have been getting this error recently. We've swapped-out a disk which
> looked to be faulty but this hasn't done the trick so we think that it
> may not be a hardware issue but may be due to a problem in tempdb
> itself. I have read elsewhere that if the server is restarted, that
> the temp db will be recreated, but having done this, the mdf and ldf
> still have Craeted dates from way before the restart happened, so that
> can't have worked, so I guess my questions are...
> 1) Is there any way that I can check if the temp db is corrupt?
> 2) Should the tempdb be recreated from scratch by restarting the
> server and if not how should I do this?
> any further comments/suggestions would be very welcome
> Event Type: Error
> Event Source: MSSQLSERVER
> Event Category: (2)
> Event ID: 5242
> Description:
> An inconsistency was detected during an internal operation in database
> 'tempdb'(ID:2) on page (1:5193). Please contact technical support.
> Reference number 3.
> many thanks
> LT
>|||If you look at the tempdb files in the file system, the Date Modified
property should reflect the date/time when the instance is recycled. You can
run DBCC CHECKDB on tempdb.
Linchi
"LaurenceT" wrote:
> Hi folks
> have been getting this error recently. We've swapped-out a disk which
> looked to be faulty but this hasn't done the trick so we think that it
> may not be a hardware issue but may be due to a problem in tempdb
> itself. I have read elsewhere that if the server is restarted, that
> the temp db will be recreated, but having done this, the mdf and ldf
> still have Craeted dates from way before the restart happened, so that
> can't have worked, so I guess my questions are...
> 1) Is there any way that I can check if the temp db is corrupt?
> 2) Should the tempdb be recreated from scratch by restarting the
> server and if not how should I do this?
> any further comments/suggestions would be very welcome
> Event Type: Error
> Event Source: MSSQLSERVER
> Event Category: (2)
> Event ID: 5242
> Description:
> An inconsistency was detected during an internal operation in database
> 'tempdb'(ID:2) on page (1:5193). Please contact technical support.
> Reference number 3.
> many thanks
> LT
>
Inconsistencies in tempdb
Hi folks
have been getting this error recently. We've swapped-out a disk which
looked to be faulty but this hasn't done the trick so we think that it
may not be a hardware issue but may be due to a problem in tempdb
itself. I have read elsewhere that if the server is restarted, that
the temp db will be recreated, but having done this, the mdf and ldf
still have Craeted dates from way before the restart happened, so that
can't have worked, so I guess my questions are...
1) Is there any way that I can check if the temp db is corrupt?
2) Should the tempdb be recreated from scratch by restarting the
server and if not how should I do this?
any further comments/suggestions would be very welcome
Event Type:Error
Event Source:MSSQLSERVER
Event Category:(2)
Event ID:5242
Description:
An inconsistency was detected during an internal operation in database
'tempdb'(ID:2) on page (1:5193). Please contact technical support.
Reference number 3.
many thanks
LT
Hi
Restart SQL Server. TempDB is rebuilt from scratch each time you restart sql
server.
"LaurenceT" <laurencetruman@.gmail.com> wrote in message
news:1178618605.338639.275140@.w5g2000hsg.googlegro ups.com...
> Hi folks
> have been getting this error recently. We've swapped-out a disk which
> looked to be faulty but this hasn't done the trick so we think that it
> may not be a hardware issue but may be due to a problem in tempdb
> itself. I have read elsewhere that if the server is restarted, that
> the temp db will be recreated, but having done this, the mdf and ldf
> still have Craeted dates from way before the restart happened, so that
> can't have worked, so I guess my questions are...
> 1) Is there any way that I can check if the temp db is corrupt?
> 2) Should the tempdb be recreated from scratch by restarting the
> server and if not how should I do this?
> any further comments/suggestions would be very welcome
> Event Type: Error
> Event Source: MSSQLSERVER
> Event Category: (2)
> Event ID: 5242
> Description:
> An inconsistency was detected during an internal operation in database
> 'tempdb'(ID:2) on page (1:5193). Please contact technical support.
> Reference number 3.
> many thanks
> LT
>
|||If you look at the tempdb files in the file system, the Date Modified
property should reflect the date/time when the instance is recycled. You can
run DBCC CHECKDB on tempdb.
Linchi
"LaurenceT" wrote:
> Hi folks
> have been getting this error recently. We've swapped-out a disk which
> looked to be faulty but this hasn't done the trick so we think that it
> may not be a hardware issue but may be due to a problem in tempdb
> itself. I have read elsewhere that if the server is restarted, that
> the temp db will be recreated, but having done this, the mdf and ldf
> still have Craeted dates from way before the restart happened, so that
> can't have worked, so I guess my questions are...
> 1) Is there any way that I can check if the temp db is corrupt?
> 2) Should the tempdb be recreated from scratch by restarting the
> server and if not how should I do this?
> any further comments/suggestions would be very welcome
> Event Type:Error
> Event Source:MSSQLSERVER
> Event Category:(2)
> Event ID:5242
> Description:
> An inconsistency was detected during an internal operation in database
> 'tempdb'(ID:2) on page (1:5193). Please contact technical support.
> Reference number 3.
> many thanks
> LT
>
have been getting this error recently. We've swapped-out a disk which
looked to be faulty but this hasn't done the trick so we think that it
may not be a hardware issue but may be due to a problem in tempdb
itself. I have read elsewhere that if the server is restarted, that
the temp db will be recreated, but having done this, the mdf and ldf
still have Craeted dates from way before the restart happened, so that
can't have worked, so I guess my questions are...
1) Is there any way that I can check if the temp db is corrupt?
2) Should the tempdb be recreated from scratch by restarting the
server and if not how should I do this?
any further comments/suggestions would be very welcome
Event Type:Error
Event Source:MSSQLSERVER
Event Category:(2)
Event ID:5242
Description:
An inconsistency was detected during an internal operation in database
'tempdb'(ID:2) on page (1:5193). Please contact technical support.
Reference number 3.
many thanks
LT
Hi
Restart SQL Server. TempDB is rebuilt from scratch each time you restart sql
server.
"LaurenceT" <laurencetruman@.gmail.com> wrote in message
news:1178618605.338639.275140@.w5g2000hsg.googlegro ups.com...
> Hi folks
> have been getting this error recently. We've swapped-out a disk which
> looked to be faulty but this hasn't done the trick so we think that it
> may not be a hardware issue but may be due to a problem in tempdb
> itself. I have read elsewhere that if the server is restarted, that
> the temp db will be recreated, but having done this, the mdf and ldf
> still have Craeted dates from way before the restart happened, so that
> can't have worked, so I guess my questions are...
> 1) Is there any way that I can check if the temp db is corrupt?
> 2) Should the tempdb be recreated from scratch by restarting the
> server and if not how should I do this?
> any further comments/suggestions would be very welcome
> Event Type: Error
> Event Source: MSSQLSERVER
> Event Category: (2)
> Event ID: 5242
> Description:
> An inconsistency was detected during an internal operation in database
> 'tempdb'(ID:2) on page (1:5193). Please contact technical support.
> Reference number 3.
> many thanks
> LT
>
|||If you look at the tempdb files in the file system, the Date Modified
property should reflect the date/time when the instance is recycled. You can
run DBCC CHECKDB on tempdb.
Linchi
"LaurenceT" wrote:
> Hi folks
> have been getting this error recently. We've swapped-out a disk which
> looked to be faulty but this hasn't done the trick so we think that it
> may not be a hardware issue but may be due to a problem in tempdb
> itself. I have read elsewhere that if the server is restarted, that
> the temp db will be recreated, but having done this, the mdf and ldf
> still have Craeted dates from way before the restart happened, so that
> can't have worked, so I guess my questions are...
> 1) Is there any way that I can check if the temp db is corrupt?
> 2) Should the tempdb be recreated from scratch by restarting the
> server and if not how should I do this?
> any further comments/suggestions would be very welcome
> Event Type:Error
> Event Source:MSSQLSERVER
> Event Category:(2)
> Event ID:5242
> Description:
> An inconsistency was detected during an internal operation in database
> 'tempdb'(ID:2) on page (1:5193). Please contact technical support.
> Reference number 3.
> many thanks
> LT
>
Inconsistencies in tempdb
Hi folks
have been getting this error recently. We've swapped-out a disk which
looked to be faulty but this hasn't done the trick so we think that it
may not be a hardware issue but may be due to a problem in tempdb
itself. I have read elsewhere that if the server is restarted, that
the temp db will be recreated, but having done this, the mdf and ldf
still have Craeted dates from way before the restart happened, so that
can't have worked, so I guess my questions are...
1) Is there any way that I can check if the temp db is corrupt?
2) Should the tempdb be recreated from scratch by restarting the
server and if not how should I do this?
any further comments/suggestions would be very welcome
Event Type: Error
Event Source: MSSQLSERVER
Event Category: (2)
Event ID: 5242
Description:
An inconsistency was detected during an internal operation in database
'tempdb'(ID:2) on page (1:5193). Please contact technical support.
Reference number 3.
many thanks
LTHi
Restart SQL Server. TempDB is rebuilt from scratch each time you restart sql
server.
"LaurenceT" <laurencetruman@.gmail.com> wrote in message
news:1178618605.338639.275140@.w5g2000hsg.googlegroups.com...
> Hi folks
> have been getting this error recently. We've swapped-out a disk which
> looked to be faulty but this hasn't done the trick so we think that it
> may not be a hardware issue but may be due to a problem in tempdb
> itself. I have read elsewhere that if the server is restarted, that
> the temp db will be recreated, but having done this, the mdf and ldf
> still have Craeted dates from way before the restart happened, so that
> can't have worked, so I guess my questions are...
> 1) Is there any way that I can check if the temp db is corrupt?
> 2) Should the tempdb be recreated from scratch by restarting the
> server and if not how should I do this?
> any further comments/suggestions would be very welcome
> Event Type: Error
> Event Source: MSSQLSERVER
> Event Category: (2)
> Event ID: 5242
> Description:
> An inconsistency was detected during an internal operation in database
> 'tempdb'(ID:2) on page (1:5193). Please contact technical support.
> Reference number 3.
> many thanks
> LT
>|||If you look at the tempdb files in the file system, the Date Modified
property should reflect the date/time when the instance is recycled. You can
run DBCC CHECKDB on tempdb.
Linchi
"LaurenceT" wrote:
> Hi folks
> have been getting this error recently. We've swapped-out a disk which
> looked to be faulty but this hasn't done the trick so we think that it
> may not be a hardware issue but may be due to a problem in tempdb
> itself. I have read elsewhere that if the server is restarted, that
> the temp db will be recreated, but having done this, the mdf and ldf
> still have Craeted dates from way before the restart happened, so that
> can't have worked, so I guess my questions are...
> 1) Is there any way that I can check if the temp db is corrupt?
> 2) Should the tempdb be recreated from scratch by restarting the
> server and if not how should I do this?
> any further comments/suggestions would be very welcome
> Event Type: Error
> Event Source: MSSQLSERVER
> Event Category: (2)
> Event ID: 5242
> Description:
> An inconsistency was detected during an internal operation in database
> 'tempdb'(ID:2) on page (1:5193). Please contact technical support.
> Reference number 3.
> many thanks
> LT
>
have been getting this error recently. We've swapped-out a disk which
looked to be faulty but this hasn't done the trick so we think that it
may not be a hardware issue but may be due to a problem in tempdb
itself. I have read elsewhere that if the server is restarted, that
the temp db will be recreated, but having done this, the mdf and ldf
still have Craeted dates from way before the restart happened, so that
can't have worked, so I guess my questions are...
1) Is there any way that I can check if the temp db is corrupt?
2) Should the tempdb be recreated from scratch by restarting the
server and if not how should I do this?
any further comments/suggestions would be very welcome
Event Type: Error
Event Source: MSSQLSERVER
Event Category: (2)
Event ID: 5242
Description:
An inconsistency was detected during an internal operation in database
'tempdb'(ID:2) on page (1:5193). Please contact technical support.
Reference number 3.
many thanks
LTHi
Restart SQL Server. TempDB is rebuilt from scratch each time you restart sql
server.
"LaurenceT" <laurencetruman@.gmail.com> wrote in message
news:1178618605.338639.275140@.w5g2000hsg.googlegroups.com...
> Hi folks
> have been getting this error recently. We've swapped-out a disk which
> looked to be faulty but this hasn't done the trick so we think that it
> may not be a hardware issue but may be due to a problem in tempdb
> itself. I have read elsewhere that if the server is restarted, that
> the temp db will be recreated, but having done this, the mdf and ldf
> still have Craeted dates from way before the restart happened, so that
> can't have worked, so I guess my questions are...
> 1) Is there any way that I can check if the temp db is corrupt?
> 2) Should the tempdb be recreated from scratch by restarting the
> server and if not how should I do this?
> any further comments/suggestions would be very welcome
> Event Type: Error
> Event Source: MSSQLSERVER
> Event Category: (2)
> Event ID: 5242
> Description:
> An inconsistency was detected during an internal operation in database
> 'tempdb'(ID:2) on page (1:5193). Please contact technical support.
> Reference number 3.
> many thanks
> LT
>|||If you look at the tempdb files in the file system, the Date Modified
property should reflect the date/time when the instance is recycled. You can
run DBCC CHECKDB on tempdb.
Linchi
"LaurenceT" wrote:
> Hi folks
> have been getting this error recently. We've swapped-out a disk which
> looked to be faulty but this hasn't done the trick so we think that it
> may not be a hardware issue but may be due to a problem in tempdb
> itself. I have read elsewhere that if the server is restarted, that
> the temp db will be recreated, but having done this, the mdf and ldf
> still have Craeted dates from way before the restart happened, so that
> can't have worked, so I guess my questions are...
> 1) Is there any way that I can check if the temp db is corrupt?
> 2) Should the tempdb be recreated from scratch by restarting the
> server and if not how should I do this?
> any further comments/suggestions would be very welcome
> Event Type: Error
> Event Source: MSSQLSERVER
> Event Category: (2)
> Event ID: 5242
> Description:
> An inconsistency was detected during an internal operation in database
> 'tempdb'(ID:2) on page (1:5193). Please contact technical support.
> Reference number 3.
> many thanks
> LT
>
Labels:
database,
disk,
error,
faulty,
folkshave,
inconsistencies,
microsoft,
mysql,
oracle,
server,
sql,
swapped-out,
tempdb,
trick,
whichlooked
Subscribe to:
Posts (Atom)