I just received this message:
Exception of type 'System.OutOfMemoryException' was thrown. (Microsoft.SqlServer.SmoEnum)
I am completely dead in the water. Cannot connect to SSAS 2005. HELP!
hello,
it is not quite clear what are you trying to do when the exception happens. Is the system really running low on memory?
the comment above seems to suggest that you are trying to connect to SSAS, however the exception seems to come from SMO (?) which is an OM for working with SQL server (relational).
if the issue is that you are unable to connect to MSAS, could you please provide more information as to what are the sequence of actions you take (also how you connect -- from Management Studio or in some different way; if from Management Studio - what do you enter in connection dialog etc.), and more information about when the exception occures and stack trace and other info about the error (in management studio error msg usually has "Show Technical Details" button)?
thanks a lot,
|||I am trying to do the initial load of SSAS 2005. Just loading the Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe executable to get to the SSAS databases is just stopped. I had to "split" the SSAS databses to get them imported into three splits. The SSAS 2000 has 35 dimensions, 49 cubes, and 4 virtual FACT cubes. This was load #2 out of 3. I had just completed the cube builds on 31 out of 49 cubes. Had just completed 138 million rows of populating the SSAS 2k5 database. I had done tests that put the total row count to 240 to 280 million rows when completed. The size of the total SSAS DB is currently projected at 16-20 GB when completed. I tried to re-impliment the 2nd set of cubes and now SSAS 2k5 will not even start. I had tried the /PAE as well as the /3GB swtiches with no success. I tried each switch individually with full reboot each. No success. . Help.
|||Update. I took the switch /3GB OUT of the boot.ini and was successful in getting the SS Management Studio to at least start. Now, as I try to open cubes to work with them in Management Studio, it gives me the following error:
Excetion of type 'System.OutOfMemoryException' was thrown. (Microsoft.SqlServer.SmoEnum)
Is there a 2GB memory limit in SSAS? When you put in the /3GB switch it actually fails to load initially. Is there some caching/hashing algorythm that allows the standard non /3GB switch to be successfule and the /3GB switch enablement to fail in high-memory usage cases? This is a bit perplexing. The 2000 OLAP database runs at about 1.7 GB TOTAL in production today (the source for the migration wizard), and it is stable. Using the Database Migration Wizard (9.0.2047.0) I could NOT get it to migrate the whole 2k OLAP database. It has the memory exception error. I had to "split" it up (Migtration Wizard) to get the the dimensions and cubes to load by chunking it into SSAS 2k5. I was successful on the first half of the 2k OLAP migration to SSAS 2k5 mmigrating 31 out of 49 cubes. I have subsequently loaded all of the dimensions (all 35 from above) with data and cubes (about 31 cubes with about 137 million rows total) with data. I tried to migrate the other outstanding 16 cubes and all errors started happening and SSAS 2k5 Management Studio is failing to even load. My hardware/OS config is as follows:
C drive - 10 GB (RAID 1)
D drive - 8 GB (4095 pagefile is here) (RAID 10)
E drive - 50GB (RAID 10)
RAM - 8GB
OS - Server 2003 Enterprise (Open License Version 5.2 Build 3790.srv_03_sp1_rtm.050324-1447: ServicePack 1)
DB - SQL Server 2005 Enterprise - SP1/041806 installed 042006 - Full install of all components. I have stopped all SQL Services accept SQL Browser and SSAS services.
Does anyone else have this issue with SSAS 2005 and hitting the ceiling-memory limit?
How can 2000 OLAP run at 1.7 GB and be stable and SSAS 2k5 fails to even load the exact same data using Microsoft's own toolset?
I am seeking to find the solution to this issue and are on an extremely aggreesive schedule. HELP!
|||Okay,
I have tried something to see if it will work and here is where I am at. I cleared the transferred SSAS DB from Management Studio completely. I re-migrated (in three MigratioWizard.exe sessions) most (32 dimensions and 38 cubes) of the existing objects into a new "stand-alone" SSAS 2K5 database. I then "imported" the now almost fully deployed (all that is left are the FACT tables) SSAS 2K5 into BI Studio successfully using the import funtion in BI Studio! I then backed up and deleted the SSAS 2K5 DB from Management Studio. Now the bad news. I was able to get the BI project to "build" with no errors. Now, I am back to the SAME Exception of type
'System.OutOfMemoryException' was thrown
error I had when only "trying" to partially migrate and populate even 50% of the cubes in Management Studio (see previous postings). Now, this same error shows up under the errors bottom-left dialog box in BI studio with no other explanantions. I have been combing the internet trying to get a solution. Can anyone out there help?
|||We have a defect in RTM and SP1 builds, that OutOfMemoryException occurs when SQL Management Studio connects to AS2005 with large database(s). We are fixing this for SP2.
Meanwhile, the work-around would be to use Visual Studio to connect to AS2005 to administer or process objects.
Or to temporary separate databases on different AS2005 instances (then script each of them and run the scripts to combine them back on a single AS2005 instance).
Adrian Dumitrascu.
|||The deimensions and cubes are now in ONE instance of BI Studio 2005. There are no more SQL or ANY databases that are in this box or connected to this instance. I am running a DELL 2850 with DUAL 3.8 Ghz procs, 8GB or RAM, and ALL data partitions that SQL 2K5 touches are RAID 10/15k hard drives. This should be "flying" on 2K5 from all of the press. These databases are running perfectly on SQL 2000 AS at 1.7 GB of RAN with no issues. I want to be crystal-clear with my response. The objects are ALL now in BI studio (definitions of only dimensions and cubes) and the SQL 2K5 BI studio throws the SAME error whether I try to use the migration tool OR try to deploy using BI Studio. I need help or this is going to be a Microsoft 2K5 disaster. Is there some work around to data sizes coming from 2000 AS? I cannot be the ONLY person that has seen this complete stoppage. If you wish to continue on this most-excellent quest to actually see the realization of the intent of "Project-REAL" then please give me a ring at 512.845.4950 or reply to this so that we can overcome this very intense (and complete stoppage) road block. Please help. I do not mean to be forward and apologize. This project should have taken approximately 60-80 hours and it is now well into the hundreds of hours. I am merely a fellow MS-er just trying to overcome adversity and see this through to success for us all.
:)
|||I will investigate this and will try to reproduce it on our side to debug and see if we can provide a work-around or a quick fix.
You migrated the AS2000 database with Migration Wizard ? If yes, can you run the wizard again to generate the migration script ? (there is an option on the first page to either migrate to AS2005 or generate the script). Once you have the script, please archive it as .zip and send it to me at adumitrascu at hotmail dot com.
Adrian Dumitrascu.
|||I forgot to mention, please double check and remove sensitive meta-data in the AS2000 database and the migration script. Especially verify the connection strings for data sources (for passwords - just change the connection strings in the script to bogus values, I don't need them to be correct). Also, if you have MDX calculations that you want to keep private, please remove them from the script (search for "<Commands>" in the script to review them).
Adrian Dumitrascu.
|||Adrian,
Thanks again for your help here. You have been great. We do have some issues with running out of memory that I will be posting. Here is the error:
Errors and Warnings from Response
Memory error: Allocation failure : Not enough storage is available to process this command. .
Memory error: Allocation failure : Not enough storage is available to process this command. .
Errors in the metadata manager. An error occurred when loading the AggregationDesign aggregation design, from the file, '\\?\E:\Program Files\Microsoft SQL Server\MSSQL.2\OLAP\Data\Business Report System ADW.1.db\TA_2003.0.cub\TA_2003.0.det\AggregationDesign.0.agg.xml'.
Error Code = 0x8007000E, External Code = 0x00000000:.
What can I do now about this? We seem to be hitting every roadblock that can be during this POC. Any assistance will be greatly appreciated.
krj
|||Hi Kjr,
I have the same problem that you had before the last post.
What solution you had about this problem System.OutOfMemoryException with MigrationWizard? You can help me?
tks,
Eder F. Dias
|||We are actually still working on the issue. The last recommendation was to move UP to the 64-BIT version of SSAS 2k5. As we continue to peice-meal the cubes into the 32-BIT solution there is an entire discussion about maintenace and care of the SSAS DB going forward. Given the application memory "ceiling" that you may be experiencing it may make sense to try the 64-bit version of SSAS 2k5. This would, as I understand it, help to allocate the required memory in a manner that would potentially allow thw application to run more freely.
krj
|||Thanks Kjr for answer.
Actually my environment is:
- Intel Xeon CPu 3.4 GHZ, 3.93GB RAM
- Windows 2003 Enterprise x64 SP1
- SQL Server 2005 Enterprise x64 (SP1 - build 2153)
How you can see I working in a 64-Bit Environment, but the exception still happen. I don't know why. Maybe my environment isn't the best? What can i do for became it better?
Somethig strange is that the MigrationWizard.exe process work in a 32-Bit even in x64 enviroment. There is another application that work in 64-Bit?
More informations about my server:
OS Name Microsoft(R) Windows(R) Server 2003 Enterprise x64 Edition
Version 5.2.3790 Service Pack 1 Build 3790
Other OS Description Not Available
OS Manufacturer Microsoft Corporation
System Name SRVBRASIL31
System Manufacturer HP
System Model ProLiant DL380 G4
System Type x64-based PC
Processor EM64T Family 15 Model 4 Stepping 3 GenuineIntel ~3400 Mhz
Processor EM64T Family 15 Model 4 Stepping 3 GenuineIntel ~3400 Mhz
Processor EM64T Family 15 Model 4 Stepping 3 GenuineIntel ~3400 Mhz
Processor EM64T Family 15 Model 4 Stepping 3 GenuineIntel ~3400 Mhz
BIOS Version/Date HP P51, 10/10/2005
SMBIOS Version 2.3
Windows Directory C:\WINDOWS
System Directory C:\WINDOWS\system32
Boot Device \Device\HarddiskVolume1
Locale United States
Hardware Abstraction Layer Version = "5.2.3790.1830 (srv03_sp1_rtm.050324-1447)"
User Name Not Available
Time Zone E. South America Standard Time
Total Physical Memory 4,031.28 MB
Available Physical Memory 1.70 GB
Total Virtual Memory 5.69 GB
Available Virtual Memory 3.23 GB
Page File Space 2.00 GB
Page File C:\pagefile.sys
tks a lot
Eder F Dias
|||Adrian,
You mentioned there is a fix for this coming in SP2. Is this fix available as a Hotfix now or only as a part of SP2?
- Steve
|||Steve,
I had varying degrees of success and are too trying to keep things running and get them stable. What I had done to extend the envelope is to try give the "system" as much "resources" as I could. First, I had 8 GB of RAM to your 4 GB. This may be a critical point. Remember, in most cases WIndows needs a memory to run as an operating system. In my case on the 32-bit platform this was around 600/700 MB for just the OS. On the 64-bit I am not so sure of the base OS memory requirements. For SQL 2K5 though (on the 32-bit platform) it was recommneded to me to put in the /3GB switch in the boot.ini for SQL 2K5 to allow for higher memory addressing. Also there is an AWE switch in "spconfig" (properties of the server in SQL 2K5) to allow for this memory to be used.
The reason that I am going over this with you is that it seems you are having the EXACT behavior in the 64-bit version that I ma having in the 32-bit version. It seemed logical to assume that I was hitting the wall because of the 32-bit addressing limitations (as told to me by Microsoft). I will continue on the next post.
No comments:
Post a Comment