Mapping pages in database file?

Hi there,
Recently for some reason, after I was trying adjusting the indexes om my
test database, the size of the database, balloned from ~4GB to 13GB+. This
is after I rolledback all the changes I did. The database runs in full
recovery mode.
Now I got the transaction log figured out, and with the help of dbcc
loginfo, I can see what's being used in the log. But what I'd like to find
out is how large the parts of the database is; ie. a complete run down, on
what SQL Server 2000 uses storage space on.
For reference, a dbcc shrinkdatabase gives the following -
11 2 16120 128 16120 128
According to BOL, the last number (Estimated Pages) is what it guess on the
database can be shrunked to, however, that's extremely unlikely, as I know,
the DB should be around 4GB just after being created and filled with data.
How do I go about this little project?
Necessity is the plea for every infringement of human freedom. It is the
argument of tyrants; it is the creed of slaves.
-- William Pitt, 1783
Kim Noer wrote:

> How do I go about this little project?
By using DBCC SHOWCONTIG(table), investigating the Avg. Page Density (full)
and remembering that fillfactor works reverse of what previously thought. To
boil it down, I applied a fillfactor of 15%, when I should had applied 85%.
Clever.
Necessity is the plea for every infringement of human freedom. It is
the argument of tyrants; it is the creed of slaves. -- William Pitt,
1783
|||Kim
http://www.sql-server-performance.co...showcontig.asp
"Kim Noer" <kn@.nospam.dk> wrote in message
news:esALBYs8FHA.3048@.TK2MSFTNGP10.phx.gbl...
> Hi there,
> Recently for some reason, after I was trying adjusting the indexes om my
> test database, the size of the database, balloned from ~4GB to 13GB+. This
> is after I rolledback all the changes I did. The database runs in full
> recovery mode.
> Now I got the transaction log figured out, and with the help of dbcc
> loginfo, I can see what's being used in the log. But what I'd like to find
> out is how large the parts of the database is; ie. a complete run down, on
> what SQL Server 2000 uses storage space on.
> For reference, a dbcc shrinkdatabase gives the following -
> 11 2 16120 128 16120 128
> According to BOL, the last number (Estimated Pages) is what it guess on
> the database can be shrunked to, however, that's extremely unlikely, as I
> know, the DB should be around 4GB just after being created and filled with
> data.
> How do I go about this little project?
> --
> Necessity is the plea for every infringement of human freedom. It is the
> argument of tyrants; it is the creed of slaves.
> -- William Pitt, 1783
>

Mapping pages in database file?

Hi there,
Recently for some reason, after I was trying adjusting the indexes om my
test database, the size of the database, balloned from ~4GB to 13GB+. This
is after I rolledback all the changes I did. The database runs in full
recovery mode.
Now I got the transaction log figured out, and with the help of dbcc
loginfo, I can see what's being used in the log. But what I'd like to find
out is how large the parts of the database is; ie. a complete run down, on
what SQL Server 2000 uses storage space on.
For reference, a dbcc shrinkdatabase gives the following -
11 2 16120 128 16120 128
According to BOL, the last number (Estimated Pages) is what it guess on the
database can be shrunked to, however, that's extremely unlikely, as I know,
the DB should be around 4GB just after being created and filled with data.
How do I go about this little project?
Necessity is the plea for every infringement of human freedom. It is the
argument of tyrants; it is the creed of slaves.
-- William Pitt, 1783Kim Noer wrote:

> How do I go about this little project?
By using DBCC SHOWCONTIG(table), investigating the Avg. Page Density (full)
and remembering that fillfactor works reverse of what previously thought. To
boil it down, I applied a fillfactor of 15%, when I should had applied 85%.
Clever.
Necessity is the plea for every infringement of human freedom. It is
the argument of tyrants; it is the creed of slaves. -- William Pitt,
1783|||Kim
http://www.sql-server-performance.c..._showcontig.asp
"Kim Noer" <kn@.nospam.dk> wrote in message
news:esALBYs8FHA.3048@.TK2MSFTNGP10.phx.gbl...
> Hi there,
> Recently for some reason, after I was trying adjusting the indexes om my
> test database, the size of the database, balloned from ~4GB to 13GB+. This
> is after I rolledback all the changes I did. The database runs in full
> recovery mode.
> Now I got the transaction log figured out, and with the help of dbcc
> loginfo, I can see what's being used in the log. But what I'd like to find
> out is how large the parts of the database is; ie. a complete run down, on
> what SQL Server 2000 uses storage space on.
> For reference, a dbcc shrinkdatabase gives the following -
> 11 2 16120 128 16120 128
> According to BOL, the last number (Estimated Pages) is what it guess on
> the database can be shrunked to, however, that's extremely unlikely, as I
> know, the DB should be around 4GB just after being created and filled with
> data.
> How do I go about this little project?
> --
> Necessity is the plea for every infringement of human freedom. It is the
> argument of tyrants; it is the creed of slaves.
> -- William Pitt, 1783
>

Mapping pages in database file?

Hi there,
Recently for some reason, after I was trying adjusting the indexes om my
test database, the size of the database, balloned from ~4GB to 13GB+. This
is after I rolledback all the changes I did. The database runs in full
recovery mode.
Now I got the transaction log figured out, and with the help of dbcc
loginfo, I can see what's being used in the log. But what I'd like to find
out is how large the parts of the database is; ie. a complete run down, on
what SQL Server 2000 uses storage space on.
For reference, a dbcc shrinkdatabase gives the following -
11 2 16120 128 16120 128
According to BOL, the last number (Estimated Pages) is what it guess on the
database can be shrunked to, however, that's extremely unlikely, as I know,
the DB should be around 4GB just after being created and filled with data.
How do I go about this little project?
--
Necessity is the plea for every infringement of human freedom. It is the
argument of tyrants; it is the creed of slaves.
-- William Pitt, 1783Kim Noer wrote:
> How do I go about this little project?
By using DBCC SHOWCONTIG(table), investigating the Avg. Page Density (full)
and remembering that fillfactor works reverse of what previously thought. To
boil it down, I applied a fillfactor of 15%, when I should had applied 85%.
Clever.
--
Necessity is the plea for every infringement of human freedom. It is
the argument of tyrants; it is the creed of slaves. -- William Pitt,
1783|||Kim
http://www.sql-server-performance.com/dt_dbcc_showcontig.asp
"Kim Noer" <kn@.nospam.dk> wrote in message
news:esALBYs8FHA.3048@.TK2MSFTNGP10.phx.gbl...
> Hi there,
> Recently for some reason, after I was trying adjusting the indexes om my
> test database, the size of the database, balloned from ~4GB to 13GB+. This
> is after I rolledback all the changes I did. The database runs in full
> recovery mode.
> Now I got the transaction log figured out, and with the help of dbcc
> loginfo, I can see what's being used in the log. But what I'd like to find
> out is how large the parts of the database is; ie. a complete run down, on
> what SQL Server 2000 uses storage space on.
> For reference, a dbcc shrinkdatabase gives the following -
> 11 2 16120 128 16120 128
> According to BOL, the last number (Estimated Pages) is what it guess on
> the database can be shrunked to, however, that's extremely unlikely, as I
> know, the DB should be around 4GB just after being created and filled with
> data.
> How do I go about this little project?
> --
> Necessity is the plea for every infringement of human freedom. It is the
> argument of tyrants; it is the creed of slaves.
> -- William Pitt, 1783
>

Many questions about internationalization options

In RS 2000, I have a version of a set of reports (50+) that are in English and formatted for US letter size. I need to have all of these also in French in A4.
What is the best way to do this? Can I use resource files? If so, for the formatting size as well as the language? How would I do that?
If I can't use resource files, are there any other ideas than a set of separate rdl files?
Is this any different in RS 2005?

Hi Patty,

I am interested to seeing some feedback from the microsoft guys themselves on this (multilingual reports).

I have spent the past days on and of looking for some good references on this. You could even drop the good because there is nothing to find on this!

Bert

|||

Here's Microsoft's answer to internationalization:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/RSCREATE/htm/rcr_creating_building_v1_31bn.asp

|||

There is a way to use expression to be able to internationalize labels within a report. With each meta data element within your report you specify a switch statement where you translate the label into the respective language. Via a report parameter you pass in the language of choice which is then translated at runtime.

E.g.

Label Expression (right-click on label within report):

=Switch

(

Parameters!Language.Value = "E", "English Label",

Parameters!Language.Value = "D", "Deutscher Label"

...

)

Many questions about internationalization options

In RS 2000, I have a version of a set of reports (50+) that are in English and formatted for US letter size. I need to have all of these also in French in A4.
What is the best way to do this? Can I use resource files? If so, for the formatting size as well as the language? How would I do that?
If I can't use resource files, are there any other ideas than a set of separate rdl files?
Is this any different in RS 2005?

Hi Patty,

I am interested to seeing some feedback from the microsoft guys themselves on this (multilingual reports).

I have spent the past days on and of looking for some good references on this. You could even drop the good because there is nothing to find on this!

Bert

|||

Here's Microsoft's answer to internationalization:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/RSCREATE/htm/rcr_creating_building_v1_31bn.asp

|||

There is a way to use expression to be able to internationalize labels within a report. With each meta data element within your report you specify a switch statement where you translate the label into the respective language. Via a report parameter you pass in the language of choice which is then translated at runtime.

E.g.

Label Expression (right-click on label within report):

=Switch

