Quantcast
Channel: SCN: Message List - SAP MaxDB
Viewing all 2539 articles
Browse latest View live
↧

Can we drop a 7.6 MaxDB into a 7.9 MaxDB?

June 19, 2014, 7:06 am
$
0
0

Hi,

 

I've got to migrate a 6.3 Content Server (based on 7.6 MaxDB) on Windows 2003 (which according to the PAM isn't supported but has been working ok). Into a 7.9 MaxDB on Windows 2012 R2. We might have to go to 2008 first, then 2012

 

There is very little info out there on whether The Content Server 6.3 currently (6.4 maintenance will soon end) will be supported on 2008, but I'm not sure that this will matter as long as the MaxDB side is correct.

 

I've read somewhere that from 7.5 you can drop a any version into 7.9? - is this true?...could someone help out on a possible upgrade path, strategy?

 

Regards

 

Neil

↧
Search

Re: Can we drop a 7.6 MaxDB into a 7.9 MaxDB?

June 20, 2014, 1:01 am
↧
↧

Re: unixODBC connection ok but no Data !

June 20, 2014, 1:38 am
$
0
0

H,

I have checked the log file and I am being at los. There are no errors in and the data is returned

The data is only copied internally but I could not find a call where isql retrives the data fetched.

SQLFetch 2014-06-19 10:20:05.168182
--> SQLExtendedFetch
::GET RESULT SET [0x0xfe49b0]
CURSOR NAME: 'SQLCURS_2' [0x0xfe1d40]

SQLExtendedFetch 2014-06-19 10:20:05.168251
StatementHandle  [in]    : 0xfe1310
FetchOrientation [in]    : SQL_FETCH_NEXT
FetchOffset      [in]    : 0

::SET ROWSET SIZE 'SQLCURS_2' [0x0xfe1d40]
SIZE: 1

::SET BINDING TYPE 'SQLCURS_2' [0x0xfe1d40]
BINDING TYPE: 0

::FETCH NEXT 'SQLCURS_2' 2014-06-19 10:20:05.168397
DATA:
APPLICATION
I   T          AT L          I           DATA
ROW: 1

::GET ROWS AFFECTED [0x0xfe1d40]
ROWS: 1

::GET ROWS AFFECTED [0x0xfe1d40]
ROWS: 1
RowCountPtr      [out]   : (null)
RowStatusArray   [out]   : (null)
SQLRETURN                : SQL_SUCCESS
<-- SQLExtendedFetch

SQLColAttribute 2014-06-19 10:20:05.168551
StatementHandle  [in]    : 0xfe1310
ColumnNumber     [in]    : 1
FieldIdentifier  [in]    : SQL_COLUMN_DISPLAY_SIZE
BufferLength     [in]    : 0
NumericAttrPtr   [out]   : 26
NumericAttrPtr   [out]   : 0x7fff81d03d7c
StringLengthPtr  [out]   : (null)
SQLRETURN                : SQL_SUCCESS

SQLColAttribute 2014-06-19 10:20:05.168664
StatementHandle  [in]    : 0xfe1310
ColumnNumber     [in]    : 1
FieldIdentifier  [in]    : SQL_COLUMN_LABEL
BufferLength     [in]    : 301
CharacterAttrPtr [out]   : 0x7fff81d03d80
StringLengthPtr  [out]   : (null)
SQLRETURN                : SQL_SUCCESS

SQLGetData 2014-06-19 10:20:05.168754
StatementHandle  [in]    : 0xfe1310
ColumnNumber     [in]    : 1
TargetType       [in]    : SQL_C_CHAR
TargetValuePtr   [out]   : 0x7fff81d03f10
BufferLength     [in]    : 301
ValuePtr         [out]   : SQL_UB_OFF

::GETOBJECT 'SQLCURS_2' 2014-06-19 10:20:05.168851 [0x0x1015dc0]
COLUMN
I   T          AT L          I                  D                  P
1   ASCII       T 301        0x00007FFF81D03B20 0x00007FFF81D03F10 0x0000000000000000
DATA
I   T          AT L          I           DATA
1   ASCII       T 301        26          '2014-06-19 10:19:33.218298'
StrLen_or_IndPtr [out]    : 26
SQLRETURN                : SQL_SUCCESS


I am not familar with isql. Did you hav tried to ask the question in a isql forum? It might be that someone can check why no data is retireved from isql.

 

Kind regards,

Burkhard

↧

Re: Can we drop a 7.6 MaxDB into a 7.9 MaxDB?

June 20, 2014, 3:40 am
$
0
0


Yes, note 129352 is a good start, however for Content Server please pay attention to the referenced notes 962019 and 389366 specifically written for CS.

 

Alsolet me add (as stated in the note) that you can copy MaxDB 7.5 and newer versions to MaxDB 7.9, so this should work for your 7.6 Content Server, unless restricted by the two notes mentioned above...

↧

Re: unixODBC connection ok but no Data !

