What is RecoveryUnitID in DBCC LOGINFO?

In SQL Server 2012, MSFT added a new column to the output of DBCC
LOGINFO, called RecoveryUnitID. I know that this DBCC command is undocumented, but I am surprised that I can't find it anywhere what it is?
MSFT said on Connect that they would be adding it to a documented DMV in SQL Sever 2014 but I can't find it. There are also people on Connect saying how it is important for performance, but again, no explanation of why.
Can anybody tell me what it is?

If you are lucky someone from the MS will jump in and explain what this column is used for, but I have my doubts.
Best Regards,Uri Dimant SQL Server MVP,
http://sqlblog.com/blogs/uri_dimant/
MS SQL optimization: MS SQL Development and Optimization
MS SQL Consulting:
Large scale of database and data cleansing
Remote DBA Services:
Improves MS SQL Database Performance
SQL Server Integration Services:
Business Intelligence

Similar Messages

Exploring the SQL Server log with DBCC Loginfo

In SQL Server 2012 , DBCC loginfo () is showing new result set .
Can someone please tell me what is RecoveryUnitId in DBCC LOGINFO () in SQL Server 2012

Connect item: "
Posted by Microsoft on 2/6/2008 at 10:08 AM
Thank you for your suggestion.
Our direction is not to document DBCC commands, but for informational queries such as this to add appropriate DMVs. I will add this to the list of DMV requests. Unfortunately it will not make the Katmai release. We will consider it for a future
release. "
LINK:
https://connect.microsoft.com/SQLServer/feedback/details/322149/msft-mso-document-dbcc-loginfo-or-create-new-dmvs-to-view-vlf-info
Kalman Toth Database & OLAP Architect
SQL Server 2014 Design & Programming
New Book / Kindle: Exam 70-461 Bootcamp: Querying Microsoft SQL Server 2012

What's the possible reason to cause dbcc running automatically?

I have a sp which truncates a large table(large 3G) and insert data into the table again(rebuild data for this table). When I run it on a production, it is fine.
but when I run it on a dev, it is very slow. After check the info in detail, I found there are lot of dbcc running during the sp running time.
when running the sp, got output like frequently:
09:35:58.865
DBMS
mysyb -- SQL Text: exec myproc ...
09:35:58.896
DBMS
mysyb -- DBCC execution completed. If DBCC printed error messages, contact a user with System Administrator (SA) role.
09:35:58.912
DBMS
mysyb -- DBCC execution completed. If DBCC printed error messages, contact a user with System Administrator (SA) role.
09:36:00.599
DBMS
mysyb -- DBCC execution completed. If DBCC printed error messages, contact a user with System Administrator (SA) role.
Not sure why. Before running the sp, somebody try to partition this table and then remove the partition. not sure if this is the reason.
So how to find out the reason for this dbcc? it is running automatically. If dbcc checktable or dbcc reindex will resolve this problem?

I can't think of any obvious way to trigger a dbcc on those actions, aside from rewriting sp_extendsegment, etc. to include a dbcc command.
A couple more possible approaches:
1) If the dbcc is one that doesn't normally send output to the client except for the "dbcc exection complete" message, then turning on switch 3605 will direct the output to the errorlog and possibly allowing us to figure out which dbcc command(s) are being run, which may help figure out why and how they are being run. ("undocumented" DBCCs like page, usedextents, etc. don't send output to the client by default) 3605 won't help if the dbcc is one that normally sends output to the client (checkdb, checkindex etc.), nothing additional will be sent to the ASE errorlog.
set switch on 3605
go
execute <yourprocedure>
go
2) You might run your procedure under the stored procedure debugger utility sqldbgr and step through it while watching the output to see what statements trigger the dbcc message.
-bret

ArgumentError: updateItem - What does it mean?

Can anyone tell me how to solve this problem--I want to update a database via a ColdFusion CFC. When I call my cfc function to update, I get this error:
ArgumentError: updateItem called with an item which is not managed on this client
Also, there is a "source not found message" that appears on a tab called "mx.data::ConcreteDataService/UpdateItem" which seems to correspond to the error.
Thank you for any advice.

You will always have at least one active VLF - there will never be an occasion where all VLF's will have a status = 2. Once that VLF is full and the next one is opened, then either a CHECKPOINT or LOG BACKUP will set the status = 0 (if there
are no open transactions that were started in that VLF and no transactions waiting to be shipped, replicated or mirrored).
Hi Jeff,
Not trying to be smart here but the blanket statement that all VLF's will never have status = 2 is NOT incorrect. Here is a simple repro.
use
master
go
drop
database db1
go
use
master
go
create
database db1
go
backup
database db1
to disk =
'c:\Temp\db1.bak'
go
use
db1
go
create
table NewTable
(c1
bigint, c2
char(8000))
go
DBCC
LOGINFO(db1)
begin
tran
insert
NewTable (c1,
c2)
select top
(30)
object_id, convert(char(8000),
name)
from sys.columns
DBCC
LOGINFO(db1)
rollback
tran
--Sankar Reddy
Blog: http://SankarReddy.com/
Twitter: http://twitter.com/SankarReddy13/

Transaction Log Truncate not working on Sql Server 2012 High Availability Groups

Hi Everyone
Firstly I have tried to search the forum for similar issues but can't seem to find any that match our situation.
We have a SQL Server 2012 High Availability Group with 2 Nodes
Node 1 = Primary
Node 2 = Secondary
Backup Schedule as follows
Full Database Backup @ 00:00
Transaction Log Backup every 30 minutes from 00:30:00 till 23:59:59.
These backups are run by Maintenance Jobs, but we have also tried doing direct backups in SSMS using Backup Database and Backup Log commands.
Before we configured the High Availability group the transaction log backups worked fine.
After we configured the High Availability group we performed a Full Backup and the T-Log schedule did the T-Log backup. The 1st T-log backup truncated the log (Used space Decreased) as expected.
However subsequent T-Log backups do not truncate the T-Log.
This happens both in our acceptance and Live environments. This also happens when running the backups as a Backup operator and sysadmin, this does not seem to be a permissions issue at all.
We have tried running the Backup on the Primary and Secondary Replica.
What about High Availability groups could stop Transaction Log Backups from not truncating the log?
Thanks
James

Hi Sean
Thank you for your reply, please see the output of the sys.databases query below, and some others which you may find usefull.
Query: select database_id,recovery_model_desc, log_reuse_wait, log_reuse_wait_desc from sys.databases
where database_id = 5
Result: database_id   recovery_model_desc   log_reuse_wait   log_reuse_wait_desc
                 5