(

Parameters!Language.Value = "E", "English Label",

Parameters!Language.Value = "D", "Deutscher Label"

...

)

Many questions about internationalization options

In RS 2000, I have a version of a set of reports (50+) that are in English and formatted for US letter size. I need to have all of these also in French in A4.
What is the best way to do this? Can I use resource files? If so, for the formatting size as well as the language? How would I do that?
If I can't use resource files, are there any other ideas than a set of separate rdl files?
Is this any different in RS 2005?

Hi Patty,

I am interested to seeing some feedback from the microsoft guys themselves on this (multilingual reports).

I have spent the past days on and of looking for some good references on this. You could even drop the good because there is nothing to find on this!

Bert

|||

Here's Microsoft's answer to internationalization:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/RSCREATE/htm/rcr_creating_building_v1_31bn.asp

|||

There is a way to use expression to be able to internationalize labels within a report. With each meta data element within your report you specify a switch statement where you translate the label into the respective language. Via a report parameter you pass in the language of choice which is then translated at runtime.

E.g.

Label Expression (right-click on label within report):

=Switch ( Parameters!Language.Value = "E", "English Label", Parameters!Language.Value = "D", "Deutscher Label" ... )sql

Manipulating Text,nText data types filed in tsql

I have to run a dynamic sql that i save in the database as a TEXT data type(due to a large size of the sql.) from a .NET app. Now i have to run this sql from the stored proc that returns the results back to .net app. I am running this dynamic sql with sp_executesql like this..

EXEC sp_executesql@.Statement,N'@.param1 varchar(3),@.param2 varchar(1)',@.param1,@.param2,
GO

As i can't declare text,ntext etc variables in T-Sql(stored proc), so i am using this method in pulling the text type field "Statement".

DECLARE@.Statement varbinary(16)
SELECT@.Statement = TEXTPTR(Statement)
FROM table1
READTEXT table1.statement@.Statement 0 16566

So far so good, the issue is how to convert @.Statment varbinary to nText to get it passed in sp_executesql.

Note:- i can't use Exec to run the dynamic sql becuase i need to pass the params from the .net app and Exec proc doesn't take param from the stored proc from where it is called.

I would appreciate if any body respond to this.

Yes, the limitation of using NTEXT as variable causes the problem. I know a workaround, but... you still need EXEC to warp the execution of sp_executesql. Read this:

sp_executesql and Long SQL Strings in SQL 2000
There is a limitation with sp_executesql on SQL 2000 and SQL 7, since you cannot use longer SQL strings than 4000 characters. (On SQL 2005, use nvarchar(MAX) to avoid this problem.) If you want to use sp_executesql despite you query string is longer, because you want to make use of parameterised query plans, there is actually a workaround. To wit, you can wrap sp_executesql in EXEC():