June 23, 2014, 3:10 am
$
0
0

Hi Burkhard,


yes, in the meantime I discovered that I have the same Problem with the Oracle-Driver.


I will follow up this issue with the unixODBC guys.

 

But if I find some solution will post it here in case somebody else get the same Problem.

 

regards

jph

 





↧
↧

Re: Livecache crashes when starting dbanalyzer after 7.9.08 build 17  Upgrade

June 23, 2014, 2:39 pm
$
0
0

Hello,

 

After working with SAP dev. support we found out that the following 03 parameters were changed by  the livecache ptach upgrade. The value is ALLINONE which is wrong. With SAP support, we changed to the defaults. We still do not know why it got changed. Waiting for SAP dev. to provide an answer. Meanwhile,we could able start livecache using LC10, using the default values.

With MaxCPU=6

TaskCluster01

TaskCluster02

TaskCluster03

 

Thank you for everyone's help.

 

 

Dinali

↧

Re: Livecache crashes when starting dbanalyzer after 7.9.08 build 17  Upgrade

June 23, 2014, 2:24 pm
$
0
0

Hello Dinali,

could you please check if this SAP Note applies in your scenario?

2001926 - SAP MaxDB/liveCache terminates when you access the volume (Version >= 7.8, Unix)

 

It seems that parameters are not correctly configured from the trace you provided, you can use this SAP Note to check: 1111426 - Parameter check for liveCache/MaxDB instances

 

Regards,

Valerio

↧

Re: Can we drop a 7.6 MaxDB into a 7.9 MaxDB?

June 24, 2014, 6:01 am
$
0
0

Hi Neil,

 

In case your query is answered request you to close this thread please.

 

Regards,

Deepak Kori

↧
Search

SAP content server - Migration as well upgrade

June 25, 2014, 7:45 am
$
0
0


Hello All,

 

I am planning to upgrade my content server from 630 to 650, the challanges are , our  current server in windows 2000  ( IA 32 Bit)and Maxdb 7.3.0.35 . i want to bring into Windows 2008 R2 (64 Bit) MaXdb 7.8 .

 

my plan is do a inplace upgrade in current server from windows 2000 to Windows 2003 and perform inplace upgrade for maxdb7.3.0.35 to 7.5  and content server from 630 to 640 at one stage.

 

and next stage is install content server 650 maxdb 7.8 in windows 2008 R2 (64 Bit ), an do a system copy from source .

 

My questions are first stage will be fesible for me, in second stage do i face any issues ? will content server accept this bit change from 32 to 64 bit.

 

do i face any challanges in Maxdb Upgrade?

 

Regards,

Prem

↧
↧

Re: SAP content server - Migration as well upgrade

June 25, 2014, 8:03 am
↧

Re: Livecache crashes when starting dbanalyzer after 7.9.08 build 17  Upgrade

June 26, 2014, 4:59 am
$
0
0

Hi Dinali,

 

Taskcluster01 value ALLINONE was very old parameter setting and is not usual anymore.
All in one means that all database Tasks are running in only 1 thread - which is nonsense in a Multi CPU environment.Today, even in single CPU systems we would not
recommend to use the ALLINONE setting
If this parameter was changed manually it will never been changed implicitely. But param_extgetall USEDDEFINED=YES did not show the user modified flag.

 

I'm in dicussion with my Dev support Colleague Yashwanth to find out the reason for this historical setting. The parameter history of KernelVersion could be helpful as well.

 

So I think we can close this request here.

Regards, Christiane

↧

Re: Healthy values in IOTHREADS?

June 26, 2014, 5:07 am
$
0
0

Hi Daniel,

 

this is a difficilt to answer questions because it depends a lot from the activities on the system.

Them IOm write time on the Log volume should be not more than 5 msec better would be < 5 msec
The read time on data volumes would be ok if they are arround 10 msec better would be < 5 as well.

 

Please notice if you are using NFS file systems that the network performance influences the IO counters as well.

 

If you are a SAP customer it makes sense to open an OSS ticket to get this analyzed in detail.(SV-BO)

 

This is a very common recommendation. If we have huge application traffic we need to have faster IO times then listed here.

IOf you have only peaks of such bad IO times you should try to find out what is active when you have such bad times. -> DB-Analyzer use smaller intervall.

 

Regards, Christiane

↧

Cache_size parameter changes

June 30, 2014, 7:34 pm
$
0
0

Hello,

 

For a MaxDB system, the cache_size parameter was changed depending upon the hardware. Later, the hardware was moved to a small box due to a db crash and then we have observed that the parameter got changed to a new value.

As far as the time stamp show, it got changed during the DB restart.

Please let me know if the MaxDB system automatically changes the parameter.

 

Thanks a lot in advance!

 

Regards,

Ankit

↧
↧

Re: Cache_size parameter changes

July 1, 2014, 12:25 am
↧

Re: Cache_size parameter changes

July 1, 2014, 9:43 pm
$
0
0