FULL   0
NOTHING
I also ran the following
select database_id, truncation_lsn, last_received_lsn, last_commit_lsn, last_hardened_lsn, last_redone_lsn,*
from sys.dm_hadr_database_replica_states
go
database_id
truncation_lsn
last_received_lsn
last_commit_lsn
last_hardened_lsn
last_redone_lsn
database_id
group_id
replica_id
group_database_id
is_local
synchronization_state
synchronization_state_desc
is_commit_participant
synchronization_health
synchronization_health_desc
database_state
database_state_desc
is_suspended
suspend_reason
suspend_reason_desc
recovery_lsn
truncation_lsn
last_sent_lsn
last_sent_time
last_received_lsn
last_received_time
last_hardened_lsn
last_hardened_time
last_redone_lsn
last_redone_time
log_send_queue_size
log_send_rate
redo_queue_size
redo_rate
filestream_send_rate
end_of_log_lsn
last_commit_lsn
last_commit_time
low_water_mark_for_ghosts
5
1231833000417170000000
1231833000418880000000
1231833000418880000000
1231833000418890000000
1231833000418880000000
5
1391A499-3F9A-47D5-BCE0-70BC204E2A5B
7E8BFC2E-363F-4C48-86F0-C276D3E0C8D9
0581E17A-6B7B-4B8F-9288-BF765BFBCE77
0
2
SYNCHRONIZED
1
2
HEALTHY
NULL
NULL
0
NULL
NULL
4294967295429490000000000
1231833000417170000000
1
41863
1231833000418880000000
41863
1231833000418890000000
41863
1231833000418880000000
41863
0
25541
0
84404
75304
1231833000418880000000
1231833000418880000000
41863
441019861
5
1231833000417170000000
NULL
1231833000418880000000
1231833000418890000000
NULL
5
1391A499-3F9A-47D5-BCE0-70BC204E2A5B
83B9F00E-D63F-4AC0-98FC-35E48FFA2C6F
0581E17A-6B7B-4B8F-9288-BF765BFBCE77
1
2
SYNCHRONIZED
1
2
HEALTHY
0
ONLINE
0
NULL
NULL
4294967295429490000000000
1231833000417170000000
NULL
NULL
NULL
NULL
1231833000418890000000
NULL
NULL
NULL
NULL
NULL
NULL
NULL
NULL
1231833000418880000000
1231833000418880000000
41863
441019861
And
dbcc loginfo
go
RecoveryUnitId
FileId
FileSize
StartOffset
FSeqNo
Status
Parity
CreateLSN
0
2
458752
8192
1231828
0
128
0
0
2
458752
466944
1231829
0
128
0
0
2
458752
925696
1231830
0
128
0
0
2
712704
1384448
1231831
0
128
0
0
2
19398656
2097152
1231832
0
128
1229654000000040000000
0
2
10199171072
21495808
1231833
2
128
1229656000000010000000
0
2
10199171072
10220666880
0
0
64
1229656000000010000000
0
2
10199171072
20419837952
1231827
0
64
1229656000000010000000
0
2
10199171072
30619009024
0
0
128
1229656000000010000000
0
2
10199171072
40818180096
0
0
128
1229656000000010000000
0
2
10199171072
51017351168
0
0
128
1229656000000010000000
0
2
10199171072
61216522240
0
0
128
1229656000000010000000
0
2
10199171072
71415693312
0
0
128
1229656000000010000000
0
2
10199171072
81614864384
0
0
128
1229656000000010000000
0
2
536870912
91814035456
0
0
64
1229989001661260000000
0
2
536870912
92350906368
0
0
64
1229989001661260000000
0
2
536870912
92887777280
0
0
64
1229989001661260000000
0
2
536870912
93424648192
0
0
64
1229989001661260000000
0
2
536870912
93961519104
0
0
64
1229989001661260000000
0
2
536870912
94498390016
0
0
64
1229989001661260000000
0
2
536870912
95035260928
0
0
64
1229989001661260000000
0
2
536870912
95572131840
0
0
64
1229989001661260000000
0
2
536870912
96109002752
0
0
64
1229989001661260000000
0
2
536870912
96645873664
0
0
64
1229989001661260000000
0
2
536870912
97182744576
0
0
64
1229989001661260000000
0
2
536870912
97719615488
0
0
64
1229989001661260000000
0
2
536870912
98256486400
0
0
64
1229989001661260000000
0
2
536870912
98793357312
0
0
64
1229989001661260000000
0
2
536870912
99330228224
0
0
64
1229989001661260000000
0
2
536870912
99867099136
0
0
64
1229989001661260000000
0
2
536870912
100403970048
0
0
64
1229995000058520000000
0
2
536870912
100940840960
0
0
64
1229995000058520000000
0
2
536870912
101477711872
0
0
64
1229995000058520000000
0
2
536870912
102014582784
0
0
64
1229995000058520000000
0
2
536870912
102551453696
0
0
64
1229995000058520000000
0
2
536870912
103088324608
0
0
64
1229995000058520000000
0
2
536870912
103625195520
0
0
64
1229995000058520000000
0
2
536870912
104162066432
0
0
64
1229995000058520000000
0
2
536870912
104698937344
0
0
64
1229995000058520000000
0
2
536870912
105235808256
0
0
64
1229995000058520000000
0
2
536870912
105772679168
0
0
64
1229995000058520000000
0
2
536870912
106309550080
0
0
64
1229995000058520000000
0
2
536870912
106846420992
0
0
64
1229995000058520000000
0
2
536870912
107383291904
0
0
64
1229995000058520000000
0
2
536870912
107920162816
0
0
64
1229995000058520000000
0
2
536870912
108457033728
0
0
64
1229995000058520000000
0
2
536870912
108993904640
0
0
64
1230004000028400000000
0
2
536870912
109530775552
0
0
64
1230004000028400000000
0
2
536870912
110067646464
0
0
64
1230004000028400000000
0
2
536870912
110604517376
0
0
64
1230004000028400000000
0
2
536870912
111141388288
0
0
64
1230004000028400000000
0
2
536870912
111678259200
0
0
64
1230004000028400000000
0
2
536870912
112215130112
0
0
64
1230004000028400000000
0
2
536870912
112752001024
0
0
64
1230004000028400000000
0
2
536870912
113288871936
0
0
64
1230004000028400000000
0
2
536870912
113825742848
0
0
64
1230004000028400000000
0
2
536870912
114362613760
0
0
64
1230004000028400000000
0
2
536870912
114899484672
0
0
64
1230004000028400000000
0
2
536870912
115436355584
0
0
64
1230004000028400000000
0
2
536870912
115973226496
0
0
64
1230004000028400000000
0
2
536870912
116510097408
0
0
64
1230004000028400000000
0
2
536870912
117046968320
0
0
64
1230004000028400000000
0
2
536870912
117583839232
0
0
64
1230012000103140000000
0
2
536870912
118120710144
0
0
64
1230012000103140000000
0
2
536870912
118657581056
0
0
64
1230012000103140000000
0
2
536870912
119194451968
0
0
64
1230012000103140000000
0
2
536870912
119731322880
0
0
64
1230012000103140000000
0
2
536870912
120268193792
0
0
64
1230012000103140000000
0
2
536870912
120805064704
0
0
64
1230012000103140000000
0
2
536870912
121341935616
0
0
64
1230012000103140000000
0
2
536870912
121878806528
0
0
64
1230012000103140000000
0
2
536870912
122415677440
0
0
64
1230012000103140000000
0
2
536870912
122952548352
0
0
64
1230012000103140000000
0
2
536870912
123489419264
0
0
64
1230012000103140000000
0
2
536870912
124026290176
0
0
64
1230012000103140000000
0
2
536870912
124563161088
0
0
64
1230012000103140000000
0
2
536870912
125100032000
0
0
64
1230012000103140000000
0
2
536870912
125636902912
0
0
64
1230012000103140000000
0
2
536870912
126173773824
0
0
128
1230338000973820000000
0
2
536870912
126710644736
0
0
128
1230338000973820000000
0
2
536870912
127247515648
0
0
128
1230338000973820000000
0
2
536870912
127784386560
0
0
128
1230338000973820000000
0
2
536870912
128321257472
0
0
128
1230338000973820000000
0
2
536870912
128858128384
0
0
128
1230338000973820000000
0
2
536870912
129394999296
0
0
128
1230338000973820000000
0
2
536870912
129931870208
0
0
128
1230338000973820000000
0
2
536870912
130468741120
0
0
128
1230338000973820000000
0
2
536870912
131005612032
0
0
128
1230338000973820000000
0
2
536870912
131542482944
0
0
128
1230338000973820000000
0
2
536870912
132079353856
0
0
128
1230338000973820000000
0
2
536870912
132616224768
0
0
128
1230338000973820000000
0
2
536870912
133153095680
0
0
128
1230338000973820000000
0
2
536870912
133689966592
0
0
128
1230338000973820000000
0
2
536870912
134226837504
0
0
128
1230338000973820000000
0
2
536870912
134763708416
0
0
128
1230338001901440000000
0
2
536870912
135300579328
0
0
128
1230338001901440000000
0
2
536870912
135837450240
0
0
128
1230338001901440000000
0
2
536870912
136374321152
0
0
128
1230338001901440000000
0
2
536870912
136911192064
0
0
128
1230338001901440000000
0
2
536870912
137448062976
0
0
128
1230338001901440000000
0
2
536870912
137984933888
0
0
128
1230338001901440000000
0
2
536870912
138521804800
0
0
128
1230338001901440000000
0
2
536870912
139058675712
0
0
128
1230338001901440000000
0
2
536870912
139595546624
0
0
128
1230338001901440000000
0
2
536870912
140132417536
0
0
128
1230338001901440000000
0
2
536870912
140669288448
0
0
128
1230338001901440000000
0
2
536870912
141206159360
0
0
128
1230338001901440000000
0
2
536870912
141743030272
0
0
128
1230338001901440000000
0
2
536870912
142279901184
0
0
128
1230338001901440000000
0
2
536870912
142816772096
0
0
128
1230338001901440000000
0
2
536870912
143353643008
0
0
128
1230346000103040000000
0
2
536870912
143890513920
0
0
128
1230346000103040000000
0
2
536870912
144427384832
0
0
128
1230346000103040000000
0
2
536870912
144964255744
0
0
128
1230346000103040000000
0
2
536870912
145501126656
0
0
128
1230346000103040000000
0
2
536870912
146037997568
0
0
128
1230346000103040000000
0
2
536870912
146574868480
0
0
128
1230346000103040000000
0
2
536870912
147111739392
0
0
128
1230346000103040000000
0
2
536870912
147648610304
0
0
128
1230346000103040000000
0
2
536870912
148185481216
0
0
128
1230346000103040000000
0
2
536870912
148722352128
0
0
128
1230346000103040000000
0
2
536870912
149259223040
0
0
128
1230346000103040000000
0
2
536870912
149796093952
0
0
128
1230346000103040000000
0
2
536870912
150332964864
0
0
128
1230346000103040000000
0
2
536870912
150869835776
0
0
128
1230346000103040000000
0
2
536870912
151406706688
0
0
128
1230346000103040000000
0
2
536870912
151943577600
0
0
128
1230355000086930000000
0
2
536870912
152480448512
0
0
128
1230355000086930000000
0
2
536870912
153017319424
0
0
128
1230355000086930000000
0
2
536870912
153554190336
0
0
128
1230355000086930000000
0
2
536870912
154091061248
0
0
128
1230355000086930000000
0
2
536870912
154627932160
0
0
128
1230355000086930000000
0
2
536870912
155164803072
0
0
128
1230355000086930000000
0
2
536870912
155701673984
0
0
128
1230355000086930000000
0
2
536870912
156238544896
0
0
128
1230355000086930000000
0
2
536870912
156775415808
0
0
128
1230355000086930000000
0
2
536870912
157312286720
0
0
128
1230355000086930000000
0
2
536870912
157849157632
0
0
128
1230355000086930000000
0
2
536870912
158386028544
0
0
128
1230355000086930000000
0
2
536870912
158922899456
0
0
128
1230355000086930000000
0
2
536870912
159459770368
0
0
128
1230355000086930000000
0
2
536870912
159996641280
0
0
128
1230355000086930000000
0
2
536870912
160533512192
0
0
128
1230364000070870000000
0
2
536870912
161070383104
0
0
128
1230364000070870000000
0
2
536870912
161607254016
0
0
128
1230364000070870000000
0
2
536870912
162144124928
0
0
128
1230364000070870000000
0
2
536870912
162680995840
0
0
128
1230364000070870000000
0
2
536870912
163217866752
0
0
128
1230364000070870000000
0
2
536870912
163754737664
0
0
128
1230364000070870000000
0
2
536870912
164291608576
0
0
128
1230364000070870000000
0
2
536870912
164828479488
0
0
128
1230364000070870000000
0
2
536870912
165365350400
0
0
128
1230364000070870000000
0
2
536870912
165902221312
0
0
128
1230364000070870000000
0
2
536870912
166439092224
0
0
128
1230364000070870000000
0
2
536870912
166975963136
0
0
128
1230364000070870000000
0
2
536870912
167512834048
0
0
128
1230364000070870000000
0
2
536870912
168049704960
0
0
128
1230364000070870000000
0
2
536870912
168586575872
0
0
128
1230364000070870000000
0
2
536870912
169123446784
0
0
128
1230373000054750000000
0
2
536870912
169660317696
0
0
128
1230373000054750000000
0
2
536870912
170197188608
0
0
128
1230373000054750000000
0
2
536870912
170734059520
0
0
128
1230373000054750000000
0
2
536870912
171270930432
0
0
128
1230373000054750000000
0
2
536870912
171807801344
0
0
128
1230373000054750000000
0
2
536870912
172344672256
0
0
128
1230373000054750000000
0
2
536870912
172881543168
0
0
128
1230373000054750000000
0
2
536870912
173418414080
0
0
128
1230373000054750000000
0
2
536870912
173955284992
0
0
128
1230373000054750000000
0
2
536870912
174492155904
0
0
128
1230373000054750000000
0
2
536870912
175029026816
0
0
128
1230373000054750000000
0
2
536870912
175565897728
0
0
128
1230373000054750000000
0
2
536870912
176102768640
0
0
128
1230373000054750000000
0
2
536870912
176639639552
0
0
128
1230373000054750000000
0
2
536870912
177176510464
0
0
128
1230373000054750000000
0
2
536870912
177713381376
0
0
128
1230382000038660000000
0
2
536870912
178250252288
0
0
128
1230382000038660000000
0
2
536870912
178787123200
0
0
128
1230382000038660000000
0
2
536870912
179323994112
0
0
128
1230382000038660000000
0
2
536870912
179860865024
0
0
128
1230382000038660000000
0
2
536870912
180397735936
0
0
128
1230382000038660000000
0
2
536870912
180934606848
0
0
128
1230382000038660000000
0
2
536870912
181471477760
0
0
128
1230382000038660000000
0
2
536870912
182008348672
0
0
128
1230382000038660000000
0
2
536870912
182545219584
0
0
128
1230382000038660000000
0
2
536870912
183082090496
0
0
128
1230382000038660000000
0
2
536870912
183618961408
0
0
128
1230382000038660000000
0
2
536870912
184155832320
0
0
128
1230382000038660000000
0
2
536870912
184692703232
0
0
128
1230382000038660000000
0
2
536870912
185229574144
0
0
128
1230382000038660000000
0
2
536870912
185766445056
0
0
128
1230382000038660000000
The create LSN column seems to have been truncated so here is is again, sorry for the bulky reply.
CreateLSN
0
0
0
0
1229654000000041600001
1229656000000012000001
1229656000000012000001
1229656000000012000001
1229656000000012000001
1229656000000012000001
1229656000000012000001
1229656000000012000001
1229656000000012000001
1229656000000012000001
1229989001661260800316
1229989001661260800316
1229989001661260800316
1229989001661260800316
1229989001661260800316
1229989001661260800316
1229989001661260800316
1229989001661260800316
1229989001661260800316
1229989001661260800316
1229989001661260800316
1229989001661260800316
1229989001661260800316
1229989001661260800316
1229989001661260800316
1229989001661260800316
1229995000058525600316
1229995000058525600316
1229995000058525600316
1229995000058525600316
1229995000058525600316
1229995000058525600316
1229995000058525600316
1229995000058525600316
1229995000058525600316
1229995000058525600316
1229995000058525600316
1229995000058525600316
1229995000058525600316
1229995000058525600316
1229995000058525600316
1229995000058525600316
1230004000028405600295
1230004000028405600295
1230004000028405600295
1230004000028405600295
1230004000028405600295
1230004000028405600295
1230004000028405600295
1230004000028405600295
1230004000028405600295
1230004000028405600295
1230004000028405600295
1230004000028405600295
1230004000028405600295
1230004000028405600295
1230004000028405600295
1230004000028405600295
1230012000103148800147
1230012000103148800147
1230012000103148800147
1230012000103148800147
1230012000103148800147
1230012000103148800147
1230012000103148800147
1230012000103148800147
1230012000103148800147
1230012000103148800147
1230012000103148800147
1230012000103148800147
1230012000103148800147
1230012000103148800147
1230012000103148800147
1230012000103148800147
1230338000973824800555
1230338000973824800555
1230338000973824800555
1230338000973824800555
1230338000973824800555
1230338000973824800555
1230338000973824800555
1230338000973824800555
1230338000973824800555
1230338000973824800555
1230338000973824800555
1230338000973824800555
1230338000973824800555
1230338000973824800555
1230338000973824800555
1230338000973824800555
1230338001901449600555
1230338001901449600555
1230338001901449600555
1230338001901449600555
1230338001901449600555
1230338001901449600555
1230338001901449600555
1230338001901449600555
1230338001901449600555
1230338001901449600555
1230338001901449600555
1230338001901449600555
1230338001901449600555
1230338001901449600555
1230338001901449600555
1230338001901449600555
1230346000103044000554
1230346000103044000554
1230346000103044000554
1230346000103044000554
1230346000103044000554
1230346000103044000554
1230346000103044000554
1230346000103044000554
1230346000103044000554
1230346000103044000554
1230346000103044000554
1230346000103044000554
1230346000103044000554
1230346000103044000554
1230346000103044000554
1230346000103044000554
1230355000086934400510
1230355000086934400510
1230355000086934400510
1230355000086934400510
1230355000086934400510
1230355000086934400510
1230355000086934400510
1230355000086934400510
1230355000086934400510
1230355000086934400510
1230355000086934400510
1230355000086934400510
1230355000086934400510
1230355000086934400510
1230355000086934400510
1230355000086934400510
1230364000070872800554
1230364000070872800554
1230364000070872800554
1230364000070872800554
1230364000070872800554
1230364000070872800554
1230364000070872800554
1230364000070872800554
1230364000070872800554
1230364000070872800554
1230364000070872800554
1230364000070872800554
1230364000070872800554
1230364000070872800554
1230364000070872800554
1230364000070872800554
1230373000054757600431
1230373000054757600431
1230373000054757600431
1230373000054757600431
1230373000054757600431
1230373000054757600431
1230373000054757600431
1230373000054757600431
1230373000054757600431
1230373000054757600431
1230373000054757600431
1230373000054757600431
1230373000054757600431
1230373000054757600431
1230373000054757600431
1230373000054757600431
1230382000038664800234
1230382000038664800234
1230382000038664800234
1230382000038664800234
1230382000038664800234
1230382000038664800234
1230382000038664800234
1230382000038664800234
1230382000038664800234
1230382000038664800234
1230382000038664800234
1230382000038664800234
1230382000038664800234
1230382000038664800234
1230382000038664800234
1230382000038664800234
Thanks
James

