Wednesday, March 21, 2012
Name Lookup of Enterprise Manager
I have noticed a strange behaviour of Enterprise Manager (or every
program to connect to SQL Server; as in Visual Studio, Query Analyser
and ODBC-Connection Manager), which I cannot get sorted out.
I try to connect to an MSDE-Instance on a clients' Server. The Server
has, for our Maintenance, a dial-up connection with dynamic IP and
runs a service to keep the IP up-to-date, so we can access it by
servername.dyndns.org.
I can ping the server and I can connect to it in pcAnywhere (using the
dyndns.org lookup).
If I try to connect to the MSDE as servername.dyndns.org\Instance, I
get an error: Server not found: Connection.Open(Connect()).
Trying to make an ODBC-Connection gives some numbers on the error:
SQLState: 01000
Server Error: 11004
followed by
SQLState: 08001
Server Error: 6
I can connect to MSDE by using the IP a ping gave me,
1.2.3.4\Instance.
Username and Password must be correct, because a connection with
IP\Instance works fine for the IP looked up a second ago. So my
Question is: Why does Name-Lookup work for ping, work for pcAnywhere,
but not for sql server?
I wonder if someone can give a hint on that on... looking Google
Groups and Knowledge base for the last 2 hours wasn't helpful...
Thanks!Sorry, but since nobody answered, and I really need a little help
here, I *bumped* this one up again.
> Hello!
> I have noticed a strange behaviour of Enterprise Manager (or every
> program to connect to SQL Server; as in Visual Studio, Query Analyser
> and ODBC-Connection Manager), which I cannot get sorted out.
> I try to connect to an MSDE-Instance on a clients' Server. The Server
> has, for our Maintenance, a dial-up connection with dynamic IP and
> runs a service to keep the IP up-to-date, so we can access it by
> servername.dyndns.org.
> I can ping the server and I can connect to it in pcAnywhere (using the
> dyndns.org lookup).
> If I try to connect to the MSDE as servername.dyndns.org\Instance, I
> get an error: Server not found: Connection.Open(Connect()).
> Trying to make an ODBC-Connection gives some numbers on the error:
> SQLState: 01000
> Server Error: 11004
> followed by
> SQLState: 08001
> Server Error: 6
> I can connect to MSDE by using the IP a ping gave me,
> 1.2.3.4\Instance.
> Username and Password must be correct, because a connection with
> IP\Instance works fine for the IP looked up a second ago. So my
> Question is: Why does Name-Lookup work for ping, work for pcAnywhere,
> but not for sql server?
> I wonder if someone can give a hint on that on... looking Google
> Groups and Knowledge base for the last 2 hours wasn't helpful...
> Thanks!
Monday, March 19, 2012
Mysteriously changing datetime data
happened to one of my database tables. The table has three columns that are
of type datetime. They normally contain values such as 08/12/2004 16:03:35.
One of the three columns, however, now shows either 08/12/2004 only or
08/12/2004 00:00:00. The other two columns are still "normal".
No update queries have been run against this table.
Does anybody know why the dates would have changed like that?DATETIME columns don't contain any inherent format and they always include
both date and time. It looks like your client application, whatever that may
be, is formatting the date differently to what you expect. Check the
regional settings on your PC or any other options in your app that may
affect date formatting.
--
David Portas
SQL Server MVP
--|||Where are you looking, in Enterprise Manager? Try using SELECT cols FROM
table in Query Analyzer.
--
http://www.aspfaq.com/
(Reverse address to reply.)
"SackerMan" <SackerMan@.discussions.microsoft.com> wrote in message
news:6529C05A-2374-421C-93C4-6A498163F365@.microsoft.com...
> I know this may seem like a weird thing, but today something very strange
> happened to one of my database tables. The table has three columns that
are
> of type datetime. They normally contain values such as 08/12/2004
16:03:35.
> One of the three columns, however, now shows either 08/12/2004 only or
> 08/12/2004 00:00:00. The other two columns are still "normal".
> No update queries have been run against this table.
> Does anybody know why the dates would have changed like that?|||Hi SackerMan
The values actually stored in a datetime column don't 'look' anything like
what you have shown us. They are stored in an internal unambigous format
that you never see.
How a datetime value 'looks' depends on the tool and the command you use to
display it.
So, how are you actually seeing these values?
--
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"SackerMan" <SackerMan@.discussions.microsoft.com> wrote in message
news:6529C05A-2374-421C-93C4-6A498163F365@.microsoft.com...
> I know this may seem like a weird thing, but today something very strange
> happened to one of my database tables. The table has three columns that
are
> of type datetime. They normally contain values such as 08/12/2004
16:03:35.
> One of the three columns, however, now shows either 08/12/2004 only or
> 08/12/2004 00:00:00. The other two columns are still "normal".
> No update queries have been run against this table.
> Does anybody know why the dates would have changed like that?
Mysterious query problem?
strange problem here... query #1 displays 357 records correctly and all
is well. However, when placed within query #2 as a subquery, it updates
every single record in the lta table, what's going on here? any
thoughts?
1.) select *
from LTA INNER JOIN new_list
ON lta.voy = new_list.voy AND
lta.poe = new_list.poe
2.)
update lta
set lta.LL_RCVD = 'N'
where exists (select *
from LTA INNER JOIN new_list
ON lta.voy = new_list.voy AND
lta.poe = new_list.poe)Gah! What am I doing wrong? The query below is a modification of query
#2 above, yet updates 32 records (all of which are NOT located in table
new_list)??!
Please help!
update lta
set LL_RCVD = 'j'
from lta a, new_list b
where a.voy = b.voy AND
a.poe = b.poe|||On 10 Jan 2005 07:25:14 -0800, Roy wrote:
>Hey all,
>strange problem here... query #1 displays 357 records correctly and all
>is well. However, when placed within query #2 as a subquery, it updates
>every single record in the lta table, what's going on here? any
>thoughts?
>
>1.) select *
>from LTA INNER JOIN new_list
>ON lta.voy = new_list.voy AND
>lta.poe = new_list.poe
>
>2.)
>update lta
>set lta.LL_RCVD = 'N'
>where exists (select *
>from LTA INNER JOIN new_list
>ON lta.voy = new_list.voy AND
>lta.poe = new_list.poe)
Hi Roy,
The subquery on #2 doesn't reference the outer query. Hence, it returns
the same 357 rows for each row in LTA (from the outer query), so the
EXISTS predicate is always true.
You probably need
UPDATE lta
SET LL_RCVD = 'N'
WHERE EXISTS (SELECT *
FROM new_list
WHERE new_list.voy = lta.voy
AND new_list.poe = lta.poe)
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||On 10 Jan 2005 07:42:14 -0800, Roy wrote:
>Gah! What am I doing wrong? The query below is a modification of query
>#2 above, yet updates 32 records (all of which are NOT located in table
>new_list)??!
>Please help!
>update lta
>set LL_RCVD = 'j'
>from lta a, new_list b
>where a.voy = b.voy AND
>a.poe = b.poe
Hi Roy,
This should affect the same rows as the query I suggested in my reply to
your other message (but this one sets LL_RVCD to 'j'; the other one sets
it to 'N').
An important difference occurs if one row in lta matches more than one row
in new_list (and, since the select returns more rows than are affected by
the update statement, this appears to be the case with your data). The
above query will repeatedly change the values for any lta row that matches
more than one new_list row (with the results being undefined, though in
you case, where the new value is a constant, the results will be as
expected); my version will simply update the rows exactly once.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||I love you forever, thanks Hugo!
Monday, March 12, 2012
mysterious changes of data
I have a simple invoice, inventory, billing program that is doing something strange but I can't track it down.
I can't figure out what triggers it but occasionally when I add an invoice to a customer all the other invoices are added to the last customer updated.
My update statement on the invoice table is
UPDATE Invoices
SET Date = @.Date, InvoiceTotal = @.InvoiceTotal, SubTotal = @.SubTotal, Tax = @.Tax, CustomerID = @.CustomerID
WHERE (CustomerID = @.CustomerID)
The only triggers on the table are to update the qty in Inventory and another trigger that fires when a payment is entered.
Any Ideas?
In your update statement, there is no need to update your customer
UPDATE Invoices
SET Date = @.Date, InvoiceTotal = @.InvoiceTotal, SubTotal = @.SubTotal, Tax = @.Tax, CustomerID = @.CustomerID
WHERE (CustomerID = @.CustomerID).
Could you post your trigger codes ?. Then only, we will find out the actual issue ?
Thanks.
Naras.
|||Trigger on InvoiceDetails to update qty in inventory
ALTER TRIGGER trInvoiceDetails_IU_UpdateQty
ON InvoiceDetails
FOR INSERT, UPDATE
AS
IF @.@.ROWCOUNT = 0
RETURN
IF UPDATE (Qty)
UPDATE WInventory
SET WInventory.InStock = ( WInventory.InStock - i.Qty )
FROM inserted i
JOIN WInventory
ON i.ItemID = WInventory.ItemID and i.ItemNumber=WInventory.ItemNumber
Trigger on Invoices to close invoice when payment entered
ALTER TRIGGER trPaidInvoices
ON dbo.Invoices
FOR UPDATE
AS
IF UPDATE (InvoiceTotal)
insert into ClosedInvoices (InvoiceID,CustomerID,[Date])
SELECT InvoiceID, CustomerID, [Date]
FROM Invoices
WHERE (InvoiceTotal = 0.00)
Delete from invoices where invoiceTotal=0.00
select * from Invoices
|||
Hi,
shouldn′t that be:
ALTER TRIGGER trPaidInvoices
ON dbo.Invoices
FOR UPDATE
AS
BEGIN
IF UPDATE (InvoiceTotal)
insert into ClosedInvoices (InvoiceID,CustomerID,[Date])
SELECT InvoiceID, CustomerID, [Date]
FROM Invoices
WHERE (InvoiceTotal = 0.00)
NNER JOIN INSERTED I
ON I.InvoiceId = In.InvoiceId
Delete from invoices where invoiceTotal=0.00
FROM Invoices In
INNER JOIN INSERTED I
ON I.InvoiceId = In.InvoiceId
END
Jens K. Suessmeyer.
http://www.sqlserver2005.de
|||maybe but I don't see how that could be causing my original problem?|||The problem is not related to the posted trigger code. Perhpas there are some other triggers on the related tables which interfer with the invoices table.Jens K. Suessmeyer.
http://www.sqlserver2005.de
|||
If you want to track this thing down quickly, perhaps SQL Profiler might help you to find out what statements are being run from where on what data to see exactly what is happening here and when.
Hope that helps,
John (MSFT)
Wednesday, March 7, 2012
My web application is not picking up all the data in the table
I'm a system engineer and not a developer, so i'm a little bit lost here.
I have a cluster running W2000 SQL Server, this SQL server has some linked
servers (oracle) with one of our costumers, everyday several SQL jobs update
our SQL tables with info from that oracle servers. But for some reason,
recently the users started complaining some some of the info is not available
on the application, after some investigation, i could confirm that everything
is ok with the data on the costumers servers and that our tables keep being
updated with the info, but the application can't seem to catch any of these
info (vendor information in this case). It seems to me that at some point the
table has some corrupt data or something that is preventing the application
from getting all the data.
Do you guys thing this is something with the SQL table or within the
application?
All the help and suggestions are welcome. (my msn is below)
Best regards
Francisco Batista
Portugal
msn: f_batista69@.hotmail.com
No where near enough information to help you. I suggest you find someone
that knows the application to help you.
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
You can't help someone get up a hill without getting a little closer to the
top yourself.
- H. Norman Schwarzkopf
"francisco - Portugal" <f_batista69@.hotmail.com> wrote in message
news:955AF918-D80E-4B0C-B626-09733B1BE251@.microsoft.com...
> I'm facing a strange problems regarding an application my company is
> hosting.
> I'm a system engineer and not a developer, so i'm a little bit lost here.
> I have a cluster running W2000 SQL Server, this SQL server has some linked
> servers (oracle) with one of our costumers, everyday several SQL jobs
> update
> our SQL tables with info from that oracle servers. But for some reason,
> recently the users started complaining some some of the info is not
> available
> on the application, after some investigation, i could confirm that
> everything
> is ok with the data on the costumers servers and that our tables keep
> being
> updated with the info, but the application can't seem to catch any of
> these
> info (vendor information in this case). It seems to me that at some point
> the
> table has some corrupt data or something that is preventing the
> application
> from getting all the data.
> Do you guys thing this is something with the SQL table or within the
> application?
> All the help and suggestions are welcome. (my msn is below)
> Best regards
> --
> Francisco Batista
> Portugal
> msn: f_batista69@.hotmail.com
|||Thanks anyway for your time, i will try to reach a developer that was
involved in the built of the application.
Merry Christmas
Francisco Batista
Portugal
f_batista69@.hotmail.com
"Arnie Rowland" wrote:
> No where near enough information to help you. I suggest you find someone
> that knows the application to help you.
> --
> Arnie Rowland, Ph.D.
> Westwood Consulting, Inc
> Most good judgment comes from experience.
> Most experience comes from bad judgment.
> - Anonymous
> You can't help someone get up a hill without getting a little closer to the
> top yourself.
> - H. Norman Schwarzkopf
>
> "francisco - Portugal" <f_batista69@.hotmail.com> wrote in message
> news:955AF918-D80E-4B0C-B626-09733B1BE251@.microsoft.com...
>
>
|||Its best to work with your developer and troubleshoot the lines of code that
calls for the data and then run the same query in your Query Analyser
window.
Alternatively you could run profiler to help troubleshoot the same. If you
think the table has all the data and the app does not return it, then it
could be capped by number of rows or possibly some rowcount option being
set,etc.
"francisco - Portugal" <f_batista69@.hotmail.com> wrote in message
news:EE601359-B05A-4995-9253-92290C82A3A7@.microsoft.com...[vbcol=seagreen]
> Thanks anyway for your time, i will try to reach a developer that was
> involved in the built of the application.
> Merry Christmas
> --
> Francisco Batista
> Portugal
> f_batista69@.hotmail.com
>
> "Arnie Rowland" wrote:
My Transaction Log size very strange
I use SQL Server 2000
I use Full recuperation mode.
My DB size is 458 MB (344 in use, 114 available)
My log size is 18 MB
I do Full backup every hour starting at 8:00 am until 21:00
I do transaction backup every 10 minutes.
The problem is that the size of the transaction log backup is strange, as
follows:
Time Size(KB) filename
...
05:52 78.336 myDB_tlog_200507140552.TRN
06:02 78.336 myDB_tlog_200507140602.TRN
06:12 78.336 myDB_tlog_200507140612.TRN
06:22 78.336 myDB_tlog_200507140622.TRN
06:32 11.776 myDB_tlog_200507140632.TRN
06:42 11.776 myDB_tlog_200507140642.TRN
06:52 78.336 myDB_tlog_200507140652.TRN
07:03 359.117.312 myDB_tlog_200507140703.TRN Note
07:12 133.072.384 myDB_tlog_200507140712.TRN Note
07:22 291.328 myDB_tlog_200507140722.TRN
07:32 291.328 myDB_tlog_200507140732.TRN
07:42 291.328 myDB_tlog_200507140742.TRN
07:52 356.864 myDB_tlog_200507140752.TRN
08:02 356.864 myDB_tlog_200507140802.TRN
08:12 356.864 myDB_tlog_200507140812.TRN
08:22 357.888 myDB_tlog_200507140822.TRN
08:32 422.400 myDB_tlog_200507140832.TRN
08:42 10.663.424 myDB_tlog_200507140842.TRN Note
08:52 437.760 myDB_tlog_200507140852.TRN
09:02 437.760 myDB_tlog_200507140902.TRN
09:12 699.904 myDB_tlog_200507140912.TRN
09:22 503.296 myDB_tlog_200507140922.TRN
09:32 568.832 myDB_tlog_200507140932.TRN
09:42 568.832 myDB_tlog_200507140942.TRN
09:52 569.856 myDB_tlog_200507140952.TRN
10:02 372.224 myDB_tlog_200507141002.TRN
10:12 10.442.240 myDB_tlog_200507141012.TRN Note
10:22 413.184 myDB_tlog_200507141022.TRN
10:32 545.280 myDB_tlog_200507141032.TRN
10:42 479.744 myDB_tlog_200507141042.TRN
10:52 414.208 myDB_tlog_200507141052.TRN
11:02 479.744 myDB_tlog_200507141102.TRN
11:12 413.184 myDB_tlog_200507141112.TRN
11:22 414.208 myDB_tlog_200507141122.TRN
11:32 546.304 myDB_tlog_200507141132.TRN
11:42 1.093.120 myDB_tlog_200507141142.TRN
11:52 303.616 myDB_tlog_200507141152.TRN
12:02 436.736 myDB_tlog_200507141202.TRN
12:12 369.152 myDB_tlog_200507141212.TRN
12:22 239.104 myDB_tlog_200507141222.TRN
12:32 172.544 myDB_tlog_200507141232.TRN
12:42 107.008 myDB_tlog_200507141242.TRN
12:52 172.544 myDB_tlog_200507141252.TRN
13:02 239.104 myDB_tlog_200507141302.TRN
13:12 9.269.760 myDB_tlog_200507141312.TRN Note
13:22 158.208 myDB_tlog_200507141322.TRN
13:32 158.208 myDB_tlog_200507141332.TRN
13:42 92.672 myDB_tlog_200507141342.TRN
13:52 158.208 myDB_tlog_200507141352.TRN
14:02 92.672 myDB_tlog_200507141402.TRN
14:12 92.672 myDB_tlog_200507141412.TRN
14:22 92.672 myDB_tlog_200507141422.TRN
14:32 289.280 myDB_tlog_200507141432.TRN
14:42 16.926.208 myDB_tlog_200507141442.TRN Note
14:52 280.064 myDB_tlog_200507141452.TRN
15:02 411.136 myDB_tlog_200507141502.TRN
Any ideas?
I want to know what is happening, and how to fix it.
Thanks in advance.Hi,
The Size of the transaction log backup will be bigger if you have Bulk
transaction or if you are doing a maintanence operation such
as UPDATE STATISTICS, DBCC INDEXDEFREAG or DBCC DBREINDEX.
Looking in to the current size the transaction log (LDF) I feel that you are
in safe side.
Thanks
Hari
SQL Server MVP
"Juan Carlos" <jcgalarzar@.hotmail.com> wrote in message
news:eP2z25KiFHA.320@.TK2MSFTNGP09.phx.gbl...
> Hi
> I use SQL Server 2000
> I use Full recuperation mode.
> My DB size is 458 MB (344 in use, 114 available)
> My log size is 18 MB
> I do Full backup every hour starting at 8:00 am until 21:00
> I do transaction backup every 10 minutes.
> The problem is that the size of the transaction log backup is strange, as
> follows:
> Time Size(KB) filename
> ...
> 05:52 78.336 myDB_tlog_200507140552.TRN
> 06:02 78.336 myDB_tlog_200507140602.TRN
> 06:12 78.336 myDB_tlog_200507140612.TRN
> 06:22 78.336 myDB_tlog_200507140622.TRN
> 06:32 11.776 myDB_tlog_200507140632.TRN
> 06:42 11.776 myDB_tlog_200507140642.TRN
> 06:52 78.336 myDB_tlog_200507140652.TRN
> 07:03 359.117.312 myDB_tlog_200507140703.TRN Note
> 07:12 133.072.384 myDB_tlog_200507140712.TRN Note
> 07:22 291.328 myDB_tlog_200507140722.TRN
> 07:32 291.328 myDB_tlog_200507140732.TRN
> 07:42 291.328 myDB_tlog_200507140742.TRN
> 07:52 356.864 myDB_tlog_200507140752.TRN
> 08:02 356.864 myDB_tlog_200507140802.TRN
> 08:12 356.864 myDB_tlog_200507140812.TRN
> 08:22 357.888 myDB_tlog_200507140822.TRN
> 08:32 422.400 myDB_tlog_200507140832.TRN
> 08:42 10.663.424 myDB_tlog_200507140842.TRN Note
> 08:52 437.760 myDB_tlog_200507140852.TRN
> 09:02 437.760 myDB_tlog_200507140902.TRN
> 09:12 699.904 myDB_tlog_200507140912.TRN
> 09:22 503.296 myDB_tlog_200507140922.TRN
> 09:32 568.832 myDB_tlog_200507140932.TRN
> 09:42 568.832 myDB_tlog_200507140942.TRN
> 09:52 569.856 myDB_tlog_200507140952.TRN
> 10:02 372.224 myDB_tlog_200507141002.TRN
> 10:12 10.442.240 myDB_tlog_200507141012.TRN Note
> 10:22 413.184 myDB_tlog_200507141022.TRN
> 10:32 545.280 myDB_tlog_200507141032.TRN
> 10:42 479.744 myDB_tlog_200507141042.TRN
> 10:52 414.208 myDB_tlog_200507141052.TRN
> 11:02 479.744 myDB_tlog_200507141102.TRN
> 11:12 413.184 myDB_tlog_200507141112.TRN
> 11:22 414.208 myDB_tlog_200507141122.TRN
> 11:32 546.304 myDB_tlog_200507141132.TRN
> 11:42 1.093.120 myDB_tlog_200507141142.TRN
> 11:52 303.616 myDB_tlog_200507141152.TRN
> 12:02 436.736 myDB_tlog_200507141202.TRN
> 12:12 369.152 myDB_tlog_200507141212.TRN
> 12:22 239.104 myDB_tlog_200507141222.TRN
> 12:32 172.544 myDB_tlog_200507141232.TRN
> 12:42 107.008 myDB_tlog_200507141242.TRN
> 12:52 172.544 myDB_tlog_200507141252.TRN
> 13:02 239.104 myDB_tlog_200507141302.TRN
> 13:12 9.269.760 myDB_tlog_200507141312.TRN Note
> 13:22 158.208 myDB_tlog_200507141322.TRN
> 13:32 158.208 myDB_tlog_200507141332.TRN
> 13:42 92.672 myDB_tlog_200507141342.TRN
> 13:52 158.208 myDB_tlog_200507141352.TRN
> 14:02 92.672 myDB_tlog_200507141402.TRN
> 14:12 92.672 myDB_tlog_200507141412.TRN
> 14:22 92.672 myDB_tlog_200507141422.TRN
> 14:32 289.280 myDB_tlog_200507141432.TRN
> 14:42 16.926.208 myDB_tlog_200507141442.TRN Note
> 14:52 280.064 myDB_tlog_200507141452.TRN
> 15:02 411.136 myDB_tlog_200507141502.TRN
> Any ideas?
> I want to know what is happening, and how to fix it.
> Thanks in advance.
>
>|||Thanks Hari.
But I'm still confused about then changing size!!!
From 300 KB to 16 MB.
Any ideas?
Thanks in advance.
"Hari Prasad" <hari_prasad_k@.hotmail.com> escribió en el mensaje
news:uLHvBRLiFHA.2852@.TK2MSFTNGP15.phx.gbl...
> Hi,
> The Size of the transaction log backup will be bigger if you have Bulk
> transaction or if you are doing a maintanence operation such
> as UPDATE STATISTICS, DBCC INDEXDEFREAG or DBCC DBREINDEX.
> Looking in to the current size the transaction log (LDF) I feel that you
are
> in safe side.
> Thanks
> Hari
> SQL Server MVP
>
>
> "Juan Carlos" <jcgalarzar@.hotmail.com> wrote in message
> news:eP2z25KiFHA.320@.TK2MSFTNGP09.phx.gbl...
> > Hi
> > I use SQL Server 2000
> > I use Full recuperation mode.
> > My DB size is 458 MB (344 in use, 114 available)
> > My log size is 18 MB
> > I do Full backup every hour starting at 8:00 am until 21:00
> > I do transaction backup every 10 minutes.
> >
> > The problem is that the size of the transaction log backup is strange,
as
> > follows:
> >
> > Time Size(KB) filename
> > ...
> > 05:52 78.336 myDB_tlog_200507140552.TRN
> > 06:02 78.336 myDB_tlog_200507140602.TRN
> > 06:12 78.336 myDB_tlog_200507140612.TRN
> > 06:22 78.336 myDB_tlog_200507140622.TRN
> > 06:32 11.776 myDB_tlog_200507140632.TRN
> > 06:42 11.776 myDB_tlog_200507140642.TRN
> > 06:52 78.336 myDB_tlog_200507140652.TRN
> > 07:03 359.117.312 myDB_tlog_200507140703.TRN Note
> > 07:12 133.072.384 myDB_tlog_200507140712.TRN Note
> > 07:22 291.328 myDB_tlog_200507140722.TRN
> > 07:32 291.328 myDB_tlog_200507140732.TRN
> > 07:42 291.328 myDB_tlog_200507140742.TRN
> > 07:52 356.864 myDB_tlog_200507140752.TRN
> > 08:02 356.864 myDB_tlog_200507140802.TRN
> > 08:12 356.864 myDB_tlog_200507140812.TRN
> > 08:22 357.888 myDB_tlog_200507140822.TRN
> > 08:32 422.400 myDB_tlog_200507140832.TRN
> > 08:42 10.663.424 myDB_tlog_200507140842.TRN Note
> > 08:52 437.760 myDB_tlog_200507140852.TRN
> > 09:02 437.760 myDB_tlog_200507140902.TRN
> > 09:12 699.904 myDB_tlog_200507140912.TRN
> > 09:22 503.296 myDB_tlog_200507140922.TRN
> > 09:32 568.832 myDB_tlog_200507140932.TRN
> > 09:42 568.832 myDB_tlog_200507140942.TRN
> > 09:52 569.856 myDB_tlog_200507140952.TRN
> > 10:02 372.224 myDB_tlog_200507141002.TRN
> > 10:12 10.442.240 myDB_tlog_200507141012.TRN Note
> > 10:22 413.184 myDB_tlog_200507141022.TRN
> > 10:32 545.280 myDB_tlog_200507141032.TRN
> > 10:42 479.744 myDB_tlog_200507141042.TRN
> > 10:52 414.208 myDB_tlog_200507141052.TRN
> > 11:02 479.744 myDB_tlog_200507141102.TRN
> > 11:12 413.184 myDB_tlog_200507141112.TRN
> > 11:22 414.208 myDB_tlog_200507141122.TRN
> > 11:32 546.304 myDB_tlog_200507141132.TRN
> > 11:42 1.093.120 myDB_tlog_200507141142.TRN
> > 11:52 303.616 myDB_tlog_200507141152.TRN
> > 12:02 436.736 myDB_tlog_200507141202.TRN
> > 12:12 369.152 myDB_tlog_200507141212.TRN
> > 12:22 239.104 myDB_tlog_200507141222.TRN
> > 12:32 172.544 myDB_tlog_200507141232.TRN
> > 12:42 107.008 myDB_tlog_200507141242.TRN
> > 12:52 172.544 myDB_tlog_200507141252.TRN
> > 13:02 239.104 myDB_tlog_200507141302.TRN
> > 13:12 9.269.760 myDB_tlog_200507141312.TRN Note
> > 13:22 158.208 myDB_tlog_200507141322.TRN
> > 13:32 158.208 myDB_tlog_200507141332.TRN
> > 13:42 92.672 myDB_tlog_200507141342.TRN
> > 13:52 158.208 myDB_tlog_200507141352.TRN
> > 14:02 92.672 myDB_tlog_200507141402.TRN
> > 14:12 92.672 myDB_tlog_200507141412.TRN
> > 14:22 92.672 myDB_tlog_200507141422.TRN
> > 14:32 289.280 myDB_tlog_200507141432.TRN
> > 14:42 16.926.208 myDB_tlog_200507141442.TRN Note
> > 14:52 280.064 myDB_tlog_200507141452.TRN
> > 15:02 411.136 myDB_tlog_200507141502.TRN
> >
> > Any ideas?
> > I want to know what is happening, and how to fix it.
> > Thanks in advance.
> >
> >
> >
>|||The amount of data in the log is totally dependant on what you are doing
since the last log backup. Use profiler to see what is happening during the
time when the log backups are large and you will see what i causing the
difference.
--
Andrew J. Kelly SQL MVP
"Juan Carlos" <jcgalarzar@.hotmail.com> wrote in message
news:%23pEhNpLiFHA.1372@.TK2MSFTNGP10.phx.gbl...
> Thanks Hari.
> But I'm still confused about then changing size!!!
> From 300 KB to 16 MB.
> Any ideas?
> Thanks in advance.
> "Hari Prasad" <hari_prasad_k@.hotmail.com> escribió en el mensaje
> news:uLHvBRLiFHA.2852@.TK2MSFTNGP15.phx.gbl...
>> Hi,
>> The Size of the transaction log backup will be bigger if you have Bulk
>> transaction or if you are doing a maintanence operation such
>> as UPDATE STATISTICS, DBCC INDEXDEFREAG or DBCC DBREINDEX.
>> Looking in to the current size the transaction log (LDF) I feel that you
> are
>> in safe side.
>> Thanks
>> Hari
>> SQL Server MVP
>>
>>
>> "Juan Carlos" <jcgalarzar@.hotmail.com> wrote in message
>> news:eP2z25KiFHA.320@.TK2MSFTNGP09.phx.gbl...
>> > Hi
>> > I use SQL Server 2000
>> > I use Full recuperation mode.
>> > My DB size is 458 MB (344 in use, 114 available)
>> > My log size is 18 MB
>> > I do Full backup every hour starting at 8:00 am until 21:00
>> > I do transaction backup every 10 minutes.
>> >
>> > The problem is that the size of the transaction log backup is strange,
> as
>> > follows:
>> >
>> > Time Size(KB) filename
>> > ...
>> > 05:52 78.336 myDB_tlog_200507140552.TRN
>> > 06:02 78.336 myDB_tlog_200507140602.TRN
>> > 06:12 78.336 myDB_tlog_200507140612.TRN
>> > 06:22 78.336 myDB_tlog_200507140622.TRN
>> > 06:32 11.776 myDB_tlog_200507140632.TRN
>> > 06:42 11.776 myDB_tlog_200507140642.TRN
>> > 06:52 78.336 myDB_tlog_200507140652.TRN
>> > 07:03 359.117.312 myDB_tlog_200507140703.TRN Note
>> > 07:12 133.072.384 myDB_tlog_200507140712.TRN Note
>> > 07:22 291.328 myDB_tlog_200507140722.TRN
>> > 07:32 291.328 myDB_tlog_200507140732.TRN
>> > 07:42 291.328 myDB_tlog_200507140742.TRN
>> > 07:52 356.864 myDB_tlog_200507140752.TRN
>> > 08:02 356.864 myDB_tlog_200507140802.TRN
>> > 08:12 356.864 myDB_tlog_200507140812.TRN
>> > 08:22 357.888 myDB_tlog_200507140822.TRN
>> > 08:32 422.400 myDB_tlog_200507140832.TRN
>> > 08:42 10.663.424 myDB_tlog_200507140842.TRN Note
>> > 08:52 437.760 myDB_tlog_200507140852.TRN
>> > 09:02 437.760 myDB_tlog_200507140902.TRN
>> > 09:12 699.904 myDB_tlog_200507140912.TRN
>> > 09:22 503.296 myDB_tlog_200507140922.TRN
>> > 09:32 568.832 myDB_tlog_200507140932.TRN
>> > 09:42 568.832 myDB_tlog_200507140942.TRN
>> > 09:52 569.856 myDB_tlog_200507140952.TRN
>> > 10:02 372.224 myDB_tlog_200507141002.TRN
>> > 10:12 10.442.240 myDB_tlog_200507141012.TRN Note
>> > 10:22 413.184 myDB_tlog_200507141022.TRN
>> > 10:32 545.280 myDB_tlog_200507141032.TRN
>> > 10:42 479.744 myDB_tlog_200507141042.TRN
>> > 10:52 414.208 myDB_tlog_200507141052.TRN
>> > 11:02 479.744 myDB_tlog_200507141102.TRN
>> > 11:12 413.184 myDB_tlog_200507141112.TRN
>> > 11:22 414.208 myDB_tlog_200507141122.TRN
>> > 11:32 546.304 myDB_tlog_200507141132.TRN
>> > 11:42 1.093.120 myDB_tlog_200507141142.TRN
>> > 11:52 303.616 myDB_tlog_200507141152.TRN
>> > 12:02 436.736 myDB_tlog_200507141202.TRN
>> > 12:12 369.152 myDB_tlog_200507141212.TRN
>> > 12:22 239.104 myDB_tlog_200507141222.TRN
>> > 12:32 172.544 myDB_tlog_200507141232.TRN
>> > 12:42 107.008 myDB_tlog_200507141242.TRN
>> > 12:52 172.544 myDB_tlog_200507141252.TRN
>> > 13:02 239.104 myDB_tlog_200507141302.TRN
>> > 13:12 9.269.760 myDB_tlog_200507141312.TRN Note
>> > 13:22 158.208 myDB_tlog_200507141322.TRN
>> > 13:32 158.208 myDB_tlog_200507141332.TRN
>> > 13:42 92.672 myDB_tlog_200507141342.TRN
>> > 13:52 158.208 myDB_tlog_200507141352.TRN
>> > 14:02 92.672 myDB_tlog_200507141402.TRN
>> > 14:12 92.672 myDB_tlog_200507141412.TRN
>> > 14:22 92.672 myDB_tlog_200507141422.TRN
>> > 14:32 289.280 myDB_tlog_200507141432.TRN
>> > 14:42 16.926.208 myDB_tlog_200507141442.TRN Note
>> > 14:52 280.064 myDB_tlog_200507141452.TRN
>> > 15:02 411.136 myDB_tlog_200507141502.TRN
>> >
>> > Any ideas?
>> > I want to know what is happening, and how to fix it.
>> > Thanks in advance.
>> >
>> >
>> >
>>
>
My Transaction Log size very strange
I use SQL Server 2000
I use Full recuperation mode.
My DB size is 458 MB (344 in use, 114 available)
My log size is 18 MB
I do Full backup every hour starting at 8:00 am until 21:00
I do transaction backup every 10 minutes.
The problem is that the size of the transaction log backup is strange, as
follows:
Time Size(KB) filename
....
05:52 78.336 myDB_tlog_200507140552.TRN
06:02 78.336 myDB_tlog_200507140602.TRN
06:12 78.336 myDB_tlog_200507140612.TRN
06:22 78.336 myDB_tlog_200507140622.TRN
06:32 11.776 myDB_tlog_200507140632.TRN
06:42 11.776 myDB_tlog_200507140642.TRN
06:52 78.336 myDB_tlog_200507140652.TRN
07:03 359.117.312 myDB_tlog_200507140703.TRN Note
07:12 133.072.384 myDB_tlog_200507140712.TRN Note
07:22 291.328 myDB_tlog_200507140722.TRN
07:32 291.328 myDB_tlog_200507140732.TRN
07:42 291.328 myDB_tlog_200507140742.TRN
07:52 356.864 myDB_tlog_200507140752.TRN
08:02 356.864 myDB_tlog_200507140802.TRN
08:12 356.864 myDB_tlog_200507140812.TRN
08:22 357.888 myDB_tlog_200507140822.TRN
08:32 422.400 myDB_tlog_200507140832.TRN
08:42 10.663.424 myDB_tlog_200507140842.TRN Note
08:52 437.760 myDB_tlog_200507140852.TRN
09:02 437.760 myDB_tlog_200507140902.TRN
09:12 699.904 myDB_tlog_200507140912.TRN
09:22 503.296 myDB_tlog_200507140922.TRN
09:32 568.832 myDB_tlog_200507140932.TRN
09:42 568.832 myDB_tlog_200507140942.TRN
09:52 569.856 myDB_tlog_200507140952.TRN
10:02 372.224 myDB_tlog_200507141002.TRN
10:12 10.442.240 myDB_tlog_200507141012.TRN Note
10:22 413.184 myDB_tlog_200507141022.TRN
10:32 545.280 myDB_tlog_200507141032.TRN
10:42 479.744 myDB_tlog_200507141042.TRN
10:52 414.208 myDB_tlog_200507141052.TRN
11:02 479.744 myDB_tlog_200507141102.TRN
11:12 413.184 myDB_tlog_200507141112.TRN
11:22 414.208 myDB_tlog_200507141122.TRN
11:32 546.304 myDB_tlog_200507141132.TRN
11:42 1.093.120 myDB_tlog_200507141142.TRN
11:52 303.616 myDB_tlog_200507141152.TRN
12:02 436.736 myDB_tlog_200507141202.TRN
12:12 369.152 myDB_tlog_200507141212.TRN
12:22 239.104 myDB_tlog_200507141222.TRN
12:32 172.544 myDB_tlog_200507141232.TRN
12:42 107.008 myDB_tlog_200507141242.TRN
12:52 172.544 myDB_tlog_200507141252.TRN
13:02 239.104 myDB_tlog_200507141302.TRN
13:12 9.269.760 myDB_tlog_200507141312.TRN Note
13:22 158.208 myDB_tlog_200507141322.TRN
13:32 158.208 myDB_tlog_200507141332.TRN
13:42 92.672 myDB_tlog_200507141342.TRN
13:52 158.208 myDB_tlog_200507141352.TRN
14:02 92.672 myDB_tlog_200507141402.TRN
14:12 92.672 myDB_tlog_200507141412.TRN
14:22 92.672 myDB_tlog_200507141422.TRN
14:32 289.280 myDB_tlog_200507141432.TRN
14:42 16.926.208 myDB_tlog_200507141442.TRN Note
14:52 280.064 myDB_tlog_200507141452.TRN
15:02 411.136 myDB_tlog_200507141502.TRN
Any ideas?
I want to know what is happening, and how to fix it.
Thanks in advance.
Hi,
The Size of the transaction log backup will be bigger if you have Bulk
transaction or if you are doing a maintanence operation such
as UPDATE STATISTICS, DBCC INDEXDEFREAG or DBCC DBREINDEX.
Looking in to the current size the transaction log (LDF) I feel that you are
in safe side.
Thanks
Hari
SQL Server MVP
"Juan Carlos" <jcgalarzar@.hotmail.com> wrote in message
news:eP2z25KiFHA.320@.TK2MSFTNGP09.phx.gbl...
> Hi
> I use SQL Server 2000
> I use Full recuperation mode.
> My DB size is 458 MB (344 in use, 114 available)
> My log size is 18 MB
> I do Full backup every hour starting at 8:00 am until 21:00
> I do transaction backup every 10 minutes.
> The problem is that the size of the transaction log backup is strange, as
> follows:
> Time Size(KB) filename
> ...
> 05:52 78.336 myDB_tlog_200507140552.TRN
> 06:02 78.336 myDB_tlog_200507140602.TRN
> 06:12 78.336 myDB_tlog_200507140612.TRN
> 06:22 78.336 myDB_tlog_200507140622.TRN
> 06:32 11.776 myDB_tlog_200507140632.TRN
> 06:42 11.776 myDB_tlog_200507140642.TRN
> 06:52 78.336 myDB_tlog_200507140652.TRN
> 07:03 359.117.312 myDB_tlog_200507140703.TRN Note
> 07:12 133.072.384 myDB_tlog_200507140712.TRN Note
> 07:22 291.328 myDB_tlog_200507140722.TRN
> 07:32 291.328 myDB_tlog_200507140732.TRN
> 07:42 291.328 myDB_tlog_200507140742.TRN
> 07:52 356.864 myDB_tlog_200507140752.TRN
> 08:02 356.864 myDB_tlog_200507140802.TRN
> 08:12 356.864 myDB_tlog_200507140812.TRN
> 08:22 357.888 myDB_tlog_200507140822.TRN
> 08:32 422.400 myDB_tlog_200507140832.TRN
> 08:42 10.663.424 myDB_tlog_200507140842.TRN Note
> 08:52 437.760 myDB_tlog_200507140852.TRN
> 09:02 437.760 myDB_tlog_200507140902.TRN
> 09:12 699.904 myDB_tlog_200507140912.TRN
> 09:22 503.296 myDB_tlog_200507140922.TRN
> 09:32 568.832 myDB_tlog_200507140932.TRN
> 09:42 568.832 myDB_tlog_200507140942.TRN
> 09:52 569.856 myDB_tlog_200507140952.TRN
> 10:02 372.224 myDB_tlog_200507141002.TRN
> 10:12 10.442.240 myDB_tlog_200507141012.TRN Note
> 10:22 413.184 myDB_tlog_200507141022.TRN
> 10:32 545.280 myDB_tlog_200507141032.TRN
> 10:42 479.744 myDB_tlog_200507141042.TRN
> 10:52 414.208 myDB_tlog_200507141052.TRN
> 11:02 479.744 myDB_tlog_200507141102.TRN
> 11:12 413.184 myDB_tlog_200507141112.TRN
> 11:22 414.208 myDB_tlog_200507141122.TRN
> 11:32 546.304 myDB_tlog_200507141132.TRN
> 11:42 1.093.120 myDB_tlog_200507141142.TRN
> 11:52 303.616 myDB_tlog_200507141152.TRN
> 12:02 436.736 myDB_tlog_200507141202.TRN
> 12:12 369.152 myDB_tlog_200507141212.TRN
> 12:22 239.104 myDB_tlog_200507141222.TRN
> 12:32 172.544 myDB_tlog_200507141232.TRN
> 12:42 107.008 myDB_tlog_200507141242.TRN
> 12:52 172.544 myDB_tlog_200507141252.TRN
> 13:02 239.104 myDB_tlog_200507141302.TRN
> 13:12 9.269.760 myDB_tlog_200507141312.TRN Note
> 13:22 158.208 myDB_tlog_200507141322.TRN
> 13:32 158.208 myDB_tlog_200507141332.TRN
> 13:42 92.672 myDB_tlog_200507141342.TRN
> 13:52 158.208 myDB_tlog_200507141352.TRN
> 14:02 92.672 myDB_tlog_200507141402.TRN
> 14:12 92.672 myDB_tlog_200507141412.TRN
> 14:22 92.672 myDB_tlog_200507141422.TRN
> 14:32 289.280 myDB_tlog_200507141432.TRN
> 14:42 16.926.208 myDB_tlog_200507141442.TRN Note
> 14:52 280.064 myDB_tlog_200507141452.TRN
> 15:02 411.136 myDB_tlog_200507141502.TRN
> Any ideas?
> I want to know what is happening, and how to fix it.
> Thanks in advance.
>
>
|||Thanks Hari.
But I'm still confused about then changing size!!!
From 300 KB to 16 MB.
Any ideas?
Thanks in advance.
"Hari Prasad" <hari_prasad_k@.hotmail.com> escribi en el mensaje
news:uLHvBRLiFHA.2852@.TK2MSFTNGP15.phx.gbl...
> Hi,
> The Size of the transaction log backup will be bigger if you have Bulk
> transaction or if you are doing a maintanence operation such
> as UPDATE STATISTICS, DBCC INDEXDEFREAG or DBCC DBREINDEX.
> Looking in to the current size the transaction log (LDF) I feel that you
are[vbcol=seagreen]
> in safe side.
> Thanks
> Hari
> SQL Server MVP
>
>
> "Juan Carlos" <jcgalarzar@.hotmail.com> wrote in message
> news:eP2z25KiFHA.320@.TK2MSFTNGP09.phx.gbl...
as
>
|||The amount of data in the log is totally dependant on what you are doing
since the last log backup. Use profiler to see what is happening during the
time when the log backups are large and you will see what i causing the
difference.
Andrew J. Kelly SQL MVP
"Juan Carlos" <jcgalarzar@.hotmail.com> wrote in message
news:%23pEhNpLiFHA.1372@.TK2MSFTNGP10.phx.gbl...
> Thanks Hari.
> But I'm still confused about then changing size!!!
> From 300 KB to 16 MB.
> Any ideas?
> Thanks in advance.
> "Hari Prasad" <hari_prasad_k@.hotmail.com> escribi en el mensaje
> news:uLHvBRLiFHA.2852@.TK2MSFTNGP15.phx.gbl...
> are
> as
>
My Transaction Log size very strange
I use SQL Server 2000
I use Full recuperation mode.
My DB size is 458 MB (344 in use, 114 available)
My log size is 18 MB
I do Full backup every hour starting at 8:00 am until 21:00
I do transaction backup every 10 minutes.
The problem is that the size of the transaction log backup is strange, as
follows:
Time Size(KB) filename
...
05:52 78.336 myDB_tlog_200507140552.TRN
06:02 78.336 myDB_tlog_200507140602.TRN
06:12 78.336 myDB_tlog_200507140612.TRN
06:22 78.336 myDB_tlog_200507140622.TRN
06:32 11.776 myDB_tlog_200507140632.TRN
06:42 11.776 myDB_tlog_200507140642.TRN
06:52 78.336 myDB_tlog_200507140652.TRN
07:03 359.117.312 myDB_tlog_200507140703.TRN Note
07:12 133.072.384 myDB_tlog_200507140712.TRN Note
07:22 291.328 myDB_tlog_200507140722.TRN
07:32 291.328 myDB_tlog_200507140732.TRN
07:42 291.328 myDB_tlog_200507140742.TRN
07:52 356.864 myDB_tlog_200507140752.TRN
08:02 356.864 myDB_tlog_200507140802.TRN
08:12 356.864 myDB_tlog_200507140812.TRN
08:22 357.888 myDB_tlog_200507140822.TRN
08:32 422.400 myDB_tlog_200507140832.TRN
08:42 10.663.424 myDB_tlog_200507140842.TRN Note
08:52 437.760 myDB_tlog_200507140852.TRN
09:02 437.760 myDB_tlog_200507140902.TRN
09:12 699.904 myDB_tlog_200507140912.TRN
09:22 503.296 myDB_tlog_200507140922.TRN
09:32 568.832 myDB_tlog_200507140932.TRN
09:42 568.832 myDB_tlog_200507140942.TRN
09:52 569.856 myDB_tlog_200507140952.TRN
10:02 372.224 myDB_tlog_200507141002.TRN
10:12 10.442.240 myDB_tlog_200507141012.TRN Note
10:22 413.184 myDB_tlog_200507141022.TRN
10:32 545.280 myDB_tlog_200507141032.TRN
10:42 479.744 myDB_tlog_200507141042.TRN
10:52 414.208 myDB_tlog_200507141052.TRN
11:02 479.744 myDB_tlog_200507141102.TRN
11:12 413.184 myDB_tlog_200507141112.TRN
11:22 414.208 myDB_tlog_200507141122.TRN
11:32 546.304 myDB_tlog_200507141132.TRN
11:42 1.093.120 myDB_tlog_200507141142.TRN
11:52 303.616 myDB_tlog_200507141152.TRN
12:02 436.736 myDB_tlog_200507141202.TRN
12:12 369.152 myDB_tlog_200507141212.TRN
12:22 239.104 myDB_tlog_200507141222.TRN
12:32 172.544 myDB_tlog_200507141232.TRN
12:42 107.008 myDB_tlog_200507141242.TRN
12:52 172.544 myDB_tlog_200507141252.TRN
13:02 239.104 myDB_tlog_200507141302.TRN
13:12 9.269.760 myDB_tlog_200507141312.TRN Note
13:22 158.208 myDB_tlog_200507141322.TRN
13:32 158.208 myDB_tlog_200507141332.TRN
13:42 92.672 myDB_tlog_200507141342.TRN
13:52 158.208 myDB_tlog_200507141352.TRN
14:02 92.672 myDB_tlog_200507141402.TRN
14:12 92.672 myDB_tlog_200507141412.TRN
14:22 92.672 myDB_tlog_200507141422.TRN
14:32 289.280 myDB_tlog_200507141432.TRN
14:42 16.926.208 myDB_tlog_200507141442.TRN Note
14:52 280.064 myDB_tlog_200507141452.TRN
15:02 411.136 myDB_tlog_200507141502.TRN
Any ideas?
I want to know what is happening, and how to fix it.
Thanks in advance.Hi,
The Size of the transaction log backup will be bigger if you have Bulk
transaction or if you are doing a maintanence operation such
as UPDATE STATISTICS, DBCC INDEXDEFREAG or DBCC DBREINDEX.
Looking in to the current size the transaction log (LDF) I feel that you are
in safe side.
Thanks
Hari
SQL Server MVP
"Juan Carlos" <jcgalarzar@.hotmail.com> wrote in message
news:eP2z25KiFHA.320@.TK2MSFTNGP09.phx.gbl...
> Hi
> I use SQL Server 2000
> I use Full recuperation mode.
> My DB size is 458 MB (344 in use, 114 available)
> My log size is 18 MB
> I do Full backup every hour starting at 8:00 am until 21:00
> I do transaction backup every 10 minutes.
> The problem is that the size of the transaction log backup is strange, as
> follows:
> Time Size(KB) filename
> ...
> 05:52 78.336 myDB_tlog_200507140552.TRN
> 06:02 78.336 myDB_tlog_200507140602.TRN
> 06:12 78.336 myDB_tlog_200507140612.TRN
> 06:22 78.336 myDB_tlog_200507140622.TRN
> 06:32 11.776 myDB_tlog_200507140632.TRN
> 06:42 11.776 myDB_tlog_200507140642.TRN
> 06:52 78.336 myDB_tlog_200507140652.TRN
> 07:03 359.117.312 myDB_tlog_200507140703.TRN Note
> 07:12 133.072.384 myDB_tlog_200507140712.TRN Note
> 07:22 291.328 myDB_tlog_200507140722.TRN
> 07:32 291.328 myDB_tlog_200507140732.TRN
> 07:42 291.328 myDB_tlog_200507140742.TRN
> 07:52 356.864 myDB_tlog_200507140752.TRN
> 08:02 356.864 myDB_tlog_200507140802.TRN
> 08:12 356.864 myDB_tlog_200507140812.TRN
> 08:22 357.888 myDB_tlog_200507140822.TRN
> 08:32 422.400 myDB_tlog_200507140832.TRN
> 08:42 10.663.424 myDB_tlog_200507140842.TRN Note
> 08:52 437.760 myDB_tlog_200507140852.TRN
> 09:02 437.760 myDB_tlog_200507140902.TRN
> 09:12 699.904 myDB_tlog_200507140912.TRN
> 09:22 503.296 myDB_tlog_200507140922.TRN
> 09:32 568.832 myDB_tlog_200507140932.TRN
> 09:42 568.832 myDB_tlog_200507140942.TRN
> 09:52 569.856 myDB_tlog_200507140952.TRN
> 10:02 372.224 myDB_tlog_200507141002.TRN
> 10:12 10.442.240 myDB_tlog_200507141012.TRN Note
> 10:22 413.184 myDB_tlog_200507141022.TRN
> 10:32 545.280 myDB_tlog_200507141032.TRN
> 10:42 479.744 myDB_tlog_200507141042.TRN
> 10:52 414.208 myDB_tlog_200507141052.TRN
> 11:02 479.744 myDB_tlog_200507141102.TRN
> 11:12 413.184 myDB_tlog_200507141112.TRN
> 11:22 414.208 myDB_tlog_200507141122.TRN
> 11:32 546.304 myDB_tlog_200507141132.TRN
> 11:42 1.093.120 myDB_tlog_200507141142.TRN
> 11:52 303.616 myDB_tlog_200507141152.TRN
> 12:02 436.736 myDB_tlog_200507141202.TRN
> 12:12 369.152 myDB_tlog_200507141212.TRN
> 12:22 239.104 myDB_tlog_200507141222.TRN
> 12:32 172.544 myDB_tlog_200507141232.TRN
> 12:42 107.008 myDB_tlog_200507141242.TRN
> 12:52 172.544 myDB_tlog_200507141252.TRN
> 13:02 239.104 myDB_tlog_200507141302.TRN
> 13:12 9.269.760 myDB_tlog_200507141312.TRN Note
> 13:22 158.208 myDB_tlog_200507141322.TRN
> 13:32 158.208 myDB_tlog_200507141332.TRN
> 13:42 92.672 myDB_tlog_200507141342.TRN
> 13:52 158.208 myDB_tlog_200507141352.TRN
> 14:02 92.672 myDB_tlog_200507141402.TRN
> 14:12 92.672 myDB_tlog_200507141412.TRN
> 14:22 92.672 myDB_tlog_200507141422.TRN
> 14:32 289.280 myDB_tlog_200507141432.TRN
> 14:42 16.926.208 myDB_tlog_200507141442.TRN Note
> 14:52 280.064 myDB_tlog_200507141452.TRN
> 15:02 411.136 myDB_tlog_200507141502.TRN
> Any ideas?
> I want to know what is happening, and how to fix it.
> Thanks in advance.
>
>|||Thanks Hari.
But I'm still confused about then changing size!!!
From 300 KB to 16 MB.
Any ideas?
Thanks in advance.
"Hari Prasad" <hari_prasad_k@.hotmail.com> escribi en el mensaje
news:uLHvBRLiFHA.2852@.TK2MSFTNGP15.phx.gbl...
> Hi,
> The Size of the transaction log backup will be bigger if you have Bulk
> transaction or if you are doing a maintanence operation such
> as UPDATE STATISTICS, DBCC INDEXDEFREAG or DBCC DBREINDEX.
> Looking in to the current size the transaction log (LDF) I feel that you
are
> in safe side.
> Thanks
> Hari
> SQL Server MVP
>
>
> "Juan Carlos" <jcgalarzar@.hotmail.com> wrote in message
> news:eP2z25KiFHA.320@.TK2MSFTNGP09.phx.gbl...
as[vbcol=seagreen]
>|||The amount of data in the log is totally dependant on what you are doing
since the last log backup. Use profiler to see what is happening during the
time when the log backups are large and you will see what i causing the
difference.
Andrew J. Kelly SQL MVP
"Juan Carlos" <jcgalarzar@.hotmail.com> wrote in message
news:%23pEhNpLiFHA.1372@.TK2MSFTNGP10.phx.gbl...
> Thanks Hari.
> But I'm still confused about then changing size!!!
> From 300 KB to 16 MB.
> Any ideas?
> Thanks in advance.
> "Hari Prasad" <hari_prasad_k@.hotmail.com> escribi en el mensaje
> news:uLHvBRLiFHA.2852@.TK2MSFTNGP15.phx.gbl...
> are
> as
>