Hello Deepak,

 

Thanks a lot for your reply.

Also the link is very helpful indeed.

Kindly let me know if you have any further documentation regarding this parameter.

 

Thanks and Regards,

Ankit

↧
Search

Re: Cache_size parameter changes

July 2, 2014, 1:32 am
↧

RUN_RSAIMMERGE_TRANSFER: Long runtime during upgrade to EhP7 MaxDB

July 5, 2014, 3:17 pm
$
0
0

Hi gurus,

 

We are in downtime phase of our PRD system.

We are in phase RUN_RSAIMMERGE_TRANSFER. We still in this phase during 4 hours. In others RDBMS (Oracle - SQL Server), this phase is very quickly (lower to 1 hour)

 

Server Name     No. Type PID      Status  Reason Sem Start Error CPU Time   User   Report   Action          Table Sem Sem Sem Sem Sem CurrSem. Mutex Mutex Mutex

<server>_<SID>_00  41 BTC      6870 Running            Yes            14154 DDIC   CL_AIMME Sequential Read E071   0   0   0   0   0        0     0     0     0

 

We are using SUM 1.0 SP08. Our system has SAP Kernel 7.40 lvl 27 with MaxDB 7.9.08.008, and we go to SAP BASIS 740 SP04. SAP Note 1442150 is implemented by SPS level...., Note 1460004 also implemented

 

WP log:

 

A Sat Jul  5 23:23:20 2014

A  AppServerTimeSync, checkLocalTime():

A    Initializing local WP variables:

A    zdate_LastLocalTime with 1404595400

A    zdate_LastLocalBias with 0

A  ***GENER* Trace switched off ***

B  dbrda: Redirect database access is disabled via rsdb/rda profile parameter setting.

E  Enqueue Info: enque/use_pfclock2 = FALSE

M

M Sat Jul  5 23:23:21 2014

M  SecAudit(rsauinit): WP attached to existing shared memory.

M  SecAudit(RsauShmInit): addr of SHM for Audit.. = 7f6fb646d000

M  SecAudit(RsauShmInit): addr of RSAUSHM........ = 7f6fb646e000

M  SecAudit(RsauShmInit): addr of RSAUSLOTINFO... = 7f6fb646e9d0

M  SecAudit(RsauShmInit): addr of RSAUSLOTS...... = 7f6fb646e9e0

A

A Sat Jul  5 23:23:43 2014

A  WP has reached abap/heaplimit = 40000000 bytes

 

Instance parameters:

abap/buffersize = 900000

ztta/roll_area = 10000000

ztta/roll_extension = 4000000000

abap/heap_area_dia = 4000000000

abap/heap_area_nondia = 4000000000

abap/heap_area_total = 8000000000

gw/max_conn = 2000

gw/max_sys = 2000

rdisp/appc_ca_blk_no = 2000

rdisp/max_arq = 2000

rdisp/max_comm_entries = 2000

rdisp/tm_max_no = 2000

rdisp/wp_ca_blk_no = 2000

rsdb/cua/buffersize = 15000

rsdb/ntab/entrycount = 90000

rsdb/ntab/ftabsize = 90000

rsdb/ntab/irbdsize = 18000

rsdb/ntab/sntabsize = 3000

rsdb/obj/buffersize = 130000

rsdb/obj/large_object_size = 45000

rsdb/obj/max_objects = 40000

rtbb/buffer_length = 60000

sap/bufdir_entries = 10000

zcsa/db_max_buftab = 35000

zcsa/presentation_buffer_area = 20000000

zcsa/table_buffer_area = 250000000

em/global_area_MB = 2048

em/initial_size_MB = 12288

em/address_space_MB = 4096

abap/heaplimit=40000000

 

Any idea for speed up the phase?

 

Regards

↧
↧

Re: RUN_RSAIMMERGE_TRANSFER: Long runtime during upgrade to EhP7 MaxDB

July 7, 2014, 1:37 am
$
0
0

Hi all,

 

Finally, the phase finishes after 24 hours.

 

Regards

↧

Re: RUN_RSAIMMERGE_TRANSFER: Long runtime during upgrade to EhP7 MaxDB

July 7, 2014, 1:43 am
$
0
0

Hi Javier,

 

You have 2 options

1) Try with 740 kernel SP 48 and check the results.

 

2) As it is known bug for MaxDB, please raise OSS mesage for further investigation and solutions.

 

Hope this helps,

 

Regards,

Deepak Kori

↧

Re: RUN_RSAIMMERGE_TRANSFER: Long runtime during upgrade to EhP7 MaxDB

July 7, 2014, 2:07 am
$
0
0

Hi Deepak,

 

 

 

We have a VH OSS Incident, no additional information.

Yes, we updated the kernel to SP60. The phase finished after 24 hours with this lvl....

 

I hope that SAP releases the solution for this MaxDB bug in short time.

 

 

 

Regards

↧
Viewing all 2539 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>