OGG for SQL Server - Extract stops capturing - Bug?

Hi, all,
I've found a problem with OGG for SQL Server where the Extract stops capturing data after the transaction log is backed up. I've looked for ways to reconfigure OGG to avoid the problem but couldn't find any reference to options to workaround this problem. It seems to be a bug to me.
My Extract configuration is as follows:
EXTRACT ext1
SOURCEDB mssql1
TRANLOGOPTIONS NOMANAGESECONDARYTRUNCATIONPOINT
EOFDELAY 60
EXTTRAIL dirdat/e1
TABLE dbo.TestTable;
I'm using the EOFDELAY parameter for testing purposes only, since it's easy to reproduce the scenario that causes the issue when the extract polling is configured with longer intervals.
When the Transaction Log backup runs, SQL Server marks all the virtual logs that are older than the primary and secondary truncation points as inactive (status = 0). These virtual logs can then be reused if required. They still contain change records, though, and OGG can read from then if required, before they are overwritten. This situation will never occur if we are not using SQL Replication and have the Extract configured with the parameter MANAGESECONDARYTRUNCATIONPOINT.
However, I'm trying to simulate a scenario where OGG is used along SQL Replication and the extract is configured with the NOMANAGESECONDARYTRUNCATIONPOINT option. The situation that I've reproduced and caused the Extract to stop capturing is the follow sequence of events:
1. Extract reads transaction log and capture change up to LSN X
2. More change are made to the database and the LSN is incremented
3. Log Reader reads Transaction Log, captures changes up to LSN X+Y and advances the secondary truncation point to that LSN
4. A transaction log occurs, backs up all the active virtual logs, advances the primary truncation point to a LSN greater than LSN X+Y, and marks all the virtual logs with LSNs <= X+Y as inactive (status = 0)
5. Changes continue to happen in the database consuming all the available inactive virtual logs and overwriting them.
6. The extract wakes up again to capture more changes.
At this point, the changes between LSNs X and X+Y are not in the Transaction Log anymore, but are available in the backups. From what I understood in the documentation the Extract should detect that situation and retrieve the changes from the Transaction Log backups. This, however, is not happening and the Extract becomes stuck. It still pools the transaction log at the configured interval query the log state with DBCC LOGINFO, but doesn't move forward anymore.
If I stop and restart the Extract I can see from the trace that it does the right thing upon startup. It realises that it requires information that's missing from the logs, query MSDB for the available backups, and mine the backups to get the required LSNs.
I would've thought the Extract should do the same during normal operation, without the need for a restart.
Is this a bug or the normal operation of the Extract? Is there a way to configure it to avoid this situation without using NOMANAGESECONDARYTRUNCATIONPOINT?
The following is the state of the Extract once it gets stuck. The last replicated change occurred at 2012-07-09 12:46:50.370000. All the changes after that, and there are many, were not captured until I restarted the Extract.
GGSCI> info extract ext1, showch
EXTRACT EXT1 Last Started 2012-07-09 12:32 Status RUNNING
Checkpoint Lag 00:00:00 (updated 00:00:54 ago)
VAM Read Checkpoint 2012-07-09 12:46:50.370000
LSN: 0x0000073d:00000aff:0001, Tran: 0000:000bd922
Current Checkpoint Detail:
Read Checkpoint #1
VAM External Interface
Startup Checkpoint (starting position in the data source):
Timestamp: 2012-07-09 11:41:06.036666
LSN: 0x00000460:00000198:0004, Tran: 0000:00089b02
Recovery Checkpoint (position of oldest unprocessed transaction in the data so
urce):
Timestamp: 2012-07-09 12:46:50.370000
LSN: 0x0000073d:00000afd:0004, Tran: 0000:000bd921
Current Checkpoint (position of last record read in the data source):
Timestamp: 2012-07-09 12:46:50.370000
LSN: 0x0000073d:00000aff:0001, Tran: 0000:000bd922
Write Checkpoint #1
GGS Log Trail
Current Checkpoint (current write position):
Sequence #: 14
RBA: 28531192
Timestamp: 2012-07-09 12:50:02.409000
Extract Trail: dirdat/e1
CSN state information:
CRC: D2-B6-9F-B0
CSN: Not available
Header:
Version = 2
Record Source = A
Type = 8
# Input Checkpoints = 1
# Output Checkpoints = 1
File Information:
Block Size = 2048
Max Blocks = 100
Record Length = 20480
Current Offset = 0
Configuration:
Data Source = 5
Transaction Integrity = 1
Task Type = 0
Status:
Start Time = 2012-07-09 12:32:29
Last Update Time = 2012-07-09 12:50:02
Stop Status = A
Last Result = 400
Thanks!
Andre

