In ASE 15.7 , is the blocksize parameter in dump database beneficial for performance ? I am referring to the "blocksize" parameter, in the "dump database" command.
For example:
dump database pubs2 to 'compress::/tmp/backup_pubs1.dmp'
stripe on '/tmp/backup_pubs2.dmp'
with
init,
notify=operator_console,
**blocksize=262144,**
compression=100
go
How can I verify if backup server is taking this value? I am checking the log of the dump but I see this all time:
enter image description here
Thank you!
Related
Im trying to load a database dump into my Sybase backup server.
Running sybase ASE-16_0 on both my primary and backup machine.
Import is done in isql cli via
load database DB from ./dumps/data_dump
Error message is the following:
Backup Server session id is: 22. Use this value when executing the
'sp_volchanged' system stored procedure after fulfilling any volume change
request from the Backup Server.
Backup Server: 4.141.2.40: [11] The 'open' call failed for database/archive
device while working on stripe device
'/opt/dumps/data_dump' with error number
13 (Permission denied). Refer to your operating system documentation for further
details.
Also found this SAP Knowledge Base article, but it's hidden behind a paywall:
https://userapps.support.sap.com/sap/support/knowledge/en/3140989
Setting up a new Server fixed the issue for me. Im still working on a possible answer for this problem.
I am trying to diagnose an issue with SQL Server 2016 that occurred after some software was updated and I wanted to see if any of the server configurations changed. I have a backup of the master db and I figured I could compare settings between the live master and the backup. I read that "network packet size (B)" could cause "Protocol error in TDS stream" and I know how to look up the configuration using sp_configure but how can I look it up in the "master" backup?
The only way to do that is to copy regularly some views from master database (in fact mssqlsystemresources db) into a newly designed database and compare it.
Everytime you will query sys.configurations, the data will be retrieved from the actual system database...
So I have setup T-replication from Publisher (SQL Server 2014) Distributor (SQL Server 2014) Subscriber (SQL Server 2008 R2) and initialized it using a snapshot.
Checking in the replication monitor I find that the Snapshot agent has completed successfully and Log Reader agent is running.
Now in 'Distributor to Subscriber History' tab just beside the 'Undistributed Commands' Tab
I get the following error:
The process could not bulk copy into table '"dbo"."BEAMDATA"'. (Source: MSSQL_REPL, Error number: MSSQL_REPL20037)
Get help: http://help/MSSQL_REPL20037
End of file reached, terminator missing or field data incomplete
To obtain an error file with details on the errors encountered when initializing the subscribing table, execute the bcp command that appears below. Consult the BOL for more information on the bcp utility and its supported options. (Source: MSSQLServer, Error number: 20253)
Get help: http://help/20253
bcp "LOWIS_BUCT"."dbo"."BEAMDATA" in "C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\ReplData\unc\LOWISBUCT_CSSQLDB_BUCT_CSSQLDB_BUCT_ALL_TABLES\20160826064516\BEAMDATA_34#1.bcp" -e "errorfile" -t"\n\n" -r"\n<,#g>\n" -m10000 -SLOWISTSTSQL -T -w (Source: MSSQLServer, Error number: 20253)
Get help: http://help/20253
I thought this could be some kind of data overflow and hence checked the schema of the table at both Publisher and Distributor and they match exactly.
I cleaned the whole replication setup completely and re did it but still stuck at the very same place for the same table.
Has anyone encountered this before? Ask me if you need more information from my end which I can furnish.
I found the reason for this. It was due to the schema mismatch at the publisher and subscriber.
In the said table, column had the datatype (date(datetime) and when replication scripted the schema for this table it was scripted as date hence at subscriber when the snapshot was applied, the field had the data type of date.
When data was being copied from datetime to date field it resulted in the said error.
I did the necessary changes in the data type at the subscriber end and things got fixed,
I had a similar error and Problem "sql replication repl20037 field size too large". What i found is this. I setup the subscription with my local Sql Management Studio v18.10 on a SQL Server 12.0. This caused the the Bulk copy problem and a field mismatch. Solution: setting up the Publication directly on the Mgmt Studio on the source server and setting up the subscription directly on the Mgmt Studio on the destination server.
I would like migrate a database of sybase ASE 11.6 to a other server sybase ASE 11.9.2(ssma), 12.5.4 or later
I don't find a way to do that, i try to dump a database from 11.6 like that:
sp_dboption '<dbname>','single user',true
go
use <dbname>
go
dump database <dbname> to '/usr/dumps/remote/ledump.dmp'
and load on 12.5.4 like that:
sp_dboption '','single user',true
go
use
go
dump database to '/tmp/dump.dmp'
Then go to ASE 12.5.4
sp_dboption '<dbname>','single user',true
go
load database hr_db from '/tmp/ledump.dmp'
Database is offline !
then
online database REFCOM
go
database still offline !
the error: database is not ready yet
After shutdown server and restart, database is here but i have no table, juste user, role and procedure
I have some other option: ddlgen (not work on 11.6 i think), linked server ?, syscomment :#.
If someone have an idea to how migrate this database, it's will be a great help for me.
i find some technical help on ASE 10-11: http://www.nowandfutures.com/sybase/
and http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.ase_12.5.1/title.htm
thank you
If I recall correctly, 11.6 -> 12.5.4 would not be directly supported. I believe you can go from 11.6 -> 12.0 -> 12.5.4 or 11.6 -> 11.9.2 -> 12.5.4, but once you get more than 2 major releases apart, it's not supported.
My Dell pc failed;it was blue screen.I fixed that problem by formatting and reinstalling OS and other software that i have been using.Then I recoved my db designed using sqlserver 2005 and other files using recovery tools ;Easy Recovery 6.0.
The problem is : When I try to attach the recovered file(lpdb.mdf),It can not attached.The operation fails with the following message :
TITLE: Microsoft SQL Server Management Studio
Attach database failed for Server 'SAPC'. (Microsoft.SqlServer.Smo)
ADDITIONAL INFORMATION:
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)
SQL Server detected a logical consistency-based I/O error: torn page (expected signature: 0x55555555; actual signature: 0x4c093c91). It occurred during a read of page (0:0) in database ID 0 at offset 0000000000000000 in file 'F:\Recovered\lpdb_log.LDF'. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online. (Microsoft SQL Server, Error: 824)
Is there any who can help me?
I thank you!
Dejene.
Edit
By gbn from other closed question:
Hi mrdanny,
I tried the way you suggested me. The problem is unresolved.
Error is reported : Message One or more files do not match the primary file of the database. If you are attempting to attach a database, retry the operation with the correct files. If this is an existing database, the file may be corrupted and should be restored from a backup.
Is there an alternative solution that i should try? I am going to redesign the database.Please save my time!
Have you a good backup?
Given it says page (0:0), then I refer you to point 1
Use emergency mode and hope for the best. Paul Randall wrote DBCC CHECKDB...
The torn page is in the log file, so rename the log file and use the sp_attch_single_file_db procedure to attach the mdf and generate a new transaction log file.