DECLARE @.sql1 nvarchar(4000),
@.sql2 nvarchar(4000),
@.state char(2)
SELECT @.state = 'CA'
SELECT @.sql1 = N'SELECT COUNT(*)'
SELECT @.sql2 = N'FROM dbo.authors WHERE state = @.state'
EXEC('EXEC sp_executesql N''' + @.sql1 + @.sql2 + ''',
N''@.state char(2)'',
@.state = ''' + @.state + '''')
This works, because the @.stmt parameter to sp_executesql is ntext, so by itself, it does not have any limitation in size.

You can even use output parameters by using INSERT-EXEC, as in this example:

CREATE TABLE #result (cnt int NOT NULL)
DECLARE @.sql1 nvarchar(4000),
@.sql2 nvarchar(4000),
@.state char(2),
@.mycnt int
SELECT @.state = 'CA'
SELECT @.sql1 = N'SELECT @.cnt = COUNT(*)'
SELECT @.sql2 = N'FROM dbo.authors WHERE state = @.state'
INSERT #result (cnt)
EXEC('DECLARE @.cnt int
EXEC sp_executesql N''' + @.sql1 + @.sql2 + ''',
N''@.state char(2),
@.cnt int OUTPUT'',
@.state = ''' + @.state + ''',
@.cnt = @.cnt OUTPUT
SELECT @.cnt')
SELECT @.mycnt = cnt FROM #result
You have my understanding if you think this is too messy to be worth it.

So you can break the NTEXT statement from your table into several NVARCHAR(4000) strings, then pass the strings as parameter for sp_executesql. The original wonderful artilc can be found here:

http://www.sommarskog.se/dynamic_sql.html

|||Thanks, I had to break the query into pieces to get this working.

managing Transaction Log file

Hi,
My problem is dealing with the size of Transaction log
file of our main database. It's very huge like 14GB. I
have tried the backing the log file up then DBCC
SHRINKFILE command on the log file. It's still the same
size I started out with. So far whatever I've done didn't
make difference on the size of the log file. Is there an
effective procedure to deal with this issue?
Thank you in advance for your help.
OryFirst, it's important to understand how transactions are
entered into the transaction log file. The log file is
essentially a circular queue. It wraps around. Think of
it as a donut. Within the log file there is a marker that
points to the active portion of the log. That marker
could be at the beginning of the file, in the middle, or
at the end. If the active portion of the log is at the
end of the file, SQL Server will not allow you shrink the
file. Somehow, we have to move that marker to the
beginning of the file so that we can successfully shrink
the file.
It is a very good KB article on this subject. The article
number is Q256650(How to Shrink the SQL Server 7.0
Transaction Log). You can do a search on www.microsoft.com
for this article. This article has a nice discussion on
various reasons why your attempts to shrink a log file
might not succeed. One of the reasons discussed is the
one I described above. The article provides a method for
identifying the problem and the solution to the problem in
the form of a Transact-SQL script. Identification of the
problem is accomplished by running a DBCC command called
LOGINFO. The syntax is DBCC LOGINFO (database_name). The
article describes what to look for in the output. The
script provided in the article for resolving the problem
does the following, in general terms:
. It creates a dummy table in the database for which
you are trying to shrink the log file.
. It then inserts a bunch of rows into this dummy
table. This has the effect of forcing the pointer to the
active portion of the log to wrap around to the beginning
of the log file.
. It then shrinks the log file to the size you want.
. Then it drops the dummy table.
This posting is provided "AS IS" with no warranties, and
confers no rights.
http://www.microsoft.com/info/cpyright.htm
>--Original Message--
>Hi,
>My problem is dealing with the size of Transaction log
>file of our main database. It's very huge like 14GB. I
>have tried the backing the log file up then DBCC
>SHRINKFILE command on the log file. It's still the same
>size I started out with. So far whatever I've done didn't
>make difference on the size of the log file. Is there an
>effective procedure to deal with this issue?
>Thank you in advance for your help.
> Ory
>.
>|||Refer to whichever applies to your version of SQL Server:
INF: How to Shrink the SQL Server 7.0 Transaction Log
(Q256650)
http://support.microsoft.com/?id=256650
INF: Shrinking the Transaction Log in SQL Server 2000 with
DBCC SHRINKFILE
http://support.microsoft.com/?id=272318
-Sue
On Mon, 13 Oct 2003 13:00:13 -0700, "Ory" <Ory@.nomail.org>
wrote:
>Hi,
>My problem is dealing with the size of Transaction log
>file of our main database. It's very huge like 14GB. I
>have tried the backing the log file up then DBCC
>SHRINKFILE command on the log file. It's still the same
>size I started out with. So far whatever I've done didn't
>make difference on the size of the log file. Is there an
>effective procedure to deal with this issue?
>Thank you in advance for your help.
> Ory|||Thanks Sue but I had tried the step in that article but
didn't resolve my problem. So I tried the easiest method
in the KB which is to detach from the database then delete
the log file (or rename) in the server then use
sp_attach_using_single_file to the database name and
physical path of the data file. Finally it creates a new
transaction log file. Sums it up for me.
>--Original Message--
>Refer to whichever applies to your version of SQL Server:
>INF: How to Shrink the SQL Server 7.0 Transaction Log
>(Q256650)
>http://support.microsoft.com/?id=256650
>INF: Shrinking the Transaction Log in SQL Server 2000 with
>DBCC SHRINKFILE
>http://support.microsoft.com/?id=272318
>-Sue
>On Mon, 13 Oct 2003 13:00:13 -0700, "Ory" <Ory@.nomail.org>
>wrote:
>>Hi,
>>My problem is dealing with the size of Transaction log
>>file of our main database. It's very huge like 14GB. I
>>have tried the backing the log file up then DBCC
>>SHRINKFILE command on the log file. It's still the same
>>size I started out with. So far whatever I've done
didn't
>>make difference on the size of the log file. Is there an
>>effective procedure to deal with this issue?
>>Thank you in advance for your help.
>> Ory
>.
>|||Thank you for your useful answer, I've ran the
shrink_database script in the article but it didn't shrink
the log file still. So I tried the easiesst method in the
book to detach the database then delete the log file then
db_attach_using_single_file pointing at the physical file
path and logical db name. This worked well because it
created a new minimum sized log file (or empty one you may
think as). I realize I need to have a more permanent
solution than this. This is not an ideal dba procedure.
Thank you again. Bye now:). Ory.
>--Original Message--
>First, it's important to understand how transactions are
>entered into the transaction log file. The log file is
>essentially a circular queue. It wraps around. Think of
>it as a donut. Within the log file there is a marker
that
>points to the active portion of the log. That marker
>could be at the beginning of the file, in the middle, or
>at the end. If the active portion of the log is at the
>end of the file, SQL Server will not allow you shrink the
>file. Somehow, we have to move that marker to the
>beginning of the file so that we can successfully shrink
>the file.
>It is a very good KB article on this subject. The
article
>number is Q256650(How to Shrink the SQL Server 7.0
>Transaction Log). You can do a search on
www.microsoft.com
>for this article. This article has a nice discussion on
>various reasons why your attempts to shrink a log file
>might not succeed. One of the reasons discussed is the
>one I described above. The article provides a method for
>identifying the problem and the solution to the problem
in
>the form of a Transact-SQL script. Identification of the
>problem is accomplished by running a DBCC command called
>LOGINFO. The syntax is DBCC LOGINFO (database_name).
The
>article describes what to look for in the output. The
>script provided in the article for resolving the problem
>does the following, in general terms:
>.. It creates a dummy table in the database for which
>you are trying to shrink the log file.
>.. It then inserts a bunch of rows into this dummy
>table. This has the effect of forcing the pointer to the
>active portion of the log to wrap around to the beginning
>of the log file.
>.. It then shrinks the log file to the size you want.
>.. Then it drops the dummy table.
>This posting is provided "AS IS" with no warranties, and
>confers no rights.
>http://www.microsoft.com/info/cpyright.htm
>>--Original Message--
>>Hi,
>>My problem is dealing with the size of Transaction log
>>file of our main database. It's very huge like 14GB. I
>>have tried the backing the log file up then DBCC
>>SHRINKFILE command on the log file. It's still the same
>>size I started out with. So far whatever I've done
didn't
>>make difference on the size of the log file. Is there an
>>effective procedure to deal with this issue?
>>Thank you in advance for your help.
>> Ory
>>.
>.
>|||I don't remember those articles or the KB recommending this
approach for shrinking a log file. As dbcc shrinkfile is a
bit different on SQL 7 and SQL 2000, it's hard to say what
the problem could be as you didn't post the version of SQL
Server. On SQL 7, it's a deferred operation so that can play
a part in what you experienced.
-Sue
On Mon, 13 Oct 2003 16:54:00 -0700, "Ory" <Ory@.nomail.org>
wrote:
>Thanks Sue but I had tried the step in that article but
>didn't resolve my problem. So I tried the easiest method
>in the KB which is to detach from the database then delete
>the log file (or rename) in the server then use
>sp_attach_using_single_file to the database name and
>physical path of the data file. Finally it creates a new
>transaction log file. Sums it up for me.
>
>>--Original Message--
>>Refer to whichever applies to your version of SQL Server:
>>INF: How to Shrink the SQL Server 7.0 Transaction Log
>>(Q256650)
>>http://support.microsoft.com/?id=256650
>>INF: Shrinking the Transaction Log in SQL Server 2000 with
>>DBCC SHRINKFILE
>>http://support.microsoft.com/?id=272318
>>-Sue
>>On Mon, 13 Oct 2003 13:00:13 -0700, "Ory" <Ory@.nomail.org>
>>wrote:
>>Hi,
>>My problem is dealing with the size of Transaction log
>>file of our main database. It's very huge like 14GB. I
>>have tried the backing the log file up then DBCC
>>SHRINKFILE command on the log file. It's still the same
>>size I started out with. So far whatever I've done
>didn't
>>make difference on the size of the log file. Is there an
>>effective procedure to deal with this issue?
>>Thank you in advance for your help.
>> Ory
>>.|||Consider yourself lucky you didn't get a corrupt/suspect database! :-)
(I do understand that you did a database backup first.)
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as ugroup=microsoft.public.sqlserver
"Ory" <Ory@.nomail.org> wrote in message news:0a7c01c391e5$45c6f170$a301280a@.phx.gbl...
> Thanks Sue but I had tried the step in that article but
> didn't resolve my problem. So I tried the easiest method
> in the KB which is to detach from the database then delete
> the log file (or rename) in the server then use
> sp_attach_using_single_file to the database name and
> physical path of the data file. Finally it creates a new
> transaction log file. Sums it up for me.
>
> >--Original Message--
> >Refer to whichever applies to your version of SQL Server:
> >
> >INF: How to Shrink the SQL Server 7.0 Transaction Log
> >(Q256650)
> >http://support.microsoft.com/?id=256650
> >
> >INF: Shrinking the Transaction Log in SQL Server 2000 with
> >DBCC SHRINKFILE
> >http://support.microsoft.com/?id=272318
> >
> >-Sue
> >
> >On Mon, 13 Oct 2003 13:00:13 -0700, "Ory" <Ory@.nomail.org>
> >wrote:
> >
> >>Hi,
> >>
> >>My problem is dealing with the size of Transaction log
> >>file of our main database. It's very huge like 14GB. I
> >>have tried the backing the log file up then DBCC
> >>SHRINKFILE command on the log file. It's still the same
> >>size I started out with. So far whatever I've done
> didn't
> >>make difference on the size of the log file. Is there an
> >>effective procedure to deal with this issue?
> >>
> >>Thank you in advance for your help.
> >>
> >> Ory
> >
> >.
> >|||Hi Sue,
I'm using SQL Server 2000. You're right that it wasn't in
KB the article it was
in //evolvedcode.net/content/code_sqllogshrink/ . The
format that I used for shrinking before that didn't work
was DBCC SHRINKFILE (xxx.log, target_size_in_MB) in Query
Analyzer. I get a result set on Actual and estimated size
of the file which doen't help much. Anyways, thank you for
your reply. I post a message as a developer/dba_to_be
every two to three months or so.
Bye.
>--Original Message--
>I don't remember those articles or the KB recommending
this
>approach for shrinking a log file. As dbcc shrinkfile is a
>bit different on SQL 7 and SQL 2000, it's hard to say what
>the problem could be as you didn't post the version of SQL
>Server. On SQL 7, it's a deferred operation so that can
play
>a part in what you experienced.
>-Sue
>On Mon, 13 Oct 2003 16:54:00 -0700, "Ory" <Ory@.nomail.org>
>wrote:
>>Thanks Sue but I had tried the step in that article but
>>didn't resolve my problem. So I tried the easiest method
>>in the KB which is to detach from the database then
delete
>>the log file (or rename) in the server then use
>>sp_attach_using_single_file to the database name and
>>physical path of the data file. Finally it creates a new
>>transaction log file. Sums it up for me.
>>
>>--Original Message--
>>Refer to whichever applies to your version of SQL
Server:
>>INF: How to Shrink the SQL Server 7.0 Transaction Log
>>(Q256650)
>>http://support.microsoft.com/?id=256650
>>INF: Shrinking the Transaction Log in SQL Server 2000
with
>>DBCC SHRINKFILE
>>http://support.microsoft.com/?id=272318
>>-Sue
>>On Mon, 13 Oct 2003 13:00:13 -0700, "Ory"
<Ory@.nomail.org>
>>wrote:
>>Hi,
>>My problem is dealing with the size of Transaction log
>>file of our main database. It's very huge like 14GB. I
>>have tried the backing the log file up then DBCC
>>SHRINKFILE command on the log file. It's still the
same
>>size I started out with. So far whatever I've done
>>didn't
>>make difference on the size of the log file. Is there
an
>>effective procedure to deal with this issue?
>>Thank you in advance for your help.
>> Ory
>>.
>.
>|||There are plenty of posts on sites about deleting logs,
rebuilding logs, etc. It's just a totally bad practice - it
risks the ability to maintain transactional consistency in
your database. Unfortunately, someone follows the advice,
doesn't see any harmful affects and then posts the solution
again. But there are plenty of people who have basically
ruined their databases by doing this. It may not even be
noticeable immediately. You could be in a situation where
you have a problem, can solve it using methods that don't
harm your database but you loose the ability to do this by
running some of these scripts. The transaction log is a
critically important piece of your database system and
that's something people seem to lose sight of sometimes.
-Sue
On Tue, 14 Oct 2003 11:58:52 -0700, "Ory"
<ory@.nomail.nospam.org> wrote:
>Hi Sue,
>I'm using SQL Server 2000. You're right that it wasn't in
>KB the article it was
>in //evolvedcode.net/content/code_sqllogshrink/ . The
>format that I used for shrinking before that didn't work
>was DBCC SHRINKFILE (xxx.log, target_size_in_MB) in Query
>Analyzer. I get a result set on Actual and estimated size
>of the file which doen't help much. Anyways, thank you for
>your reply. I post a message as a developer/dba_to_be
>every two to three months or so.
>Bye.
>
>>--Original Message--
>>I don't remember those articles or the KB recommending
>this
>>approach for shrinking a log file. As dbcc shrinkfile is a
>>bit different on SQL 7 and SQL 2000, it's hard to say what
>>the problem could be as you didn't post the version of SQL
>>Server. On SQL 7, it's a deferred operation so that can
>play
>>a part in what you experienced.
>>-Sue
>>On Mon, 13 Oct 2003 16:54:00 -0700, "Ory" <Ory@.nomail.org>
>>wrote:
>>Thanks Sue but I had tried the step in that article but
>>didn't resolve my problem. So I tried the easiest method
>>in the KB which is to detach from the database then
>delete
>>the log file (or rename) in the server then use
>>sp_attach_using_single_file to the database name and
>>physical path of the data file. Finally it creates a new
>>transaction log file. Sums it up for me.
>>
>>--Original Message--
>>Refer to whichever applies to your version of SQL
>Server:
>>INF: How to Shrink the SQL Server 7.0 Transaction Log
>>(Q256650)
>>http://support.microsoft.com/?id=256650
>>INF: Shrinking the Transaction Log in SQL Server 2000
>with
>>DBCC SHRINKFILE
>>http://support.microsoft.com/?id=272318
>>-Sue
>>On Mon, 13 Oct 2003 13:00:13 -0700, "Ory"
><Ory@.nomail.org>
>>wrote:
>>Hi,
>>My problem is dealing with the size of Transaction log
>>file of our main database. It's very huge like 14GB. I
>>have tried the backing the log file up then DBCC
>>SHRINKFILE command on the log file. It's still the
>same
>>size I started out with. So far whatever I've done
>>didn't
>>make difference on the size of the log file. Is there
>an
>>effective procedure to deal with this issue?
>>Thank you in advance for your help.
>> Ory
>>.
>>
>>.|||(MRS OR MS) Hoegemeier,
You're chewing me up?. Believe me I tried scripts and
commands from Microsoft sites mostly. Which I didn't get
anywhere. I don't have comfort of long time for these
problems I have to go on with running our application
scripts against the database. However, I acknowledge that
this is just a temporary solution. More I become
knowledgable more I will implement more permanent and
sustaining solutions. I'm below your experience and know-
how in SQL Server but in Real World shortcuts and relative
quick fixes keeps running the IT departments. And also
keep the problem solver image. That's all.
*\Ory
>--Original Message--
>There are plenty of posts on sites about deleting logs,
>rebuilding logs, etc. It's just a totally bad practice -
it
>risks the ability to maintain transactional consistency in
>your database. Unfortunately, someone follows the advice,
>doesn't see any harmful affects and then posts the
solution
>again. But there are plenty of people who have basically
>ruined their databases by doing this. It may not even be
>noticeable immediately. You could be in a situation where
>you have a problem, can solve it using methods that don't
>harm your database but you loose the ability to do this by
>running some of these scripts. The transaction log is a
>critically important piece of your database system and
>that's something people seem to lose sight of sometimes.
>-Sue
>On Tue, 14 Oct 2003 11:58:52 -0700, "Ory"
><ory@.nomail.nospam.org> wrote:
>>Hi Sue,
>>I'm using SQL Server 2000. You're right that it wasn't
in
>>KB the article it was
>>in //evolvedcode.net/content/code_sqllogshrink/ . The
>>format that I used for shrinking before that didn't work
>>was DBCC SHRINKFILE (xxx.log, target_size_in_MB) in
Query
>>Analyzer. I get a result set on Actual and estimated
size
>>of the file which doen't help much. Anyways, thank you
for
>>your reply. I post a message as a developer/dba_to_be
>>every two to three months or so.
>>Bye.
>>
>>--Original Message--
>>I don't remember those articles or the KB recommending
>>this
>>approach for shrinking a log file. As dbcc shrinkfile
is a
>>bit different on SQL 7 and SQL 2000, it's hard to say
what
>>the problem could be as you didn't post the version of
SQL
>>Server. On SQL 7, it's a deferred operation so that can
>>play
>>a part in what you experienced.
>>-Sue
>>On Mon, 13 Oct 2003 16:54:00 -0700, "Ory"
<Ory@.nomail.org>
>>wrote:
>>Thanks Sue but I had tried the step in that article
but
>>didn't resolve my problem. So I tried the easiest
method
>>in the KB which is to detach from the database then
>>delete
>>the log file (or rename) in the server then use
>>sp_attach_using_single_file to the database name and
>>physical path of the data file. Finally it creates a
new
>>transaction log file. Sums it up for me.
>>
>>--Original Message--
>>Refer to whichever applies to your version of SQL
>>Server:
>>INF: How to Shrink the SQL Server 7.0 Transaction Log
>>(Q256650)
>>http://support.microsoft.com/?id=256650
>>INF: Shrinking the Transaction Log in SQL Server 2000
>>with
>>DBCC SHRINKFILE
>>http://support.microsoft.com/?id=272318
>>-Sue
>>On Mon, 13 Oct 2003 13:00:13 -0700, "Ory"
>><Ory@.nomail.org>
>>wrote:
>>Hi,
>>My problem is dealing with the size of Transaction
log
>>file of our main database. It's very huge like 14GB.
I
>>have tried the backing the log file up then DBCC
>>SHRINKFILE command on the log file. It's still the
>>same
>>size I started out with. So far whatever I've done
>>didn't
>>make difference on the size of the log file. Is
there
>>an
>>effective procedure to deal with this issue?
>>Thank you in advance for your help.
>> Ory
>>.
>>
>>.
>.
>|||No, no...not chewing you up at all. Just the opposite - I
was just trying to warn you about using some of those
scripts. Of all the scripts I've seen, I think some of the
log scripts (as well some of the ones that mess with system
tables) are just the totally wrong solutions to the problem.
All too often I have seen where these "shortcuts" really
don't add up to any time, money, business saved and often
cause more problems than the original problem they were
meant to solve. I've seen places use the shortcuts and then
have problems with the database for weeks, downtime, data
loss etc. I really do understand what you are saying and
I've certainly been in the position where I have been told
to do things that are totally wrong. But they don't keep
things running sometimes as much as they keep us in crisis
mode, working later for days, etc. And a lot of times it's
just people who don't know any better who are going to
insist anyway. But it's important for you to know what's
right and what's wrong. If you warn them and they insist
(and they sign your paycheck) then often there isn't much
you can do. But if you know and you warn them, at least you
did what's right. The worse part is when we think some of
the bad practices are really the way it's suppose to be
done. But if you know better and take the time to understand
you can be in a better position to help clean up the mess.
That's why I was warning you about going down that road...
-Sue
On Tue, 14 Oct 2003 14:48:06 -0700, "Ory"
<ory@.nospam.please> wrote:
>(MRS OR MS) Hoegemeier,
>You're chewing me up?. Believe me I tried scripts and
>commands from Microsoft sites mostly. Which I didn't get
>anywhere. I don't have comfort of long time for these
>problems I have to go on with running our application
>scripts against the database. However, I acknowledge that
>this is just a temporary solution. More I become
>knowledgable more I will implement more permanent and
>sustaining solutions. I'm below your experience and know-
>how in SQL Server but in Real World shortcuts and relative
>quick fixes keeps running the IT departments. And also
>keep the problem solver image. That's all.
> *\Ory
>>--Original Message--
>>There are plenty of posts on sites about deleting logs,
>>rebuilding logs, etc. It's just a totally bad practice -
>it
>>risks the ability to maintain transactional consistency in
>>your database. Unfortunately, someone follows the advice,
>>doesn't see any harmful affects and then posts the
>solution
>>again. But there are plenty of people who have basically
>>ruined their databases by doing this. It may not even be
>>noticeable immediately. You could be in a situation where
>>you have a problem, can solve it using methods that don't
>>harm your database but you loose the ability to do this by
>>running some of these scripts. The transaction log is a
>>critically important piece of your database system and
>>that's something people seem to lose sight of sometimes.
>>-Sue
>>On Tue, 14 Oct 2003 11:58:52 -0700, "Ory"
>><ory@.nomail.nospam.org> wrote:
>>Hi Sue,
>>I'm using SQL Server 2000. You're right that it wasn't
>in
>>KB the article it was
>>in //evolvedcode.net/content/code_sqllogshrink/ . The
>>format that I used for shrinking before that didn't work
>>was DBCC SHRINKFILE (xxx.log, target_size_in_MB) in
>Query
>>Analyzer. I get a result set on Actual and estimated
>size
>>of the file which doen't help much. Anyways, thank you
>for
>>your reply. I post a message as a developer/dba_to_be
>>every two to three months or so.
>>Bye.
>>
>>--Original Message--
>>I don't remember those articles or the KB recommending
>>this
>>approach for shrinking a log file. As dbcc shrinkfile
>is a
>>bit different on SQL 7 and SQL 2000, it's hard to say
>what
>>the problem could be as you didn't post the version of
>SQL
>>Server. On SQL 7, it's a deferred operation so that can
>>play
>>a part in what you experienced.
>>-Sue
>>On Mon, 13 Oct 2003 16:54:00 -0700, "Ory"
><Ory@.nomail.org>
>>wrote:
>>Thanks Sue but I had tried the step in that article
>but
>>didn't resolve my problem. So I tried the easiest
>method
>>in the KB which is to detach from the database then
>>delete
>>the log file (or rename) in the server then use
>>sp_attach_using_single_file to the database name and
>>physical path of the data file. Finally it creates a
>new
>>transaction log file. Sums it up for me.
>>
>>--Original Message--
>>Refer to whichever applies to your version of SQL
>>Server:
>>INF: How to Shrink the SQL Server 7.0 Transaction Log
>>(Q256650)
>>http://support.microsoft.com/?id=256650
>>INF: Shrinking the Transaction Log in SQL Server 2000
>>with
>>DBCC SHRINKFILE
>>http://support.microsoft.com/?id=272318
>>-Sue
>>On Mon, 13 Oct 2003 13:00:13 -0700, "Ory"
>><Ory@.nomail.org>
>>wrote:
>>>Hi,
>>>
>>>My problem is dealing with the size of Transaction
>log
>>>file of our main database. It's very huge like 14GB.
>I
>>>have tried the backing the log file up then DBCC
>>>SHRINKFILE command on the log file. It's still the
>>same
>>>size I started out with. So far whatever I've done
>>didn't
>>>make difference on the size of the log file. Is
>there
>>an
>>>effective procedure to deal with this issue?
>>>
>>>Thank you in advance for your help.
>>>
>>> Ory
>>.
>>
>>.
>>
>>.|||And with a last name like that, Sue is very much okay by me.
It's worse to pronounce than it is to type so you were lucky
you only had to type it!
-Sue
On Tue, 14 Oct 2003 14:48:06 -0700, "Ory"
<ory@.nospam.please> wrote:
>MRS OR MS) Hoegemeier,|||I see :). It was good having a frank exchange with a Lady
of significant professional experience. Your warnings and
opinions are appreciated. Thank you.
PS. Would you tell me where you work (company)? Just
curious.
>--Original Message--
>No, no...not chewing you up at all. Just the opposite - I
>was just trying to warn you about using some of those
>scripts. Of all the scripts I've seen, I think some of the
>log scripts (as well some of the ones that mess with
system
>tables) are just the totally wrong solutions to the
problem.
>All too often I have seen where these "shortcuts" really
>don't add up to any time, money, business saved and often
>cause more problems than the original problem they were
>meant to solve. I've seen places use the shortcuts and
then
>have problems with the database for weeks, downtime, data
>loss etc. I really do understand what you are saying and
>I've certainly been in the position where I have been told
>to do things that are totally wrong. But they don't keep
>things running sometimes as much as they keep us in crisis
>mode, working later for days, etc. And a lot of times it's
>just people who don't know any better who are going to
>insist anyway. But it's important for you to know what's
>right and what's wrong. If you warn them and they insist
>(and they sign your paycheck) then often there isn't much
>you can do. But if you know and you warn them, at least
you
>did what's right. The worse part is when we think some of
>the bad practices are really the way it's suppose to be
>done. But if you know better and take the time to
understand
>you can be in a better position to help clean up the mess.
>That's why I was warning you about going down that road...
>-Sue
>On Tue, 14 Oct 2003 14:48:06 -0700, "Ory"
><ory@.nospam.please> wrote:
>>(MRS OR MS) Hoegemeier,
>>You're chewing me up?. Believe me I tried scripts and
>>commands from Microsoft sites mostly. Which I didn't get
>>anywhere. I don't have comfort of long time for these
>>problems I have to go on with running our application
>>scripts against the database. However, I acknowledge
that
>>this is just a temporary solution. More I become
>>knowledgable more I will implement more permanent and
>>sustaining solutions. I'm below your experience and know-
>>how in SQL Server but in Real World shortcuts and
relative
>>quick fixes keeps running the IT departments. And also
>>keep the problem solver image. That's all.
>> *\Ory
>>--Original Message--
>>There are plenty of posts on sites about deleting logs,
>>rebuilding logs, etc. It's just a totally bad practice -
>>it
>>risks the ability to maintain transactional consistency
in
>>your database. Unfortunately, someone follows the
advice,
>>doesn't see any harmful affects and then posts the
>>solution
>>again. But there are plenty of people who have
basically
>>ruined their databases by doing this. It may not even be
>>noticeable immediately. You could be in a situation
where
>>you have a problem, can solve it using methods that
don't
>>harm your database but you loose the ability to do this
by
>>running some of these scripts. The transaction log is a
>>critically important piece of your database system and
>>that's something people seem to lose sight of sometimes.
>>-Sue
>>On Tue, 14 Oct 2003 11:58:52 -0700, "Ory"
>><ory@.nomail.nospam.org> wrote:
>>Hi Sue,
>>I'm using SQL Server 2000. You're right that it wasn't
>>in
>>KB the article it was
>>in //evolvedcode.net/content/code_sqllogshrink/ . The
>>format that I used for shrinking before that didn't
work
>>was DBCC SHRINKFILE (xxx.log, target_size_in_MB) in
>>Query
>>Analyzer. I get a result set on Actual and estimated
>>size
>>of the file which doen't help much. Anyways, thank you
>>for
>>your reply. I post a message as a developer/dba_to_be
>>every two to three months or so.
>>Bye.
>>
>>--Original Message--
>>I don't remember those articles or the KB
recommending
>>this
>>approach for shrinking a log file. As dbcc shrinkfile
>>is a
>>bit different on SQL 7 and SQL 2000, it's hard to say
>>what
>>the problem could be as you didn't post the version
of
>>SQL
>>Server. On SQL 7, it's a deferred operation so that
can
>>play
>>a part in what you experienced.
>>-Sue
>>On Mon, 13 Oct 2003 16:54:00 -0700, "Ory"
>><Ory@.nomail.org>
>>wrote:
>>Thanks Sue but I had tried the step in that article
>>but
>>didn't resolve my problem. So I tried the easiest
>>method
>>in the KB which is to detach from the database then
>>delete
>>the log file (or rename) in the server then use
>>sp_attach_using_single_file to the database name and
>>physical path of the data file. Finally it creates a
>>new
>>transaction log file. Sums it up for me.
>>
>>>--Original Message--
>>>Refer to whichever applies to your version of SQL
>>Server:
>>>
>>>INF: How to Shrink the SQL Server 7.0 Transaction
Log
>>>(Q256650)
>>>http://support.microsoft.com/?id=256650
>>>
>>>INF: Shrinking the Transaction Log in SQL Server
2000
>>with
>>>DBCC SHRINKFILE
>>>http://support.microsoft.com/?id=272318
>>>
>>>-Sue
>>>
>>>On Mon, 13 Oct 2003 13:00:13 -0700, "Ory"
>><Ory@.nomail.org>
>>>wrote:
>>>
>>>Hi,
>>>
>>>My problem is dealing with the size of Transaction
>>log
>>>file of our main database. It's very huge like
14GB.
>>I
>>>have tried the backing the log file up then DBCC
>>>SHRINKFILE command on the log file. It's still the
>>same
>>>size I started out with. So far whatever I've done
>>didn't
>>>make difference on the size of the log file. Is
>>there
>>an
>>>effective procedure to deal with this issue?
>>>
>>>Thank you in advance for your help.
>>>
>>> Ory
>>>
>>>.
>>>
>>.
>>
>>.
>.
>|||If I told you after posting these things, I'd probably never
get a job again! But I've worked at a lot of different
places actually. I think many places experience the same
problems we've discussed.
-Sue
On Tue, 14 Oct 2003 16:45:25 -0700, "Ory"
<anonymous@.discussions.microsoft.com> wrote:
>I see :). It was good having a frank exchange with a Lady
>of significant professional experience. Your warnings and
>opinions are appreciated. Thank you.
>PS. Would you tell me where you work (company)? Just
>curious.
>
>>--Original Message--
>>No, no...not chewing you up at all. Just the opposite - I
>>was just trying to warn you about using some of those
>>scripts. Of all the scripts I've seen, I think some of the
>>log scripts (as well some of the ones that mess with
>system
>>tables) are just the totally wrong solutions to the
>problem.
>>All too often I have seen where these "shortcuts" really
>>don't add up to any time, money, business saved and often
>>cause more problems than the original problem they were
>>meant to solve. I've seen places use the shortcuts and
>then
>>have problems with the database for weeks, downtime, data
>>loss etc. I really do understand what you are saying and
>>I've certainly been in the position where I have been told
>>to do things that are totally wrong. But they don't keep
>>things running sometimes as much as they keep us in crisis
>>mode, working later for days, etc. And a lot of times it's
>>just people who don't know any better who are going to
>>insist anyway. But it's important for you to know what's
>>right and what's wrong. If you warn them and they insist
>>(and they sign your paycheck) then often there isn't much
>>you can do. But if you know and you warn them, at least
>you
>>did what's right. The worse part is when we think some of
>>the bad practices are really the way it's suppose to be
>>done. But if you know better and take the time to
>understand
>>you can be in a better position to help clean up the mess.
>>That's why I was warning you about going down that road...
>>-Sue
>>On Tue, 14 Oct 2003 14:48:06 -0700, "Ory"
>><ory@.nospam.please> wrote:
>>(MRS OR MS) Hoegemeier,
>>You're chewing me up?. Believe me I tried scripts and
>>commands from Microsoft sites mostly. Which I didn't get
>>anywhere. I don't have comfort of long time for these
>>problems I have to go on with running our application
>>scripts against the database. However, I acknowledge
>that
>>this is just a temporary solution. More I become
>>knowledgable more I will implement more permanent and
>>sustaining solutions. I'm below your experience and know-
>>how in SQL Server but in Real World shortcuts and
>relative
>>quick fixes keeps running the IT departments. And also
>>keep the problem solver image. That's all.
>> *\Ory
>>--Original Message--
>>There are plenty of posts on sites about deleting logs,
>>rebuilding logs, etc. It's just a totally bad practice -
>>it
>>risks the ability to maintain transactional consistency
>in
>>your database. Unfortunately, someone follows the
>advice,
>>doesn't see any harmful affects and then posts the
>>solution
>>again. But there are plenty of people who have
>basically
>>ruined their databases by doing this. It may not even be
>>noticeable immediately. You could be in a situation
>where
>>you have a problem, can solve it using methods that
>don't
>>harm your database but you loose the ability to do this
>by
>>running some of these scripts. The transaction log is a
>>critically important piece of your database system and
>>that's something people seem to lose sight of sometimes.
>>-Sue
>>On Tue, 14 Oct 2003 11:58:52 -0700, "Ory"
>><ory@.nomail.nospam.org> wrote:
>>Hi Sue,
>>I'm using SQL Server 2000. You're right that it wasn't
>>in
>>KB the article it was
>>in //evolvedcode.net/content/code_sqllogshrink/ . The
>>format that I used for shrinking before that didn't
>work
>>was DBCC SHRINKFILE (xxx.log, target_size_in_MB) in
>>Query
>>Analyzer. I get a result set on Actual and estimated
>>size
>>of the file which doen't help much. Anyways, thank you
>>for
>>your reply. I post a message as a developer/dba_to_be
>>every two to three months or so.
>>Bye.
>>
>>--Original Message--
>>I don't remember those articles or the KB
>recommending
>>this
>>approach for shrinking a log file. As dbcc shrinkfile
>>is a
>>bit different on SQL 7 and SQL 2000, it's hard to say
>>what
>>the problem could be as you didn't post the version
>of
>>SQL
>>Server. On SQL 7, it's a deferred operation so that
>can
>>play
>>a part in what you experienced.
>>-Sue
>>On Mon, 13 Oct 2003 16:54:00 -0700, "Ory"
>><Ory@.nomail.org>
>>wrote:
>>>Thanks Sue but I had tried the step in that article
>>but
>>>didn't resolve my problem. So I tried the easiest
>>method
>>>in the KB which is to detach from the database then
>>delete
>>>the log file (or rename) in the server then use
>>>sp_attach_using_single_file to the database name and
>>>physical path of the data file. Finally it creates a
>>new
>>>transaction log file. Sums it up for me.
>>>
>>>
>>>--Original Message--
>>>Refer to whichever applies to your version of SQL
>>Server:
>>>
>>>INF: How to Shrink the SQL Server 7.0 Transaction
>Log
>>>(Q256650)
>>>http://support.microsoft.com/?id=256650
>>>
>>>INF: Shrinking the Transaction Log in SQL Server
>2000
>>with
>>>DBCC SHRINKFILE
>>>http://support.microsoft.com/?id=272318
>>>
>>>-Sue
>>>
>>>On Mon, 13 Oct 2003 13:00:13 -0700, "Ory"
>><Ory@.nomail.org>
>>>wrote:
>>>
>>>Hi,
>>>
>>>My problem is dealing with the size of Transaction
>>log
>>>file of our main database. It's very huge like
>14GB.
>>I
>>>have tried the backing the log file up then DBCC
>>>SHRINKFILE command on the log file. It's still the
>>same
>>>size I started out with. So far whatever I've done
>>>didn't
>>>make difference on the size of the log file. Is
>>there
>>an
>>>effective procedure to deal with this issue?
>>>
>>>Thank you in advance for your help.
>>>
>>> Ory
>>>
>>>.
>>>
>>.
>>
>>.
>>
>>.|||Dear Sue, or other friend:
I've read all your talks above, and want to say that I am just in that
trouble. My database log file's size is over 1.2G, and I detached it,
and delete the log file, but when I want to attach the mdf file, it
shows 'Error 1813, could not open new database, CREATE DATABASE is
abort, Device activation error, the physical file name xxx may be
incorrect.' The server version is 2000, database size is just 300M.
How can I do?
Thanks in advanced.
Wing1993
Posted via http://dbforums.com|||This is the very reason why folks shouldn't recommend deleting log files. I suggest you restore the
database from the backup I take it you did before this operation.
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as ugroup=microsoft.public.sqlserver
"wing1993" <member44167@.dbforums.com> wrote in message news:3482440.1066189506@.dbforums.com...
> Dear Sue, or other friend:
>
> I've read all your talks above, and want to say that I am just in that
> trouble. My database log file's size is over 1.2G, and I detached it,
> and delete the log file, but when I want to attach the mdf file, it
> shows 'Error 1813, could not open new database, CREATE DATABASE is
> abort, Device activation error, the physical file name xxx may be
> incorrect.' The server version is 2000, database size is just 300M.
>
> How can I do?
> Thanks in advanced.
>
> Wing1993
>
> --
> Posted via http://dbforums.com|||All,
If I still want to use this updated mdf file to restore the database,
how can i do, in fact, the last backup is over 3 days older than the bad
file. I don't want to loss the data.
But I will bear in mind that next time I shall backup database and log
file to truncate the long transaction file.
Wing1993
Posted via http://dbforums.com

Managing TB size of data

hi,
I jsut want ot know what are the challenges we should face in managing few
100 TB size large DB. What is the best way to do the backup and in the live
24 * 7 environment how to do the Full backup if needed?
SOS.
thanks
jag
Are you sure you mean terabytes, as in 1000 gigabytes? I haven't heard of
any SQL Server database over 8 TB -- so I doubt anyone knows what the
challenges are with something as large as you're describing. What industry
is this for? And what kind of disk system do you have in mind to support
it?
Adam Machanic
SQL Server MVP
http://www.datamanipulation.net
"Ramuk" <Ramuk@.discussions.microsoft.com> wrote in message
news:07FE34A4-DB6C-4BD0-9912-5F6A1F2FE0E0@.microsoft.com...
> hi,
> I jsut want ot know what are the challenges we should face in managing few
> 100 TB size large DB. What is the best way to do the backup and in the
live
> 24 * 7 environment how to do the Full backup if needed?
> SOS.
> thanks
> jag
|||SQL Server Scalability FAQ
http://www.microsoft.com/sql/techinf...abilityfaq.asp
AMB
"Ramuk" wrote:

> hi,
> I jsut want ot know what are the challenges we should face in managing few
> 100 TB size large DB. What is the best way to do the backup and in the live
> 24 * 7 environment how to do the Full backup if needed?
> SOS.
> thanks
> jag
|||If you are really talking about 100TB then there is no way you can get a
detailed enough answer on a newsgroup for such a general question. A DB
that size must be properly planed and if you are asking these type questions
you simply do not have the necessary background to accomplish a task like
this on your own. I recommend you hire a "qualified" consultant to guide
you through this process.
Andrew J. Kelly SQL MVP
"Ramuk" <Ramuk@.discussions.microsoft.com> wrote in message
news:07FE34A4-DB6C-4BD0-9912-5F6A1F2FE0E0@.microsoft.com...
> hi,
> I jsut want ot know what are the challenges we should face in managing few
> 100 TB size large DB. What is the best way to do the backup and in the
> live
> 24 * 7 environment how to do the Full backup if needed?
> SOS.
> thanks
> jag
|||"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:ePN9TUWMFHA.436@.TK2MSFTNGP09.phx.gbl...
> this on your own. I recommend you hire a "qualified" consultant to guide
> you through this process.
Such as..? ;)
Adam Machanic
SQL Server MVP
http://www.datamanipulation.net
|||I stand corrected -- 17 terabytes. Still not even close to 100.
Adam Machanic
SQL Server MVP
http://www.datamanipulation.net
"Alejandro Mesa" <AlejandroMesa@.discussions.microsoft.com> wrote in message
news:C85802E9-B841-49C5-A4A7-725B85145684@.microsoft.com...
> SQL Server Scalability FAQ
>
http://www.microsoft.com/sql/techinf...abilityfaq.asp[vbcol=seagreen]
>
> AMB
> "Ramuk" wrote:
few[vbcol=seagreen]
live[vbcol=seagreen]
|||Adam,
You were right, 17 tb for the group of dbs.
AMB
"Adam Machanic" wrote:

> I stand corrected -- 17 terabytes. Still not even close to 100.
> --
> Adam Machanic
> SQL Server MVP
> http://www.datamanipulation.net
> --
>
> "Alejandro Mesa" <AlejandroMesa@.discussions.microsoft.com> wrote in message
> news:C85802E9-B841-49C5-A4A7-725B85145684@.microsoft.com...
> http://www.microsoft.com/sql/techinf...abilityfaq.asp
> few
> live
>
>
|||I could name a few but I won't<g>.
Andrew J. Kelly SQL MVP
"Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in message
news:%23MY2ydWMFHA.1096@.tk2msftngp13.phx.gbl...
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:ePN9TUWMFHA.436@.TK2MSFTNGP09.phx.gbl...
> Such as..? ;)
>
> --
> Adam Machanic
> SQL Server MVP
> http://www.datamanipulation.net
> --
>

Managing TB size of data

hi,
I jsut want ot know what are the challenges we should face in managing few
100 TB size large DB. What is the best way to do the backup and in the live
24 * 7 environment how to do the Full backup if needed?
SOS.
thanks
jagAre you sure you mean terabytes, as in 1000 gigabytes? I haven't heard of
any SQL Server database over 8 TB -- so I doubt anyone knows what the
challenges are with something as large as you're describing. What industry
is this for? And what kind of disk system do you have in mind to support
it?
Adam Machanic
SQL Server MVP
http://www.datamanipulation.net
--
"Ramuk" <Ramuk@.discussions.microsoft.com> wrote in message
news:07FE34A4-DB6C-4BD0-9912-5F6A1F2FE0E0@.microsoft.com...
> hi,
> I jsut want ot know what are the challenges we should face in managing few
> 100 TB size large DB. What is the best way to do the backup and in the
live
> 24 * 7 environment how to do the Full backup if needed?
> SOS.
> thanks
> jag|||SQL Server Scalability FAQ
http://www.microsoft.com/sql/techinfo/administration/2000/scalabilityfaq.asp
AMB
"Ramuk" wrote:
> hi,
> I jsut want ot know what are the challenges we should face in managing few
> 100 TB size large DB. What is the best way to do the backup and in the live
> 24 * 7 environment how to do the Full backup if needed?
> SOS.
> thanks
> jag|||If you are really talking about 100TB then there is no way you can get a
detailed enough answer on a newsgroup for such a general question. A DB
that size must be properly planed and if you are asking these type questions
you simply do not have the necessary background to accomplish a task like
this on your own. I recommend you hire a "qualified" consultant to guide
you through this process.
--
Andrew J. Kelly SQL MVP
"Ramuk" <Ramuk@.discussions.microsoft.com> wrote in message
news:07FE34A4-DB6C-4BD0-9912-5F6A1F2FE0E0@.microsoft.com...
> hi,
> I jsut want ot know what are the challenges we should face in managing few
> 100 TB size large DB. What is the best way to do the backup and in the
> live
> 24 * 7 environment how to do the Full backup if needed?
> SOS.
> thanks
> jag|||"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:ePN9TUWMFHA.436@.TK2MSFTNGP09.phx.gbl...
> this on your own. I recommend you hire a "qualified" consultant to guide
> you through this process.
Such as..? ;)
Adam Machanic
SQL Server MVP
http://www.datamanipulation.net
--|||I stand corrected -- 17 terabytes. Still not even close to 100.
--
Adam Machanic
SQL Server MVP
http://www.datamanipulation.net
--
"Alejandro Mesa" <AlejandroMesa@.discussions.microsoft.com> wrote in message
news:C85802E9-B841-49C5-A4A7-725B85145684@.microsoft.com...
> SQL Server Scalability FAQ
>
http://www.microsoft.com/sql/techinfo/administration/2000/scalabilityfaq.asp
>
> AMB
> "Ramuk" wrote:
> > hi,
> >
> > I jsut want ot know what are the challenges we should face in managing
few
> > 100 TB size large DB. What is the best way to do the backup and in the
live
> > 24 * 7 environment how to do the Full backup if needed?
> >
> > SOS.
> >
> > thanks
> > jag|||Adam,
You were right, 17 tb for the group of dbs.
AMB
"Adam Machanic" wrote:
> I stand corrected -- 17 terabytes. Still not even close to 100.
> --
> Adam Machanic
> SQL Server MVP
> http://www.datamanipulation.net
> --
>
> "Alejandro Mesa" <AlejandroMesa@.discussions.microsoft.com> wrote in message
> news:C85802E9-B841-49C5-A4A7-725B85145684@.microsoft.com...
> > SQL Server Scalability FAQ
> >
> http://www.microsoft.com/sql/techinfo/administration/2000/scalabilityfaq.asp
> >
> >
> > AMB
> >
> > "Ramuk" wrote:
> >
> > > hi,
> > >
> > > I jsut want ot know what are the challenges we should face in managing
> few
> > > 100 TB size large DB. What is the best way to do the backup and in the
> live
> > > 24 * 7 environment how to do the Full backup if needed?
> > >
> > > SOS.
> > >
> > > thanks
> > > jag
>
>|||I could name a few but I won't<g>.
--
Andrew J. Kelly SQL MVP
"Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in message
news:%23MY2ydWMFHA.1096@.tk2msftngp13.phx.gbl...
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:ePN9TUWMFHA.436@.TK2MSFTNGP09.phx.gbl...
>> this on your own. I recommend you hire a "qualified" consultant to guide
>> you through this process.
> Such as..? ;)
>
> --
> Adam Machanic
> SQL Server MVP
> http://www.datamanipulation.net
> --
>

Managing TB size of data

hi,
I jsut want ot know what are the challenges we should face in managing few
100 TB size large DB. What is the best way to do the backup and in the live
24 * 7 environment how to do the Full backup if needed?
SOS.
thanks
jagAre you sure you mean terabytes, as in 1000 gigabytes? I haven't heard of
any SQL Server database over 8 TB -- so I doubt anyone knows what the
challenges are with something as large as you're describing. What industry
is this for? And what kind of disk system do you have in mind to support
it?
Adam Machanic
SQL Server MVP
http://www.datamanipulation.net
--
"Ramuk" <Ramuk@.discussions.microsoft.com> wrote in message
news:07FE34A4-DB6C-4BD0-9912-5F6A1F2FE0E0@.microsoft.com...
> hi,
> I jsut want ot know what are the challenges we should face in managing few
> 100 TB size large DB. What is the best way to do the backup and in the
live
> 24 * 7 environment how to do the Full backup if needed?
> SOS.
> thanks
> jag|||SQL Server Scalability FAQ
http://www.microsoft.com/sql/techin...labilityfaq.asp
AMB
"Ramuk" wrote:

> hi,
> I jsut want ot know what are the challenges we should face in managing few
> 100 TB size large DB. What is the best way to do the backup and in the liv
e
> 24 * 7 environment how to do the Full backup if needed?
> SOS.
> thanks
> jag|||If you are really talking about 100TB then there is no way you can get a
detailed enough answer on a newsgroup for such a general question. A DB
that size must be properly planed and if you are asking these type questions
you simply do not have the necessary background to accomplish a task like
this on your own. I recommend you hire a "qualified" consultant to guide
you through this process.
Andrew J. Kelly SQL MVP
"Ramuk" <Ramuk@.discussions.microsoft.com> wrote in message
news:07FE34A4-DB6C-4BD0-9912-5F6A1F2FE0E0@.microsoft.com...
> hi,
> I jsut want ot know what are the challenges we should face in managing few
> 100 TB size large DB. What is the best way to do the backup and in the
> live
> 24 * 7 environment how to do the Full backup if needed?
> SOS.
> thanks
> jag|||"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:ePN9TUWMFHA.436@.TK2MSFTNGP09.phx.gbl...
> this on your own. I recommend you hire a "qualified" consultant to guide
> you through this process.
Such as..? ;)
Adam Machanic
SQL Server MVP
http://www.datamanipulation.net
--|||I stand corrected -- 17 terabytes. Still not even close to 100.
Adam Machanic
SQL Server MVP
http://www.datamanipulation.net
--
"Alejandro Mesa" <AlejandroMesa@.discussions.microsoft.com> wrote in message
news:C85802E9-B841-49C5-A4A7-725B85145684@.microsoft.com...
> SQL Server Scalability FAQ
>
http://www.microsoft.com/sql/techin...labilityfaq.asp[vbcol=seagreen]
>
> AMB
> "Ramuk" wrote:
>
few[vbcol=seagreen]
live[vbcol=seagreen]|||Adam,
You were right, 17 tb for the group of dbs.
AMB
"Adam Machanic" wrote:

> I stand corrected -- 17 terabytes. Still not even close to 100.
> --
> Adam Machanic
> SQL Server MVP
> http://www.datamanipulation.net
> --
>
> "Alejandro Mesa" <AlejandroMesa@.discussions.microsoft.com> wrote in messag
e
> news:C85802E9-B841-49C5-A4A7-725B85145684@.microsoft.com...
> [url]http://www.microsoft.com/sql/techinfo/administration/2000/scalabilityfaq.asp[/ur
l]
> few
> live
>
>|||I could name a few but I won't<g>.
Andrew J. Kelly SQL MVP
"Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in message
news:%23MY2ydWMFHA.1096@.tk2msftngp13.phx.gbl...
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:ePN9TUWMFHA.436@.TK2MSFTNGP09.phx.gbl...
> Such as..? ;)
>
> --
> Adam Machanic
> SQL Server MVP
> http://www.datamanipulation.net
> --
>

Managing Table Size

I agree with Bobs solution, but here is some SQL that will
find values greater than 4 months rather than 120 days
(although I am being very picky)
delete
FROM order
WHERE DATEDIFF(month, orderdate, getdate()) > 4
J

>--Original Message--
>I have a table in my DB that I would like to restrict to
recent records
>only. Recent being the last 4 months. Can someone help me
determine the
>easiest and most maintenance free way to accomplish this?
>Thank You
>
>.
>
"Julie" <anonymous@.discussions.microsoft.com> wrote in message
news:1a22a01c41d4d$1f22acf0$a101280a@.phx.gbl...
> I agree with Bobs solution, but here is some SQL that will
> find values greater than 4 months rather than 120 days
> (although I am being very picky)
> delete
> FROM order
> WHERE DATEDIFF(month, orderdate, getdate()) > 4
LOL I was going to post that, but had a sudden doubt as to whether DATEDIFF
was TSQL or VB, couldn't check, so I chickened out.
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.655 / Virus Database: 420 - Release Date: 08/04/2004

Managing Table Size

I have a table in my DB that I would like to restrict to recent records
only. Recent being the last 4 months. Can someone help me determine the
easiest and most maintenance free way to accomplish this?
Thank You
"Shawn" <skfabc@.yahoo.com> wrote in message
news:ezb1obNHEHA.3556@.TK2MSFTNGP10.phx.gbl...
> I have a table in my DB that I would like to restrict to recent records
> only. Recent being the last 4 months. Can someone help me determine the
> easiest and most maintenance free way to accomplish this?
> Thank You
Presumably you have a column with creation date included in the table
schema. In which case create a SQL Server Agent TSQL job that contains the
SQL:
DELETE *
FROM tablename
WHERE dateCol < GETDATE() - 120.
Schedule it to run regularly (e.g. every night). You might even want to add
it to the backup job.
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.647 / Virus Database: 414 - Release Date: 29/03/2004

Managing Table Size

I agree with Bobs solution, but here is some SQL that will
find values greater than 4 months rather than 120 days
(although I am being very picky)
delete
FROM order
WHERE DATEDIFF(month, orderdate, getdate()) > 4
J

>--Original Message--
>I have a table in my DB that I would like to restrict to
recent records
>only. Recent being the last 4 months. Can someone help me
determine the
>easiest and most maintenance free way to accomplish this?
>Thank You
>
>.
>"Julie" <anonymous@.discussions.microsoft.com> wrote in message
news:1a22a01c41d4d$1f22acf0$a101280a@.phx
.gbl...
> I agree with Bobs solution, but here is some SQL that will
> find values greater than 4 months rather than 120 days
> (although I am being very picky)
> delete
> FROM order
> WHERE DATEDIFF(month, orderdate, getdate()) > 4
LOL I was going to post that, but had a sudden doubt as to whether DATEDIFF
was TSQL or VB, couldn't check, so I chickened out.
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.655 / Virus Database: 420 - Release Date: 08/04/2004

Managing Table Size

I have a table in my DB that I would like to restrict to recent records
only. Recent being the last 4 months. Can someone help me determine the
easiest and most maintenance free way to accomplish this?
Thank You"Shawn" <skfabc@.yahoo.com> wrote in message
news:ezb1obNHEHA.3556@.TK2MSFTNGP10.phx.gbl...
> I have a table in my DB that I would like to restrict to recent records
> only. Recent being the last 4 months. Can someone help me determine the
> easiest and most maintenance free way to accomplish this?
> Thank You
Presumably you have a column with creation date included in the table
schema. In which case create a SQL Server Agent TSQL job that contains the
SQL:
DELETE *
FROM tablename
WHERE dateCol < GETDATE() - 120.
Schedule it to run regularly (e.g. every night). You might even want to add
it to the backup job.
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.647 / Virus Database: 414 - Release Date: 29/03/2004

Managing Table Size

I have a table in my DB that I would like to restrict to recent records
only. Recent being the last 4 months. Can someone help me determine the
easiest and most maintenance free way to accomplish this?
Thank You"Shawn" <skfabc@.yahoo.com> wrote in message
news:ezb1obNHEHA.3556@.TK2MSFTNGP10.phx.gbl...
> I have a table in my DB that I would like to restrict to recent records
> only. Recent being the last 4 months. Can someone help me determine the
> easiest and most maintenance free way to accomplish this?
> Thank You
Presumably you have a column with creation date included in the table
schema. In which case create a SQL Server Agent TSQL job that contains the
SQL:
DELETE *
FROM tablename
WHERE dateCol < GETDATE() - 120.
Schedule it to run regularly (e.g. every night). You might even want to add
it to the backup job.
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.647 / Virus Database: 414 - Release Date: 29/03/2004|||I agree with Bobs solution, but here is some SQL that will
find values greater than 4 months rather than 120 days
(although I am being very picky)
delete
FROM order
WHERE DATEDIFF(month, orderdate, getdate()) > 4
J
>--Original Message--
>I have a table in my DB that I would like to restrict to
recent records
>only. Recent being the last 4 months. Can someone help me
determine the
>easiest and most maintenance free way to accomplish this?
>Thank You
>
>.
>|||"Julie" <anonymous@.discussions.microsoft.com> wrote in message
news:1a22a01c41d4d$1f22acf0$a101280a@.phx.gbl...
> I agree with Bobs solution, but here is some SQL that will
> find values greater than 4 months rather than 120 days
> (although I am being very picky)
> delete
> FROM order
> WHERE DATEDIFF(month, orderdate, getdate()) > 4
LOL I was going to post that, but had a sudden doubt as to whether DATEDIFF
was TSQL or VB, couldn't check, so I chickened out.
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.655 / Virus Database: 420 - Release Date: 08/04/2004

Managing Disk Space

Is there a tool or trick/tip for managing disk space on SQL Server
(database/tran log size vs. free disk space)?
Thanks.
No tricks really. You have to chose the best recovery model for your
database, and an appropriate backup plan, to keep the transaction log files
in check. Also, defragmenting your tables will help avoid disk space
wastage. Please read up on recovery model, BACKUP/RESTORE, DBCC DBREINDEX,
DBCC INDEXDEFRAG.
Vyas, MVP (SQL Server)
http://vyaskn.tripod.com/
"SQL" <nospam@.adfadfadf.com> wrote in message
news:eWiPESrYEHA.3512@.TK2MSFTNGP12.phx.gbl...
> Is there a tool or trick/tip for managing disk space on SQL Server
> (database/tran log size vs. free disk space)?
> Thanks.
>
|||Hi,
For Managing the growth you can use the Performance monitor. You create the
Alerts in performance monitor
which can raise an network message / write in application log based on the
threshold limit set for each counters.
You can also create your own alerts using SQL Agent from SQL Enterprise
manager.
Monitor disk space , see the belew link.
http://www.databasejournal.com/featu...le.php/1475741
Apart from this you can use the 3rd party tool.
http://www.bmcpatrol.com
Thanks
Hari
MCDBA
"SQL" <nospam@.adfadfadf.com> wrote in message
news:eWiPESrYEHA.3512@.TK2MSFTNGP12.phx.gbl...
> Is there a tool or trick/tip for managing disk space on SQL Server
> (database/tran log size vs. free disk space)?
> Thanks.
>

Managing Disk Space

Is there a tool or trick/tip for managing disk space on SQL Server
(database/tran log size vs. free disk space)?
Thanks.No tricks really. You have to chose the best recovery model for your
database, and an appropriate backup plan, to keep the transaction log files
in check. Also, defragmenting your tables will help avoid disk space
wastage. Please read up on recovery model, BACKUP/RESTORE, DBCC DBREINDEX,
DBCC INDEXDEFRAG.
--
Vyas, MVP (SQL Server)
http://vyaskn.tripod.com/
"SQL" <nospam@.adfadfadf.com> wrote in message
news:eWiPESrYEHA.3512@.TK2MSFTNGP12.phx.gbl...
> Is there a tool or trick/tip for managing disk space on SQL Server
> (database/tran log size vs. free disk space)?
> Thanks.
>|||Hi,
For Managing the growth you can use the Performance monitor. You create the
Alerts in performance monitor
which can raise an network message / write in application log based on the
threshold limit set for each counters.
You can also create your own alerts using SQL Agent from SQL Enterprise
manager.
Monitor disk space , see the belew link.
http://www.databasejournal.com/feat...cle.php/1475741
Apart from this you can use the 3rd party tool.
http://www.bmcpatrol.com
Thanks
Hari
MCDBA
"SQL" <nospam@.adfadfadf.com> wrote in message
news:eWiPESrYEHA.3512@.TK2MSFTNGP12.phx.gbl...
> Is there a tool or trick/tip for managing disk space on SQL Server
> (database/tran log size vs. free disk space)?
> Thanks.
>

Managing Disk Space

Is there a tool or trick/tip for managing disk space on SQL Server
(database/tran log size vs. free disk space)?
Thanks.No tricks really. You have to chose the best recovery model for your
database, and an appropriate backup plan, to keep the transaction log files
in check. Also, defragmenting your tables will help avoid disk space
wastage. Please read up on recovery model, BACKUP/RESTORE, DBCC DBREINDEX,
DBCC INDEXDEFRAG.
--
Vyas, MVP (SQL Server)
http://vyaskn.tripod.com/
"SQL" <nospam@.adfadfadf.com> wrote in message
news:eWiPESrYEHA.3512@.TK2MSFTNGP12.phx.gbl...
> Is there a tool or trick/tip for managing disk space on SQL Server
> (database/tran log size vs. free disk space)?
> Thanks.
>|||Hi,
For Managing the growth you can use the Performance monitor. You create the
Alerts in performance monitor
which can raise an network message / write in application log based on the
threshold limit set for each counters.
You can also create your own alerts using SQL Agent from SQL Enterprise
manager.
Monitor disk space , see the belew link.
http://www.databasejournal.com/features/mssql/article.php/1475741
Apart from this you can use the 3rd party tool.
http://www.bmcpatrol.com
Thanks
Hari
MCDBA
"SQL" <nospam@.adfadfadf.com> wrote in message
news:eWiPESrYEHA.3512@.TK2MSFTNGP12.phx.gbl...
> Is there a tool or trick/tip for managing disk space on SQL Server
> (database/tran log size vs. free disk space)?
> Thanks.
>

Managing a large row size

I have an app that requires 125 columns whcih blows away the 8060 byte
limit.
(It's a decision support app, and I've alreay broken out four subordinate
tables to fullfill a one-to-many need...but the 125 DO belong together.)
I need to split it into a minimum of three tables.
Is there sample code that would show how to keep these three tables in sync
when doing INS, UPDT, and DEL, including transactions?
Kyle!Try create a view based on the three tables and instead of trigger when
insert and update
"Kyle Jedrusiak" <kyle.jedrusiak@.princetoninformation.com> wrote in message
news:OuH9DOLQDHA.3768@.tk2msftngp13.phx.gbl...
> I have an app that requires 125 columns whcih blows away the 8060 byte
> limit.
> (It's a decision support app, and I've alreay broken out four subordinate
> tables to fullfill a one-to-many need...but the 125 DO belong together.)
> I need to split it into a minimum of three tables.
> Is there sample code that would show how to keep these three tables in
sync
> when doing INS, UPDT, and DEL, including transactions?
> Kyle!
>