It might be something simple (or maybe not); but the best/fastest way to troubleshoot this would be to have Oracle (GoldenGate) support review your configuration. There are a number of critical steps required to allow GG to interoperate with MS's capture API. (I doubt this is it, but is your TranLogOptions on one line? It looks like you have it on two , the way it's formatted here.)
Anyway, GG support has seen it all, and can probably wrap this up quickly. (And if it was something simple -- or even a bug -- do post back here & maybe someone else can benefit from the solution.)
Perhaps someone else will be able to provide a better answer, but for the most part troubleshooting this (ie, sql server) via forum tends to be a bit like doing brain surgery blindfolded.

Unable to shrink tlog

Hello,
Usually,the tlog backup goes to tape but it's giving some error.I took the backup on disk and then doing tlog shrink but it's not happening.
Please advise.
Best regards,
Vishal

Hello,
Usually,the tlog backup goes to tape but it's giving some error.I took the backup on disk and then doing tlog shrink but it's not happening.
Please advise.
Best regards,
Vishal
You might need to take log backup twice to actually be able to shrink the log file.please run DBCC LOGINFO(DB_NAME) and see if status column last value is 0 or not unless it is zero you wont be able to shrink.
You can also use below query to see what is holding your log from truncating'.If it is log backup you need to take log backup.
select name,log_reuse_wait_desc from sys.databases where name='db_name
Problem with tape log backup is there are 2 options to take log backup one just log backup (plain) and other take log backup and truncate logs hope you have selected second option.Else please take log backup using TSQL
Please mark this reply as the answer or vote as helpful, as appropriate, to make it useful for other readers

ShrinkFile

Boa tarde,
Usei os seguintes comandos para consultar e reduzir o arquivo de log do meu banco porém os aquivos continuam do mesmo tamanho. O que posso fazer para resolver ?
DBCC SQLPERF (LOGSPACE)
DATABASE NAME - LOG SIZE (MB) - LOG SPACE USED (%) - STATUS
DB_TESTE - 25034,68
- 86,71359 - 0
SELECT * FROM DB_TESTE.DBO.SYSFILES
DB_TESTE_Log
DBCC SHRINKFILE ( DB_TESTE_Log, 200,
TRUNCATEONLY )

Hello,
Based on your description, you want to shrink the log file of the database to 200 MB. However TRUNCATEONLY is applicable only to data files and
target_size is ignored if specified with TRUNCATEONLY in DBCC SHRINKFILE.
Fanny that is actually a document bug which I proved it in below link.
http://social.technet.microsoft.com/wiki/contents/articles/22206.when-using-dbcc-shrinkfile-for-log-files-can-we-use-truncateonly-option.aspx
Here is
Connect raised for the same
It does effect the log files it shrinks it.Cuts out the free space and returns it to OS
Rafael,
What does below command returns
select log_reuse_wait_desc from sys.databases where name='db_nmae'
If it returns log backup you need to take log backup( may be twice) which will truncate the logs and then you can shrink using DBCC SHRINKFILE.
DBCC LOGINFO(DB_NAME) run this command if last value in col status is 2 which means active transaction is still holding the VLF, so then you need to take log backup.If the value is 0 you can shrink then
>>and I don't have space to realize a bkp currently.
You can change recovery model of database to simple and then back to full and then it will allow you to shrink but you will loose point in time recovery. Please take full backup after this activity.
Please mark this reply as the answer or vote as helpful, as appropriate, to make it useful for other readers
My TechNet Wiki Articles

How can U decrease the Log Size in MS-SQL server?

Hello friends,
                I am in Big Trouble. I have a Problem.we are Using MS-SQL server 8.00.924. The Database Log size is almost Full.But BackUps are not Done successfully ,,How to Shink the Log file,, Any body pls help me I will give more Points.
Regards,
Balaram

Hi Balaram,
Please see the link and scripts which is given hereunder.
http://support.microsoft.com/kb/873235
You can check this method also.
Method 1 Delete the Log (LDF) File
Although this method is simple, it is not supported by Microsoft®. Additionally, it may not work for all systems. Follow these steps to try the simple method on your system.
Ensure that no users are logged into the database.
Open Query Analyzer or another program to execute SQL scripts. Ensure that dsdbase is not selected in the drop-down DB list.
Open and run the script DETACH.sql. This script detaches the DataLyzer® database from the SQL server database.
Make a backup copy of the DSdbase_Data.MDF and DSdbase_Log files.
Rename the DSdbase_log file to another name, for instance backup_DSdbase_log.
Open and run the script ATTACHMDF.sql. This script re-attaches the DataLyzer® database to the SQL database without attaching the log file. NOTE: If your database is not stored in the location c:mssql7data change the SQL script to reflect the location of your DSdbase file.
If the script runs successfully, a new DSdbase_Log file will automatically be created to the original size specified when creating the database. It is suggested that users keep the backup copies made of their database and log files for several days to ensure an available backup if anything happens to the new log file.
If the script does not run successfully, method 1 will not work for your current DataLyzer® Spectrum database. This is because your databases structure is dependent on the logfile. In this case, re-name the original log file back to DSdbase_log. Run the script ATTACH.sql and again change the file location to the location of your DataLyzer® database, if necessary. When the database is successfully re-attached, try using method 2 to shrink the log file.
Method 2 Truncate and Shrink the Log (LDF) File
Although this method of shrinking the log file is more complicated, it is supported by Microsoft®, and it will work for almost all systems. Follow these steps:
Ensure no users are logged into the database.
Open Query Analyzer or another program to execute SQL scripts. Ensure that dsdbase is not selected in the drop-down DB list.
If you have already tried method 1, or if you have a current backup of you database and log file, skip to step 7
Open and run the script DETACH.sql. This script detaches the DataLyzer® database from the SQL server database.
Make a backup copy of the DSdbase_Data.MDF and DSdbase_Log files.
Open and run the script ATTACHMDF.sql. This script re-attaches the DataLyzer® database to the SQL database. NOTE: If your database is not stored in the location c:mssql7data, change the SQL script to reflect the location of your DSdbase file.
Select dsdbase from the drop down DB list in the program you are using to execute the SQL scripts.
8.      Run VIEW2LDF.sql. Below is an excerpt similar to what will be displayed on your screen: FileId   FileSize    StartOffset    FSeqNo      Status   Parity CreateTime
2          1245184   819              1292   0          64         1999-12-15 10:25:13.597
2          1245184   1253376       1225    0          128        1999-11-19 09:12:57.743
2           1245184   2498560       1224    0          128     1999-11-19 09:12:23.82
2          1499136   3743744       1318    2          64         1999-12-15 10:25:36.880
Locate the 2 in the status column. The location of the 2 determines where the active portion of the log is.
If the 2 is in the bottom half of the log, open and run the SQL script MOVE2LOOP.sql. This script is an infinite loop used to move the active portion of the log.
Re-Run the VIEW2LDF.sql script to make sure that the 2 is now located in the first half of the script.
Run the script SHRINKLOG.sql to reduce the size of the database.
Run the script VIEW2LDF.sql to view the new status of the log file. You should notice that the number of lines is significantly smaller than it originally was.
If you wish to further reduce the size of the database, repeat steps 8 through 13.
Text Context of SQL Scripts
ATTACHMDF.sql
sp_attach_db @dbname=N'dsdbase', @filename1=N'c:mssql7datadsdbase_data.mdf'
ATTACH.sql
sp_attach_db @dbname=N'dsdbase', @filename1=N'c:mssql7datadsdbase_data.mdf',
@filename2=N'c:mssql7datadsdbase_log.ldf'
Detach.sql
sp_detach_db dsdbase
MOVE2LOOP.sql
USE DSDBASE
GO
CREATE TABLE VIRTUAL_LOG_FILE_WRAPPER (CHAR1 CHAR(4000))
GO
DECLARE @I INT
SELECT @I = 0
WHILE (1=1)
BEGIN
WHILE (@I < 100)
BEGIN
INSERT VIRTUAL_LOG_FILE_WRAPPER VALUES ('A')
SELECT @I = @I + 1
END
TRUNCATE TABLE VIRTUAL_LOG_FILE_WRAPPER
BACKUP LOG DSDBASE WITH TRUNCATE_ONLY
END
SHRINKLOG.sql
DBCC SHRINKFILE (DSDBASE_LOG, TRUNCATEONLY)
BACKUP LOG DSDBASE WITH TRUNCATE_ONLY
VIEW2LDF.sql
DBCC LOGINFO(DSDBASE)
Regards,
Anil

Why are transactions long running?

My stored procedure has a transaction blog. I pick up a record from a database and process it in that transaction block. I noticed that my transaction
log has grown in gigabytes. But my transaction block would execute for the 2nd time only when it has finished processing the 1st time right? Because as I mentioned my transaction block executes each time for a record in a table. So 2nd record won't be picked
until 1st record is finished processing. So how come my transaction log has grown into GBs? Like until the 1st time transaction block finishes executing, other records won't be processed, meaning the same transaction block in the same SP wont be visited. So
why is my log growing? It is showing active transaction when i execute the dbcc opentran command. Please advice
mayooran99

It is in simple recovery mode. What does it write in log file? The whole page at that moment or is it just the statements to be executed?
mayooran99
In simple recovery mode, the transaction log will record both new/old values if the operation is update, will record all insert values if the operation is insert and will record all deleted values if the operation is delete.
on a high level, there is no difference between simple and full recovery in terms of what the transaction log will record. It will need all this information, so if a crash happens during the transaction,it can use this information to restore the data to a consistent
state.
if the crash happens right after the transaction is committed but before the checkpoint occurred, it will again use transaction log data to recover the data.
the difference between simple and full recovery is, once the transaction is committed, in simple recovery , it will truncate the logical log space(VLF) where as in full recovery, you need log backup to truncate the logical log space.
so, if the stored procedure is having long transaction or having lot of transactions(update/insert/delete), it will generate quite a bit log before the truncate happens.
It could also be possible that there is one open tran and all the committed transactions after that are not truncated either. this could be a possibility..see the below example:
create database DB1
alter database DB1 set recovery SIMPLE
--check the log file size
select size,* from sys.master_files where database_id=db_id('DB1')
use DB1
go
Create Table Table1 (sno int identity(1,1) Primary key,sname varchar(20),scity varchar(20))
Create Table Table2 (sno int identity(1,1) Primary key,sname varchar(20),scity varchar(20))
-- Session 1
---leave the transaction open. we will commit later
Begin Tran
Insert into Table1
Values('William','Dallas')
/*session 2 do this transaction in another session and commit the transaction*/
Begin Tran
Insert into Table2
Values('William','Dallas')
commit
go 10000
/*check the log virtual space now, you will quite a few active vlf's..ie because of the open transaction in session1*/
dbcc loginfo
--now commit the transaction in session1
Commit
--check vlf's in log. all vlf's should be free(status=0)
dbcc loginfo
/*if the database is in full recovery, all the vlf would still be with status=2.only log backup would make them reusable(status=0)*/
Hope it Helps!!

High T-log Size

Hi,
I have a a database of 100Gigs and a t-log of 300GB. The database is scheduled for t-log backup every one hour and differential every day.
1.I increasted the t-log backup frequency-But there is no change in file size even after shrink
2.T-log has 3 files.other two files has just 10Gb each.What would be the reason?
Regards,
Arun
Best Regards, Arun http://whynotsql.blogspot.com/

hi,
1.You should first try to find out what is holding your log from truncating
select name,log_reuse_wait_desc from sys.databases where name='db_name'
You should also run DBCC loginfo(db_name) to check if status col value is zero or not.Unless its zero you cannot shrink
2.No specific reason.Is auto growth disabled for these two files? What is use of 3 transaction log files.
Please mark this reply as the answer or vote as helpful, as appropriate, to make it useful for other readers

Run-time error "PXA_NO_SHARED_MEMORY" occurred

Hi All,
My production system is running fine. And when i check SM21 I saw a lot of error message Run-time error "PXA_NO_SHARED_MEMORY" occurred and Run-time error "SYSTEM_NO_ROLL" occurred. However I can't see any error in ST22. I had read sap note 307976. And dont know when I restart the SAP services is it will be fine?
trc file: "dev_w0", trc level: 1, release: "640"
ACTIVE TRACE LEVEL           1
ACTIVE TRACE COMPONENTS      all, M
B
B Mon Feb 22 08:13:29 2010
B create_con (con_name=R/3)
B Loading DB library 'D:\usr\sap\PRD\SYS\exe\run\dbmssslib.dll' ...
B Library 'D:\usr\sap\PRD\SYS\exe\run\dbmssslib.dll' loaded
B Version of 'D:\usr\sap\PRD\SYS\exe\run\dbmssslib.dll' is "640.00", patchlevel (0.58)
B New connection 0 created
M sysno      00
M sid        PRD
M systemid   560 (PC with Windows NT)
M relno      6400
M patchlevel 0
M patchno    58
M intno      20020600
M make:      multithreaded, ASCII
M pid        2440
M
M ***LOG Q0Q=> tskh_init, WPStart (Workproc 0 2440) [dpxxdisp.c   1160]
I MtxInit: -2 0 0
M DpSysAdmExtCreate: ABAP is active
M DpShMCreate: sizeof(wp_adm)          11592     (828)
M DpShMCreate: sizeof(tm_adm)          2219848     (11044)
M DpShMCreate: sizeof(wp_ca_adm)          18000     (60)
M DpShMCreate: sizeof(appc_ca_adm)     6000     (60)
M DpShMCreate: sizeof(comm_adm)          192000     (384)
M DpShMCreate: sizeof(vmc_adm)          0     (320)
M DpShMCreate: sizeof(wall_adm)          (22440/34344/56/100)
M DpShMCreate: SHM_DP_ADM_KEY          (addr: 047D0040, size: 2510384)
M DpShMCreate: allocated sys_adm at 047D0040
M DpShMCreate: allocated wp_adm at 047D17A8
M DpShMCreate: allocated tm_adm_list at 047D44F0
M DpShMCreate: allocated tm_adm at 047D4518
M DpShMCreate: allocated wp_ca_adm at 049F2460
M DpShMCreate: allocated appc_ca_adm at 049F6AB0
M DpShMCreate: allocated comm_adm_list at 049F8220
M DpShMCreate: allocated comm_adm at 049F8238
M DpShMCreate: allocated vmc_adm_list at 04A27038
M DpShMCreate: system runs without vmc_adm
M DpShMCreate: allocated ca_info at 04A27060
M DpShMCreate: allocated wall_adm at 04A27068
X EmInit: MmSetImplementation( 2 ).
X <ES> client 0 initializing ....
X Using implementation flat
M <EsNT> Memory Reset disabled as NT default
X ES initialized.
M
M Mon Feb 22 08:13:30 2010
M calling db_connect ...
C Thank You for using the SLOLEDB-interface
C Using dynamic link library 'D:\usr\sap\PRD\SYS\exe\run\dbmssslib.dll'
C dbmssslib.dll patch info
C    patchlevel   0
C    patchno      58
C    patchcomment MSSQL: Workaround for SQL2005 change in RpcNexecInsert (814383)
C np:(local) connection used on PKG-PRD
C CopyLocalParameters: dbuser is 'prd'
C
C Mon Feb 22 08:13:31 2010
C Provider SQLNCLI could not be initialized. See note #734034 for more information.
C Using provider SQLOLEDB instead.
C OpenOledbConnection: MARS property was not set.
C Provider Release:08.50.1022
C Provider SQLNCLI could not be initialized. See note #734034 for more information.
C Using provider SQLOLEDB instead.
C OpenOledbConnection: MARS property was not set.
C
C Mon Feb 22 08:13:42 2010
C Cache sizes: header 52 bytes, 20000 names (26720000 bytes), 1000 dynamic statements (5432000 bytes), total 32152052 bytes
C Using shared procedure name cache PKG-PRD_PRDPRD_PRD_MEM initialized by another process.
C Connected to db server : [PKG-PRD] server_used : [np:(local)], dbname: PRD, dbuser: prd
C pn_id:PKG-PRD_PRDPRD_PRD
C Not using MARS (on sql 8.0)
B Connection 0 opened (DBSL handle 0)
B Wp Hdl ConName          ConId     ConState     TX PRM RCT TIM MAX OPT Date     Time   DBHost
B 000 000 R/3              000000000 ACTIVE       NO YES NO 000 255 255 20100222 081330 PKG-PRD
C The IRow interface is supported by this OLEDB provider
M db_connect o.k.
I
I Mon Feb 22 08:14:02 2010
I MtxInit: 0 0 0
M SHM_PRES_BUF               (addr: 09E50040, size: 4400128)
M SHM_ROLL_AREA          (addr: 12510040, size: 262144000)
M SHM_PAGING_AREA          (addr: 617B0040, size: 113246208)
M SHM_ROLL_ADM               (addr: 0A290040, size: 2616690)
M SHM_PAGING_ADM          (addr: 0A510040, size: 525344)
M ThCreateNoBuffer          allocated 320144 bytes for 1000 entries at 0A5A0040
M ThCreateNoBuffer          index size: 3000 elems
M ThCreateVBAdm          allocated 7424 bytes (50 server) at 0A5F0040
X EmInit: MmSetImplementation( 2 ).
X <ES> client 0 initializing ....
X Using implementation flat
X ES initialized.
B db_con_shm_ini: WP_ID = 0, WP_CNT = 14
B dbtbxbuf: Buffer TABL (addr: 103500C8, size: 30000128, end: 11FEC4C8)
B dbtbxbuf: Buffer TABLP (addr: 0E5200C8, size: 10240000, end: 0EEE40C8)
B dbexpbuf: Buffer EIBUF (addr: 0EF000D0, size: 4194304, end: 0F3000D0)
B dbexpbuf: Buffer ESM   (addr: 0F3100D0, size: 4194304, end: 0F7100D0)
B dbexpbuf: Buffer CUA   (addr: 0F7200D0, size: 3072000, end: 0FA0E0D0)
B dbexpbuf: Buffer OTR   (addr: 0FA100D0, size: 4194304, end: 0FE100D0)
M rdisp/reinitialize_code_page -> 0
M icm/accept_remote_trace_level -> 0
M rdisp/no_hooks_for_sqlbreak -> 0
C Provider SQLNCLI could not be initialized. See note #734034 for more information.
C Using provider SQLOLEDB instead.
C OpenOledbConnection: MARS property was not set.
S *** init spool environment
S initialize debug system
T Stack direction is downwards.
T debug control: prepare exclude for printer trace
T new memory block 120D8040
S spool kernel/ddic check: Ok
S using table TSP02FX for frontend printing
S 1 spool work process(es) found
S frontend print via spool service enabled
S printer list size is 150
S printer type list size is 50
S queue size (profile)   = 300
S hostspool list size = 3000
S option list size is 30
S      found processing queue enabled
S found spool memory service RSPO-RCLOCKS at 121F0098
S doing lock recovery
S setting server cache root
S found spool memory service RSPO-SERVERCACHE at 121F03E0
S    using messages for server info
S size of spec char cache entry: 165020 bytes (timeout 100 sec)
S size of open spool request entry: 1152 bytes
S immediate print option for implicitely closed spool requests is disabled
A
A -PXA--
A PXA INITIALIZATION
A PXA: Fragment Size too small: 107 MB, reducing # of fragments
A System page size: 4kb, admin_size: 13396kb.
A Attached to PXA (address 21F30040, size 440000K)
A abap/pxa = shared protect gen_remote
A PXA INITIALIZATION FINISHED
A -PXA--
A
C The IRow interface is supported by this OLEDB provider
B dbtran INFO (init_connection '<DEFAULT>' [MSSQL:640.00]):
B   max_blocking_factor = 50, max_in_blocking_factor      = 255,
B   min_blocking_factor =   5, min_in_blocking_factor      = 10,
B   prefer_union_all    =   1, prefer_union_for_select_all =   0,
B   prefer_fix_blocking =   0, prefer_in_itab_opt          =   0,
B   convert AVG         =   1, alias table FUPD            =   0,
B   escape_as_literal   =   0, opt GE LE to BETWEEN        =   0,
B   select *            =0x00, character encoding          =SBCS / []:X,
B   use_hints           = abap->1, dbif->0x1, upto->0, rule_in->0,
B                         rule_fae->0, concat_fae->0, concat_fae_or->0
A
A Mon Feb 22 08:14:03 2010
A ABAP ShmAdm attached (addr=53EC5000 leng=20955136 end=552C1000)
A >> Shm MMADM area (addr=5422D180 leng=134720 end=5424DFC0)
A >> Shm MMDAT area (addr=5424F000 leng=17244160 end=552C1000)
A RFC Destination> destination pkg-prd_PRD_00 host pkg-prd system PRD systnr 0 (pkg-prd_PRD_00)
A RFC Options> H=pkg-prd,S=00
A RFC FRFC> fallback activ but this is not a central instance.
A
A RFC rfc/signon_error_log = -1
A RFC rfc/dump_connection_info = 0
A RFC rfc/dump_client_info = 0
A RFC rfc/cp_convert/ignore_error = 1
A RFC rfc/cp_convert/conversion_char = 23
A RFC rfc/wan_compress/threshold = 251
A RFC rfc/recorder_pcs not set, use defaule value: 1
A RFC rfc/delta_trc_level not set, use default value: 0
A RFC rfc/no_uuid_check not set, use default value: 0
A RFC abap/SIGCHILD_default not set, use default value: 0
A RFC Method> initialize RemObjDriver for ABAP Objects
A Hotpackage version: 49
M ThrCreateShObjects          allocated 14604 bytes at 0FFD0040
N
N Mon Feb 22 08:14:05 2010
N SsfSapSecin: putenv(SECUDIR=D:\usr\sap\PRD\DVEBMGS00\sec): ok
N
N =================================================
N === SSF INITIALIZATION:
N ===...SSF Security Toolkit name SAPSECULIB .
N ===...SSF trace level is 0 .
N ===...SSF library is D:\usr\sap\PRD\SYS\exe\run\sapsecu.dll .
N ===...SSF hash algorithm is SHA1 .
N ===...SSF symmetric encryption algorithm is DES-CBC .
N ===...sucessfully completed.
N =================================================
N MskiInitLogonTicketCacheHandle: Logon Ticket cache pointer retrieved from shared memory.
N MskiInitLogonTicketCacheHandle: Workprocess runs with Logon Ticket cache.
W =================================================
W === ipl_Init() called
W    ITSP Running against db release 620!
W    ITSP Disable Kernel Web GUI functionality
W === ipl_Init() returns 2, ITSPE_DISABLED: Service is disabled (sapparam)
W =================================================
E
E Mon Feb 22 08:14:39 2010
E Replication is disabled
C
C Mon Feb 22 08:15:00 2010
C sloledb.cpp [DoDbcc,line 2930]: Error/Message: (err 2571, sev 0), User 'prd' does not have permission to run DBCC CACHEPROFILE.
C Procname: [No proc]
C
C Mon Feb 22 08:15:01 2010
C statement rerun with user dbo was successful, you can ignore the preceeding message
C
C Mon Feb 22 08:16:27 2010
C Provider SQLNCLI could not be initialized. See note #734034 for more information.
C Using provider SQLOLEDB instead.
C OpenOledbConnection: MARS property was not set.
S
S Mon Feb 22 08:19:23 2010
S found spool memory service RSPO-ACTIONS at 121F4C68
A
A Mon Feb 22 08:19:55 2010
A TH VERBOSE LEVEL FULL
M ***LOG R68=> ThIRollBack, roll back () [thxxhead.c   12304]
C Rollback Work (0)
A
A Mon Feb 22 08:19:59 2010
A Mon Feb 22 08:19:59 2010
A
A ABAP/4 Program /SDF/SAPLRI_SQLSERVER                   .
A Source /SDF/LRI_SQLSERVERU02                    Line 264.
A Error Code CALL_FUNCTION_CONFLICT_LENG.
A Module $Id: //bas/640_REL/src/krn/runt/abfunc.c#14 $ SAP.
A Function FuncParams Line 2906.
C Rollback Work (0)
C
C Mon Feb 22 08:20:00 2010
C sloledb.cpp [DoDbcc,line 2930]: Error/Message: (err 2571, sev 0), User 'prd' does not have permission to run DBCC loginfo.
C Procname: [No proc]
C
C Mon Feb 22 08:20:01 2010
C statement rerun with user dbo was successful, you can ignore the preceeding message
C
C Mon Feb 22 08:20:07 2010
C sloledb.cpp [ParamStmtExec,line 12251]: Error/Message: (err 50000, sev 0), Table not found.
C Procname: [##Y3PKG_PRDprd00000024400000003365081342]
C ParamStmtExec failed. HR 80040e14 DBSL retcode 99. stmt: [sap_get_table_size_info 'syscomments', 'prd', 'PRD'
C /* R3:CL_SQL_RESULT_SET=============CP:234 T: */
C ]
C Conn_i:2 selection:1 singleton:0 flag_fupd:0 use_cursor:0 chksum: 222194
C dbdsmss: DBSL99 SQL50000
C Table not found.
B ***LOG BY2=> sql error 50000      performing FET        [dbds#3 @ 592] [dbds    0592 ]
B ***LOG BY0=> Table not found. [dbds#3 @ 592] [dbds    0592 ]
B ***LOG BY1=> sql error 50000      [dbacds#2 @ 1187] [dbacds 1187 ]
B
B Mon Feb 22 08:26:10 2010
B dbmyclu : info : my major identification is 3232261128, minor one 0.
B dbmyclu : info : Time Reference is 1.12.2001 00:00:00h GMT.
B dbmyclu : info : my uuid is 31B87DDDE43B904B955F2E6B45F604BE.
B dbmyclu : info : current optimistic cluster level: 3
B dbmyclu : info : pessimistic reads set to 2.
N login/password_change_for_SSO : 1 -> 1
B
B Mon Feb 22 08:32:54 2010
B table logging switched off for all clients
M
M Mon Feb 22 08:45:50 2010
M PfHIndInitialize: memory=<60720150>, header=<60720150>, records=<60720180>
S
S Mon Feb 22 08:55:52 2010
S handle memory type is RSTSPROMMM
M
M Mon Feb 22 09:18:08 2010
M *** ERROR => NiProcMsg: rc=-104 (NIEROUT_SNC_FAILURE) from router [nibuf.c      423]
M *** ERROR => MsIAttachEx: NiBufConnect to /H/192.168.100.7/S/sapdp99/H/194.39.131.34/S/sapdp99/H/oss001/sapmsOSS failed (rc=NIEROUT_SNC_FAILURE) [msxxi.c      633]
M *** ERROR => LgIAttach: MsAttach (rc=NIEROUT_SNC_FAILURE) [lgxx.c       2984]
M *** ERROR => LgIGroup: LgIAttach(rc=-101) [lgxx.c       3504]
A TH VERBOSE LEVEL FULL
M
M Mon Feb 22 09:18:28 2010
M *** ERROR => NiProcMsg: rc=-104 (NIEROUT_SNC_FAILURE) from router [nibuf.c      423]
M *** ERROR => MsIAttachEx: NiBufConnect to /H/192.168.100.7/S/sapdp99/H/194.39.131.34/S/sapdp99/H/oss001/sapmsOSS failed (rc=NIEROUT_SNC_FAILURE) [msxxi.c      633]
M *** ERROR => LgIAttach: MsAttach (rc=NIEROUT_SNC_FAILURE) [lgxx.c       2984]
M *** ERROR => LgIGroup: LgIAttach(rc=-101) [lgxx.c       3504]
A TH VERBOSE LEVEL FULL
C
C Mon Feb 22 10:01:09 2010
C Rollback Work (0)
A
A Mon Feb 22 10:18:24 2010
A TH VERBOSE LEVEL FULL
M ***LOG R68=> ThIRollBack, roll back () [thxxhead.c   12304]
C Rollback Work (0)
A
A Mon Feb 22 10:18:26 2010
A Mon Feb 22 10:18:26 2010
A
A ABAP/4 Program /SDF/SAPLRI_SQLSERVER                   .
A Source /SDF/LRI_SQLSERVERU02                    Line 264.
A Error Code CALL_FUNCTION_CONFLICT_LENG.
A Module $Id: //bas/640_REL/src/krn/runt/abfunc.c#14 $ SAP.
A Function FuncParams Line 2906.
C Rollback Work (0)
C sloledb.cpp [DoDbcc,line 2930]: Error/Message: (err 2571, sev 0), User 'prd' does not have permission to run DBCC loginfo.
C Procname: [No proc]
C statement rerun with user dbo was successful, you can ignore the preceeding message
C
C Mon Feb 22 10:18:29 2010
C sloledb.cpp [ParamStmtExec,line 12251]: Error/Message: (err 50000, sev 0), Table not found.
C Procname: [##Y3PKG_PRDprd00000024400000012657081342]
C ParamStmtExec failed. HR 80040e14 DBSL retcode 99. stmt: [sap_get_table_size_info 'syscomments', 'prd', 'PRD'
C /* R3:CL_SQL_RESULT_SET=============CP:234 T: */
C ]
C Conn_i:2 selection:1 singleton:0 flag_fupd:0 use_cursor:0 chksum: 222194
C dbdsmss: DBSL99 SQL50000
C Table not found.
B ***LOG BY2=> sql error 50000      performing FET        [dbds#3 @ 592] [dbds    0592 ]
B ***LOG BY0=> Table not found. [dbds#3 @ 592] [dbds    0592 ]
B ***LOG BY1=> sql error 50000      [dbacds#2 @ 1187] [dbacds 1187 ]
Could anybody advice me on this
Regards,
Zul

Hi,
I hope 440000 will not the cause,
this might occur due to many reasons,
1. make sure you have all the components(Applications,OSlevel,DBlevel) are at same level in entire the landscape.
2. you can observe the evenlogs at OSlevel to get the error information pointing to. Also check for the dumps/logs(work direcotry).
3. if not, can open SAP message.
regards
Nagaraju

Many VLFs in high availability database

Hi,
I have a database in high availability mode with a Log file of 16GB. Running DBCC SQLPERF (LOGSPACE) reveals that only 0.03% of the file is used. So I'd like to shrink the file. I performed full and transaction backups and tried to shrink, but nothing happens.
I executed DBCC OPENTRAN but no transaction is open on the DB. Executing SELECT name,log_reuse_wait_desc FROM sys.databases; returns "NOTHING". But If I run DBCC LOGINFO I see 320 Virtual log files, with about 200 being marked with STATUS 2 (not
reusabale).
Looking at the Always-on availability dashboard shows that replication is fine.
Does somebody know why these VLFs are marked as such?
Thanks

with about 200 being marked with STATUS 2 (not reusabale).
No need to worry about this, you can read below link
http://blog.moserit.com/virtual-log-file-monitoring-with-dbcc-loginfo-in-alwayson
Though we mark the log records as available for cleanup, the actual process of cleaning up is deferred. Since the new available space is tracked but the VLFs themselves are not
yet marked as inactive it is not reported as such by DBCC LOGINFO directly. The other commands such as DBCC SQLPERF(‘LOGSPACE’) accurately report the free space since they include the VLFs marked for deferred cleanup when accounting for space.
There is, unfortunately, no equivalent of the DBCC LOGINFO currently that can track VLFs marked for deferred cleanup.

Tansaction Log File of SQL Server

Dear Guys,
We have implemented ECC 6.0 on Windows 2003 Server / MS SQL 2005 platform. For backup purpose we have bought Tivoli. Some reason we cant backup of Database from DB13. Our Transaction log file is goin to increase, when after taking the backup of Transaction log, I shrink the log file but size of log file never decrease. So size of log file increase and free size on disk decrease. Second issue is, Can I shirnk the log file when SAP instance run ...??
So help me out in this 2 issues.
Thanks & Regards,
Charanjit Singh.

Hi,
The log space is usually huge after a fresh install. You can use the following script to shrink the log file. Make sure you take a full backup of the database before you run. If you running in production system make sure you run during the scheduled downtime after a full backup.
1) BACKUP LOG <DB_NAME> TO [<DEVICE_NAME>] WITH NOFORMAT, NOINIT,
NAME = N'<DESCRIPTION>', SKIP, NOREWIND, NOUNLOAD, STATS = 10 --backup transaction log to a backup device
GO
2) USE <DB_NAME> --switch to the database
GO
3) DBCC SHRINKFILE (N'<LOGICAL_LOG_FILE_NAME>' , 2024) --shrink the file to 2gb (2024). use sp_helpdb to find out the logical file name
GO
4) sp_helpdb <SID> --view the new size
go
5) dbcc loginfo (<SID>) -- a status of 2 means transaction is dirty.
Repeat steps 1 thru 5 until log size shrinks to your desired size.
The step 3 value of "2024" is 2gb which tries to shrink the log file to 2MB. But it is not guaranteed. That is why you have to run it multiple times.
The step 5 displays output of the transactions in the log file. The status of "2" means it is dirty. If you see this value at the end of result set then there is less chance of shrinking the log file. if you see the value of "2" in the middle of the result set then there is likely chance of shrinking the file. "DBCC LOGINFO" is an undocumented command in SQL Server. But it is a favourite command of all DBAs'.
I hope this helps.
RT
Message was edited by:
R.T.
Message was edited by:
R.Th.

How to read or view information (ldf) File And find out operations update or drop or insert for tables ?

I'm want read Ldf log and find out all event for database ???

I'm want read Ldf log and find out all event for database ???
hello,
You can use below undocumented commands( you cannot completely read it but below commands will surely be helpful).Any specific requirement you have from log files
select * from fn_dblog()
dbcc loginfo(db_name)
dbcc log
simiilar discussion
http://social.msdn.microsoft.com/Forums/sqlserver/en-US/5aea4dab-8d84-4515-b686-202e329ad2b6/how-to-open-or-read-sql-server-log-file-ldf?forum=sqlgetstarted
http://stackoverflow.com/questions/9767054/read-the-log-file-ldf-in-sql-server-2008
Please mark this reply as the answer or vote as helpful, as appropriate, to make it useful for other readers

What is RecoveryUnitID in DBCC LOGINFO?

Similar Messages

Maybe you are looking for